Dialects and Chatbots

This week has been absolutely bonkers with academic commitments, personal commitments, and travelling all around the country, and I just haven’t had time to program very much at all. However, there is a major question I’d like some input on, which is what this entry is going to be about – and, indeed, it’s actually important to resolve this question before going too much further.

Learning Dialects

I’ve got the conversation window opened up. You can see yourself and the person you’re talking to, browse the appropriate options, and access some special windows for challenging the person you’re talking to, exchanging or buying/selling items, etc. The next stage (this is the task for this and next week) is to add in the full database of possible sentences, add in a data structure to allow new sentences to be easily added (by me in the future) and easily “unlocked” (e.g. when you learn about a painting, you can then talk about that painting), and in order to do this, I need to think about the other half of the conversation system: being able to ask these questions in appropriate dialects. We now therefore face a rather challenging question: how does the player learn a dialect? I see several options, and I’m still not quite sure which one to go for.

1) You can only say a sentence in a dialect once you have heard that sentence. This would be the simplest; I’d add some colour variation in sentences said by the other person in a conversation to show whether a) you already knew that dialect bit or b) you were hearing it for the first time.

2) You gradually acquire % knowledge, and it is distributed randomly across topics. This could have a range of methods: maybe it’s the number of conversations you have, or the time you spend in a particular nation (though I’d have to make sure that couldn’t be exploited by just running around in the forest, so maybe settlements only!), or something else; as time goes by you can say more and more in that dialect.

3) You can acquire books, or blocks of knowledge, which teach you *everything* in a dialect for *certain topics*. So, for instance, a book called “Laws and Finance in the Nation of Mugoppe” will, once acquired, allow you to speak like a native on the “Laws” and “Money” topics; similarly, perhaps certain characters can be encouraged to tell you everything about a certain topic, which then triggers a little under-the-hood acknowledgement of the same thing, i.e. you can now speak on that topic as a native.

4) Some combination of the above?

5) Something I haven’t thought of?

So, from readers, may I request: can you think about these options, and any potential fourth options you might conceive of, and let me know your thoughts? The basic requirements are for there to be a truly MASSIVE volume of potential sentences, a volume of sentences which can be added to as the player discovers more about the world, and a “learning” system that is interesting, distinctive, and can be somehow “distributed” throughout the world – i.e. you will always learn languages gradually, rather than instantly. This might be fast if the player specifically sets themselves to quickly learning a dialect and doing X (the learning process) a lot, but it should never be instant; there needs to be the option for the player character to know a tiny part of a dialect, a lot of a dialect, some of a dialect, etc.

There’s also  an additional exciting technical question of how to code and store it all… but my intention is to get to plan that out in the next few days once I have some idea of how it should all work!

Also, for this release, I think the player will have full access to every dialect, but in the very near future (0.9 or 0.10) that will change, and the player will have to learn each form of speech for each dialect via whatever means we decide upon.

Chatbots or Robots

A very interesting idea came up in URR’s Bay12 thread this week about whether URR could perhaps instead use chatbots rather than the “option robot” approach. A very strong argument was made for it, and I did actually seriously ponder it for several days, but in the end I decided it wasn’t the right move. Succinctly, my reasons were:

Technical/speed I’ve never used a chatbot before, and it would require a potentially lengthy process of up-skilling, and I’m really desperate to get 0.8 out asap.

Clues how easy/hard would it be to program a chatbot to “drop clues” of the right sorts at the right moments in the right context? I have no idea, but I don’t think it would be easy, and given the above point, I don’t know where I’d even start!

Annoyance – a chatbot means the player has to type things, and selecting greetings is one thing, but typing out a greeting every time would quickly get quite infuriating I think. Don’t get me wrong, it would be super cool if the player learned things rather than the player and the player character learning things, but the corrolary there is that the player would have to type everything.

Uniqueness – I already think the system I’ve proposed here will be very different to any other “option robot”, although I am certainly open to further ideas about how to further differentiate it. This is because: a) You have a massive wealth of options and no explicit clues towards what you should say, or implicit “suggestions” for what you should say (i.e. games tend not to give you “pointless” options, but URR will effectively do so, but it’s up to you to decide which are useful/pointless), b) you cannot exhaust all options and have to carefully choose options, c) you’ll be speaking in and moving between dialects and different styles to say the same things. I feel the combination of those three will be very distinctive.

So, I decided not to go to with the chatbot, but I thought it was an interesting enough idea to be worth posting here, in case anyone else has some other ideas, or some other ways to make the system even more distinctive (but you’ll have to be fast, coding starts this week!). Of course, had I elected to go with the chatbot model, I wouldn’t have needed to think about the player character learning dialects as discussed above in this entry, since it would be up to the player themselves, but for the reasons above, chatbots just don’t seem like the best solution for URR.

Fortresses, Names, 0.8 Changes, Bugfixes

Playtesting and Bugfixing

Lots of new bugs fixed thanks to the playtesting team!

Fixed a very rare issue where important NPCs, moving in a map grid you are in, and then you leave, will crash upon trying to calculate how long it will take them to hypothetically complete their task, which is a number the game needs in case the player doesn’t return to that map grid, and therefore the important NPC must “tick” over into their next task at the appropriate time – and, if the player returns to the grid half-way through the NPC concluding their task, the important NPC should be half way there. The problem would arise from a random NPC being placed on the important NPC’s target square, and preventing them from reaching it and the game from acknowledging that they’d finished testing out their remaining steps. To fix this the game checks if there is a random NPC, and if there is, it deletes it. If there’s another important npc there (super rare, but… I think it has to be possible?) then it shifts them aside by one tile, has the first important NPC test their route, then shifts them back. It’s not super-elegant, but it’s entirely unseen by the player and gets the job done, and fixes a crash bug that a good two or three people reported.

Fixed an issue with guards under very rare circumstances in castles not correctly exchanging themselves with the other appropriate guards, which now works fine again. (Again, as before, they tend to change over at the exact same time, and that’s a truly minor aesthetic thing I’ll alter in the future).


Fixed another bug where, for a small subset of possible nomadic fortresses, merchants wouldn’t spawn because I’d failed to ensure that there were spawn points for all the (twelve?) possible market generation algorithms. Fixed another bug which had slaves/servants failing to spawn in large-but-not-massive mansions in upper class districts, due to a rather silly typo in the function that generates them and wasn’t adding beds on the bottom floor to the list of beds that slaves/servants could spawn upon. Also fixed a bug with doors and iron bars in torture chambers in dungeons in castles, whereby looking at the bars would very rather fail to produce a picture, whilst looking at the doors would often result in a crash, due to the lack of a wall nearby for the game to use as the correct terrain/texture (this was quickly fixed by adding an exception telling the game to look further in the map for the right wall terrain instead of just the surrounding tiles, which is adequate in every single case/scenario except this one).

At this point, it is actually looking like… dare I say it… everything for NPC AI / scheduling / pathfinding is basically working? The volume of bug reports have slowed down from a torrent to a mere stream, and nobody has found any truly catastrophic issues that required me to seriously rewrite large portions of code.


Guards and Merchants in Fortresses

I’ve also continued to work on AI and NPCs and whatnot in the background whilst I wait for my playtesters to send me more bugs and issues. For instance, similar to a question I posed a little while ago about NPCs working correctly in towns, i.e. out of cities, came a similar question – would guards and merchants work correctly in nomadic fortresses?! Short answer: no, there were some serious issues with merchant scheduling, although guard scheduling appears to work completely fine. I had to put in quite a bit of new code to ensure that merchants were spawned correctly at the right places (whether in house or at their stalls), and to ensure that when merchants awake for the day and leave the house, they actually go directly to their stalls, and that when you leave and come back, the game actually correctly spawns the merchants at their outside shops instead of placing them in an imaginary “shop” building (which would be correct for a city, but is not correct for a fortress). Here’s a bunch of gifs from fortresses, the first three of merchants selling their wares, at home, and then emerging and returning to their location (a two-part gif).

Merchants1 Merchants2 Merchants3 Merchants4

However, as you will note… this does again raise the issue of skin tone and soil/sand colours. As I said a few entries ago, I’m going to try fiddling with the sand colours, and potentially making soil more of a “red brown” and even the darkest skin tones a little closer to “light brown”. It’s damned tricky though when you only have one-colour tiles to play with, in most cases, and there are only so many shades which are even light enough to see in the first place! Still: I’ll fiddle with these colours a bit and try to make sure that darker skin tones and soil/sand stand out a little better than they do at the moment, since although you can follow this, it’s obviously nowhere near as clear as dark skin tones on lighter terrain types / light skin tones on darker terrain types, and this is an issue that needs fixing somehow.

Conversation Window

You’ll notice a few other slight changes to the conversation list: “Exchange” and “Challenge” have been added, whilst one or two other options have either been removed, or subsumed into a larger category. “Exchange” is distinct from “Trade”, which is only an option for merchants and is explicitly for offering money, in exchange for an item, which they are selling; by contrast, “Exchange” will allow you to either demand something from them for nothing, or offer them something for nothing, or propose an exchange of items/information/money/anything else. It’ll then up to the other character to determine whether or not they want to accept the offer/demand/exchange, or they’re offended by it, flattered by it, etc. I realized that this was a pretty crucial thing to add, so that’s now in there, and will lead to a slightly different screen to the rest of the conversation options, although some of the others are definitely going to have unique/distinct stuff too. When clicked on, it’ll bring up three windows – one for your items/intelligence, one for their items/intelligence, and then a middle window to put in items from both lists and see what they think of it. The same window will be used for bartering in nations that aren’t especially fond of coinage.

“Challenge”, meanwhile, will be another more detailed function to allow the player to challenge another NPC at various things – or, at least, offer/demand a challenge. This could be a battle, or to accuse them of something, or offer to gamble with them, or anything of that sort. This will probably be developed a little later once I have some idea of what kinds of things you should be able to challenge NPCs at/with/for! This will bring up two windows, one for the nature of the challenge, and one for the stakes that you propose .The same two windows will probably be used for “Smithing” as a conversation topic, to decide on what you want smithed, and the resources/payment you want to contribute. Anyway, I think both of these more complex options will be very interesting and very important, alongside the other “standard” conversation options which will list topics the player can potentially speak about.

In this gif, we look at a standard conversation option which will give you one window with a list of things you can say and whether you know how to convincingly say them in that dialect, then we move onto the “Challenge” option which shows us two windows, and then “Exchange” which shows us three. Hopefully by next week we should have some idea of what’ll be in these options! (You’ll note the below gif was taken before name implementation)

Three speak

0.8 Small Changes

I’ve spent some of this past week also putting in a somewhat sizeable range of small edits for 0.8 across a range of areas.

I’ve removed the “History” and “Heresies” options from the encyclopedia. The histories option has been removed because it no longer correlated well with the new forms of name generation for each nation (as outlined in this and the previous entry), and because this needs a substantial re-write anyway, and because in the near future players should be discovering the world’s history through their actions and conversations, rather than in the encyclopedia. The “heresies” option has been removed because it was always just a very early draft when I first implemented it, and it really needs a lot more work before I’m happy making it a core part of the game. Equally, as discussed before, the encyclopedia won’t be around for long anyway, so I don’t think it’s a tremendous loss to remove these options. In the Guidebook, meanwhile, I’ve updated the “Controls” list, disabled the “Histories” section, and updated the “NPC Types” list, as well as changed a couple of comments in a few entries which were no longer totally accurate.

I’ve also updated the policy descriptions for each nation, since these were out of date, and didn’t fit! Again, before too long these will probably be less visible and abstracted out, but it’s an important improvement for now. I’ve also updated the “0.7” stuff everywhere to “0.8”, and various other fiddlings just to fix things here and there. Quite a few people reported as bugs things that I’d just put in as placeholders, so I thought it was important to prevent any future confusion! I also disabled the “grab” function (for pulling/pushing large objects) since a) it isn’t relevant right now and b) it doesn’t seem to be working properly.

Next Week

Names will be integrated from the experimental file into the main game, and I’ll be figuring out how exactly dialects are learned. I have come up with four main options, and I think the fourth is definitely the strongest from a gameplay perspective, but I want to get some feedback before I go ahead in put in all the infrastructure for this! And probably some more bug fixes, but I am rather pleased to note that bug reports have trickled off, so I’m quietly hopeful we’ve now fixed all the major issues with 0.8…

NPCs, Playtesting, Speech and Dialects

A huge update this week, so let’s skip the introduction and get on with it!

AI Refinements

I’ve had a wealth of fantastic feedback from my playtesters this week – thank you to you all! As such, I’ve implemented a whole range of fixes, some of which were for issues that I thought had been resolved ages ago, but some code edit in the mean time had apparently ruined, leading to these problems.

Firstly, we had a wealth of problems with servants/slaves in upper-class housing districts entering non-crucial mansions, and then when players enter them, a whole suite of Very Strange things happened, normally resulting in a crash. Quite a few people reported it. This bug was a leftover from a previous model of NPC handling, and required me to prevent random crowd servants/slaves from going into buildings, so now they just move around the district or sometimes leave the district instead; in turn, I’ve disabled servants/slaves in second-tier upper-class houses, and I’ll put them back once I come to 0.9 and I’m putting in all the other NPCs and NPC variations 0.8 will lack. This should all now be fine!


Secondly, I’ve had a bunch of reports of crashes when saving/loading the game, and these are very hard to diagnose, unfortunately, but I think I’ve fixed it. One was a rather strange issue with the pathfinding maps in buildings; these were just saved and loaded, but for some reason this has stopped working when you save and close the program; save and reload works fine. In truth, I don’t really understand what could be causing this in the slightest, but it takes just a few milliseconds to recalculate when you load the game instead of trying to load it from scratch, so I’ve dumped in some code to that effect, which will be sufficient for now. Debug logs still look crazy, though.


Thirdly, a major problem arose with non-“important” NPCs sometimes straying into the code for important NPCs, and being asked by the game to report their “current_step” variable (which relates to how far through they are moving from one district to another on a regular/routine schedule), and the game thereby crashing because they don’t have that variable at all. A lot of people reported this, and it turned out to be pleasingly trivial to diagnose and fix, since it basically required the addition of “if npc.important:” to a particular piece of AI code, and that sorted it out. Result!

We also had an issue with guards failing to appear to relieve other guards in upper-class districts, which has now been fixed:


And ambassadors were not always in their embassies at night, which needed a quick fix:


There were also reported issues of jailers sometimes getting into an infinite loop (fixed), an issue with castles that contained both slaves and jailers/torturers in the basement and they would sometimes try to path to beds in the other segment of the basement and cause the game to go into a loop (fixed), farmers sometimes didn’t always appear on their farms at the right times (fixed), and entering a farmhouse after a farmer who you saw enter, entered, and that farmer wasn’t an important farmer, would cause a crash (fixed), due to them inexplicably attempting to use a line of code designed for guards and knights moving between floors in castles, and the game freaking out with concern about the impossibility of pathing to duplicate mutually-exclusive staircases which didn’t exist. Weird. Also, we had a problem with guards sometimes teleporting themselves into the inside doors of a castle, which was screwing up their ability to exchange places with their counterparts at the right time (fixed, below) and a whole host of little minor problems which I didn’t write down whilst solving, but were generally not crash bugs, but just strange actions.


There is still one issue, which is that if you enter a “farm” map grid at night, the farmers spawn outside and then immediately rush inside to sleep; this really should be fixed, but it’s low priority, so in 0.9 I’ll make sure they appear in their buildings. It’s basically because most farmers being unique, but unimportant, AND being in their own buildings, is a unique combination, which requires some special code to it though. If I don’t mention on the blog that I’ve fixed this in the next couple of months, somebody remind me!

If you’re on the playtesting team, you should have a link to a new version in your inbox in the next few days. For everyone else, suffice to say that major bug-fixing improvements are taking place at the moment, and the team are doing damned well. More news as and when…

Talking Screen

Insanely exciting developments this week! We have a first draft of the conversation screen! It is heavily *in progress*, but check this beautiful thing out:


Now, I’ve been working on how this should look for quite some time and there’s a lot of stuff here to explain and describe, so let’s take it in order. Firstly, when you want to talk to someone you press ‘s’ for speak – ‘t’ is currently used for throw, and the options are therefore “throw” and “speak”, or “chuck” and “talk” – I think we can all agree that chuck is far too informal, so the first option is obviously better. This gives you a crosshair like the look function and the grab function and so forth, which can be moved in a 7×7 square centred on the player. Anyone in that area, and without your line of sight and on an explored tile (so you can’t exploit it by trying to speak through walls and finding where other NPCs are!) can be spoken with by pressing Enter, which brings you to the above screen. (In the below gif I quite rudely start talking to an NPC whilst they’re sleeping, but these are early days – naturally waking someone else will soon have some effect on their mood in the conversation).


Once you’re there, we have a bunch of options, which fall into three categories. Firstly, we have the “standard options”.


These are the options that the player will be given for every single person they ever talk to. These will be related to the player’s “memory” (which will soon replace the existing “encyclopedia”, which is to say that you can ask anyone a question about any sub-topic within these topics, so for every important painting you’ve seen, you’ll be able to raise it as a potential topic of conversation (if you’re thinking “this will make for extremely tedious optimal gameplay – don’t worry, I have a solution, which is later in this entry). These options will likely form the majority of one’s conversations, and allow for a great breadth in potential conversation topics. Naturally, some people will be more or less willing to discuss each topic, for reasons of their own preferences or their culture/religion.

Then, we have the “special options”.


These are options specific to the class of NPC you’re talking to. A priest will give you options like “Worship”, “Holy Book” and “Relics” that we see here; a servant or slave will show “Tasks”; a noble or lord might show “Family”; an archivist will show “Archives” and “Tombs”; and so on and so forth. There are never more than four special options, but quite a few classes of NPC now have four special options listed. These will often be the crucial topics to speak about with an NPC, but naturally the standard options will also often yield important or interesting data of various sorts. I think these add a nice sense of variety when encountering new types of NPC, and also direct players to some almost “recommended” topics of conversation, which might be especially important when people are learning the game and find themselves a little overwhelmed by the sheer volume of Stuff you can talk about.

And thirdly we have the “dialect” option.


Now, you may be thinking – what is to stop the player simply asking every single question to every important NPC in the hope of extracting some information? We all know that gamers can often be satisfied with performing some very unexciting things in games if they are gameplay-optimal, and naturally I therefore don’t want it to be gameplay-optimal to “grind” in this way and just ask everything you can in the hope of landing upon something which matters. Once you’ve explored the world a fair bit, you are going to have hundreds, and potentially (in the late game) thousands of things which you could ask a given NPC. The solution to this problem is rather simple, and I think rather elegant. Basically, all NPCs will have a “conversation interest” meter, hidden to the player, but reflected in the tone with which they speak. If you ask relevant questions, the conversation continues. If you don’t, they will quickly become disinterested, and past a certain point, just end the conversation with you. This will therefore strongly encourage the player towards focusing only on conversation topics you know are important, or towards those you think might be important, getting the player to make intelligent and informed judgements instead of just taking a shot on every conversation option. This is very different to most games with conversation options, in which players are generally strongly encouraged to exhaust every conversation tree, and I think it’ll be interesting to see how this plays out.

Also, I then thought of a way even this could be exploited – end the conversation, start a new conversation, try some more options, etc – but that’s also readily fixed. Characters who end the conversation due to your stupid or irrelevant questions will be unwilling to start a new conversation for a period of time, and since time will be the fundamental “food clock” resource in URR, you won’t (in almost all cases) be able to just wait around until they reset (a few days? A week?), and if you do, then it will have to be a strategic choice because you strongly feel you need to speak to a character who has previously shunned you.

Anyway, back to the screen. When you select an option you’ll get a list of every possible topic, and whether you know the dialect well enough to speak that question in that dialect (I’m still working on how exactly that will be “acquired”). These are empty for now, but will be one of the next things I’ll work on. We also see two images at the top of the screen, for the player and the person you’re talking to, whilst the conversation will scroll up (and be scroll-able) in the middle of the screen, with your comments left-aligned and the comments of the other character right-aligned. These are all the things I’ll be putting together in the next few weeks!

Lastly, on dialects, I would also like to add (on a more personal note) how enjoyable it is to be working on the speech generation/conversation system stuff! There’s a real pleasure to be found in starting to work on an entirely new and very cool system, and the past few days have been a great little period of starting to piece the disparate components required together. I’m really happy with how this initially looks and excited to keep working on this in the coming weeks. Stay tuned!

Dialect Generation I: Name Generation

The time has finally come – we’re now onto the final push towards 0.8’s release, URR’s first ever (and quite extensive) gameplay release, which means generating dialects, and then adding in the game’s conversation system. Although this is the final coding task, this is still quite a substantial one, so I anticipate a few months of programming, but it will most definitely be worth it. The first part of this process has been figuring out how, exactly, the dialect system is actually going to work. I long ago decided that I wasn’t going to have nations actually speaking different languages that had to be somehow deciphered; this was just going to produce too substantial an obstacle, and I couldn’t think of any way to implement such a system in a way I’d actually be happy with, so all feudal and nomadic nations will wind up speaking English (with the assumption that the player character is multi-lingual and actually speaking multiple languages, much like many films have the actors speaking a single language whilst the characters implicitly speak several) – however, I am actually going to have tribal nations speak different languages. I think that would offer a small amount of interesting deciphering gameplay, without it overwhelming the rest of the game; I think it would also stress that these are quite isolated nations away from the rest of the world, without doing something to make them seem explicitly “primitive”. So: you remember all those extra font characters in the lower part of the URR font file? Those are going to be deployed for tribal nations, but once translated, they will also have their own dialects.

What all of this means is that the maximum number of possible dialects in one game – if every feudal, nomadic and tribal nation possible spawns – we need around forty dialects. To do so, I’m breaking down “speech” into several categories, with many many variations in each:

Name Style – how names for individuals in a civilization are created!

Phrases – how people from a culture greet others, how they say farewell, how they threaten others, and so forth, which are all dependent upon ideologies, religious beliefs, and the like.

Sentence Detail – how many clauses are usually in a sentence, how much detail people of that culture give when they peak, how descriptive they are, how to the point they are, etc.

Location References – how people in that culture describe locations, e.g. with reference to where people live, to historical events, to natural structures, etc.

People References – how people are described, with reference to civilization, sex, race, hairstyle, clothing, behaviour, weaponry, etc.

Information References – how things like historical events or artistic works are described, which breaks down into lots of subcategories.

These have some overlap, so Information Reference Style #24 will yield more detail if Sentence Detail Style is #21 than #46, and so forth. For this entry, however, we’ll be looking specifically at name generation. I’ve implemented a grand total of 42 archetypes so far, each of which will then vary massively according to the words it uses in its lexicon and the lettering in its consonants and vowels. For instance, if a particular name-type calls for animal words, it will naturally draw upon animal words appropriate to the geographical region the culture originates from; similarly, if it uses religious terms, then it will obviously use words appropriate to the particular religion, and same goes for everything else. Here are some nice lists of names generated for the same civilizations, to give you an impression of how some of these look. Most name-types can apply to any civilization, whilst a small number are specifically dependent upon there being particular ideologies present within that culture. Some of these are quite strange, but there have been some profoundly “strange” (by our reckoning) ways of naming people in the past, and I needed to maximize the possible variety as much as possible.

One archetype, based on Icelandic names:

Xornoka Arnoksdottir

Konnoma Numikssohn

Mollakor Koxxossohn

Onnorka Rommolsdottir

Another, based on “homeric” names:

Brave Hummanir

Strong Rukiomi

Bashful Hunnoruk

Wise Kiomirun

Another, with titles and only single names:

Jartinar, Quiet Fern

Nobboran, Soft Breeze

Ratjon, Red Sand

Bortjaan, Flowing Leaves

Another, with three short names:





Another, with a kind of thematic ownership:

Zapotel of the Great Mountain

Latapota of the Open Sea

Ponzalot of the Winding River

Epolatoz of the Rolling Plain

Another, with animals, places and features:

Feather of the Hawk

Snow of the Peak

Howl of the Jaguar

Cry of the Wolf

Another, for an “exploration” ideology nation:

Crealorn Mountainfinder

Lonopleat Plaintrekker

Nucrea Grasswalker

Teanullo Hillviewer

Another, for an “isolationist” nation:

Highwall Wrattom

In-rampart Ryttoramow

Tallgate Tarroramo

Behind-the-castle Mowrat

And another, with declining lengths of names:

Mertohurtam Murri Mo

Huttomerra Hart Han

Muerhurtammo Mont Mu

Turnamortan Tunna Tor

And many, many other variations besides – naturally, as I say, the sets of consonants/vowels/syllables also vary every time, so even if you encounter the same overall name archetype again, the names themselves will be very different in a range of ways. I’m in the process of transferring these from my development file into the game proper, and so soon I should be able to go around the world map and get these accurate cultural names on every NPC (important and random-in-the-crowd) I encounter on my travels.

Next week: probably some AI improvements from the feedback my playtesters will send me, and then a discussion either of some more speech generation, or thinking about how conversations and styles of speech are going to work. See you all then!

The Final AI Update

Ladies and gentlemen, I am pleased beyond words to announce that, as far as I can tell, all the AI requirements for 0.8 are finished! Now, I must qualify this: there are a number of NPC classes that do not yet exist in the game, but those that do exist perform almost all their actions, although there are a small number of events currently omitted (rare or unique events like religious festivals and the like). What this means is that around 80% of all NPCs now do 98% of their schedules, and I think they work correctly no matter what kind of strange behaviour the player involves themselves in with regardless to moving, saving, loading, spawning/unspawning areas, and so forth. As a result, I am indeed putting out the interim playtesting/bug-finding release in the next few days! If you emailed me asking to be on the list, you should find an email in your inbox with details of how to download the playtesting release, and some things to look for, within the week. For the rest of this blog post, therefore, I’ll go over the final additions and refinements done in the last week, and then from next week onwards, we’ll finally be on to dialect and speech generation! I’m so excited. But, first…

Finishing Castles

On Tuesday, Wednesday and Thursday I finished off everything that still needed to be done for castles, and so as far as I can now tell, all the possible NPCs that can spawn in a castle all function correctly with their schedules, their placement, their tracking whether the castle map grid is spawned/unspawned and whether the castle itself is spawned/unspawned, and so on and so forth. One major issue was with sleeping and waking NPCs, and in a few particular contexts guards who should be spawned sleeping in beds were spawned sleeping at their posts, whilst those who should have been on guard duty at their posts were on guard duty in their beds! This got fixed by copying a line of code which should have applied to all guards, but was instead applying to around 90% of them thanks to a typo. I then ran into some issues with entering a castle after the 1080 time of the day (which has 1440 “ticks”, each being ten “turns”) which is when all the guard schedules should switch over; for some strange reasons, the knights guarding the throne room were struggling to spawn correctly and causing a crash, which had *something* to do with beds, but I wasn’t quite sure what.

The “filled” doors are doors to the outside whilst the hollow doors are within one building, so here we see various guards and conscripts going outside. It’s slightly jerky due to all the debug processes printing, but I think it still looks rather snazzy, and I love seeing such a large volume of people going about their day without the game crashing! (You’ll also see slaves and knights in these gifs also just going about their daily business in the castle)


And then immediately after, the guards/conscripts who were guarding outside come back inside and head to appropriate beds:



Here’s a cache guard switching with another cache guards whilst various other guards/knights/etc on the same timetable also move to wherever it is they need to go in order to switch over:


Guards on upper floors wouldn’t behave

As a result, here are some guards and a knight in one of the towers finding their way down correctly, rather than misbehaving terribly:


I ran into a bug whereby I sometimes ran out of beds on certain generations, but only for knights and guards. It took quite some time to diagnose what was actually happening here, but it finally became apparent that when the smallest possible number of beds spawned in the corner/side towers (four per tower, so sixteen total) and the game was trying to place guards and knights in those towers, and there was a cache in the castle, there simply weren’t enough beds, so the NPCs were stuck trying to find a bed; this meant I had to specifically enable their ability to climb up towers to find another bed, but only specific staircases (because the main staircases are in the main castle, rather than in the towers)! The disconnected nature of the upper floors of castles is unique, and has basically required adding in quite a few exceptions to a lot of NPC behaviour which ordinarliy wouldn’t have to think about impossible paths on a given floor.

After that, though, things went quite smoothly with servants, slaves, and monks. Here we have a basement in this castle containing the castle’s slaves, who were all going about their day most of the time and then filed into the basement as time went by:


And monks sleeping at night in their quarters:


I then turned my attention to priests, who – in castles – can fall into two categories. In religious nations you’ll find a single large chapel with a priest walking around inside, whilst in nations that have freedom of religion you’ll find a large number of small chapels, each with a priest (and altar, book, etc) of the appropriate religion. Here’s a priest wandering around a full-size chapel for a nation dominated by a particular religion (you’ll note various servants coming and going at the same time), and then various priests in smaller chapels in a castle in a nation with a plurality of religions:




And I must say there were some cool religions in this castle. Jaguars for the jaguar god!


Then, servants. They work the same as slaves (aside from being on the ground floor instead of underground), and these worked pretty much immediately thanks to all the code in place for slaves. I then moved onto torturers and jailers, who should be spawning in a different section of the basement, away from slave quarters (if slave quarters are present) and who keep to a very simple schedule. Sure enough, these folks seem to work perfectly well now too. Here’s one of them wandering around (I also really love how under-castle jails look, don’t you?).


And heading to bed:


And here’s a torturer checking out the cells under their control (where unfortunate people will one day appear), and in a later version there will be various unpleasant things in the centre of this room, which will vary from nation to nation (so different nations have different methods of torture, if torture is their thing).


And slave quarters and a dungeon in the basement of the same castle, with two different staircases. This is a rare-ish scenario, but meant I had to make absolutely sure that slaves returning to their quarters knew which staircase to take (servants, being on the ground floor instead of the basement, don’t have this issue)…


And that’s pretty much all the NPCs for castles! In future versions I may add in a couple of extra NPCs, like book-keepers for archives and the like, and also I need to add in concubines at an appropriate point – and the actual leaders themselves! – but for now, castles still appear very active when the player wanders around them, and that’s what matters for 0.8.

Final Check, Final Bugs

The last thing to do before sending out the playtesting release is to active all possible AI actors and spend a little while wandering around the world and trying to break them myself. I’ve now done so, and to my absolute delight, I have thus far discovered that everything seemed to be working correctly, although I do still harbour a tiny, tiny concern that certain NPCs in certain houses might not always appear in their houses at the correct times, depending on the player’s actions… but I couldn’t produce any bugs here, so that’s down to be super-secret super-elite playtesting team to figure out.

I’m also going to implement a few debug tools for my playtesters, so they can now look at a debug print-out which shows all the important NPCs in that area, where their homes are, what their current tasks and schedules and objectives are, and so forth. This, naturally, will not be in the final release, but I thought it was a pretty essential feature to maximize the potential of the interim playtesting beta.

Although I have ever confidence in my team, the complexity of all this stuff does mean it has to be possible that the final 0.8 release will go out with a few minor issues still in place. This would be disappointing, of course, but so long as there are no AI related crash bugs present when 0.8 hits the shelves, I’ll be content – it would obviously be even better if there were no AI bugs of any sort whatsoever, but I’m being realistic. Pathfinding and scheduling is massively complicated already and made even more complex by the variety of permutations of spawned/unspawned/loaded/saved areas the player can bring into existence or push into the background through their movements in the game world, and despite my best efforts, I’m sure it’s still possible for an NPC to duplicate, or to vanish into nonexistence, or something else of that sort. But we’ll see! Maybe the playtesting release will be remarkably stable and nobody will find any problems whatsoever.


Next Week

DIALECT GENERATION! For the next week or two I’ll be working on the underlying mechanics for generating different styles of speech for each in-game culture (in the average game we need to produce around 40 very different styles of speech, and ideally many tens of thousands possible across a long enough stretch of time). I’ve started to draft this in various forms over the last month or so, and so next week I’ll give you all a run-down of what I have in mind here. After that we’ll be onto designing the conversation screen! I’ve also been giving this a lot of thought, and I have some idea how this is going to play out, and how it will connect to the dialect/sentence generation stuff I’ve been quietly putting together and experimenting with in the background. See you in a week!