next »

[Ultima Ratio Regum]

Oh the navigation checkpoint system sounds like such a relief, nice!

Thanks Leonard - definitely! It's an amazing time-saver, and like I say, later I'll let you add your own checkpoints as well. A lot of this release is not just about filling in gaps, but also just speeding everything up...

[Ultima Ratio Regum]

Welcome back everyone!

Lots of new developments again, so let’s take a look:

Buying supplies

When you enter or leave cities you can now stock up on supplies. These take four forms – canteens, food, water, and equipment. Canteens, food ration bags and equipment have generated images while water is a slightly more abstract image. In the case of canteens, these are empty containers that can be filled up with any liquid, and the player starts off with a canteen filled with ten units of water (which allows for ten days spent in desert). The images are of course generated with around a million or so permutations I believe – so hopefully you’ll never see the same canteen, as they are handmade after all! – and are pretty expensive items, but they have a lot of value for exploration so I think that’s justified (again, as more and more gameplay elements come in through 0.10 and 0.11, all of this will need balancing later on). Food is the only one that is needed in the everyday for moving around outside of settlements (except when on ships) and is consumed at a rate of one unit a day, and you buy food in blocks of ten; food, like water and so forth, is not needed when you’re in settlements, but only when you’re out in the wild. The image used here is an alteration of the graphics used for the gunpowder bags, and I’m sure I’ll find some more value for the “bag” image archetype further down the line. Water is bought separately and can be used to fill up canteens, and is again fairly cheap, and required when exploring desert in order to avoid dehydration and sunstroke (see hopefully my next update for info on these sorts of ailments etc!). Finally, equipment is the equivalent of water but for polar and mountainous regions, consumed at a rate of one per day, otherwise frostbite and hypothermia will be lurking just around the corner. I don’t see many games that model interesting conditions and illnesses and I think these will make for interesting strategic considerations (with some light alterations from how these work in real life), but that’s all to come later. Finally, as part of this the player now also starts the game with a supply of food, and a canteen filled with water, but not with any equipment nor any additional canteens.



Location discovery

As part of what I discussed last time – building-specific fast travel – I have also made changes to how locations are recorded. In 0.9 simply setting foot into a map tile would immediately tell you (on the world map) what was in it, i.e. entering a market tile and then going into your world map would tell you precisely what shops were on that tile, even if you (the player character) had not yet actually seen them. This worked fine for a while as a basis but given the new stuff I’ve implemented above about allowing you to fast-travel to specific buildings within a map grid, it seemed to make sense to also go back and make this fine rather more finely-grained than it is at present. To do this there is now a system in place that, while rendering an outdoor area, takes note of any doors you happen to see and then looks over those doors to see whether any of them are noteworthy doors (i.e. they don’t just belong to normal homes, for example). If the game finds a noteworthy door within your line of sight on a particular turn, it then checks to see what that is a door to (e.g. a shop, a cathedral, whatever) and then checks whether or not that building has already been stored in the player’s knowledge of building. If it has then it does nothing, but if it hasn’t, then the game adds it in and posts a little message in the text log below along the lines of “You have discovered a new X”, after which you will then be able to fast-travel back there next time you are on that map tile. URR therefore now keeps track of every important structure you find, and when coupled with the above, this makes exploration – and moving back and forth – almost ludicrously faster than it once was.











Image improvements

I’ve improved a couple of the old generated graphics in the game that just weren’t up to the current standard. Firstly, archery targets are now correctly shaded, which brings them a little more “up to date” with the quality of the other procedural graphics in the game; I’ve also optimised the image code here to make them generate / draw faster, as they were painfully slow. These are an extremely rare thing to see in the game – though now that I’ve put in the time to improve them like this, I am certainly incentivized now to make them appear in a few more places! – but they no longer stand out as a very poor graphic. Similarly, fountains have also now been significantly enhanced in order to bring them in line with the quality of the generated images in the game. These are rather more common so I think this was far more time well-spent, as the player (currently) starts in an upper-class housing district full of fountains, and many of the most interesting areas of cities and the like have fountains. These were not hugely time-consuming things, but I’m glad to have them done; readers will remember that in the 0.9 release I redid the graphics for the world generation because the original graphics were very outdated compared to the quality of visuals I’m making now, and it didn’t really do for the first thing the player sees to be something so rubbish! I’m not sure whether these meet my quality standards for the long-term, but for now updating these just adds a little bit of polish and smooths off a rough corner remaining from the game’s much earlier days.





Flavour messages

As further part of making navigation of the in-game world both easier and more interesting, I’ve taken a leaf from the book of games like NetHack and introduced messages that appear when you enter a new area. Naturally in NetHack (and other games that do similar things, like Spelunky and Noita) the idea is partly to warn the player in advance of something coming up in that area or acknowledge an unusual procedural generation choice, whereas here it is partly about flavour, but also partly about letting the player know that a particular thing might be present in this area which they might want to take note of. At the moment this takes two forms. Firstly, an “introductory” message will now always appear when you enter a district of a city, a town, a fortress, a settlement, and soon on things like mines, universities (see below), etc. This will give you some flavour and will also point you towards important things. For example, upon entering a lower class district in a city, it might say – depending on the cultures / policies of the area – something like…

“You enter the lower class housing district. As you watch the people in this area, you see items and goods often being traded from hand to hand. In the distance to the north-west you see a tall building with barred windows.” (A “barter” nation, and a prison with its location identified)

“You enter the lower class housing district. A call to prayer is being sung out from the north-east, and to the south you hear the roar of a crowd.” (A location hint for a religious building, and a location hint for an arena)

“You enter the low class housing district. You hear people talking about the outside world, and notice that their comments doesn’t quite match up with your ideas of lands beyond this one.” (An “isolationist” nation)

…and so on. By my calculations there are many hundreds of thousands of these possible messages across different locations with different sets of combinations present, and just from doing my own playtesting around the world these add a real lot of texture and feel to the world, and give a sense of greater weight and consequence to each particular area the player might go into. When coupled with the discovery messages mentioned above, the message log in URR is now far more full and far more active, and has things constantly being told to the player rather than just an endless sequence of “it is a new day!”, which can seem a little bit silly sometimes. I think these are a really important addition for, again, speeding things up, helping the player have a sense of where they might want to go in that area, and also deepening this sense of the world being a little more alive and a little more active as you walk around it.





The other sort is what I’m calling “ambient” messages show up every x turns since the last message has showed up, and take a similar form to the above messages, giving you information but on a much smaller scale. So, for instance, in a city centre district you might see messages like…

“You hear nearby an argument between some clerks about taxation for the outer areas of the empire.”

“You see in the distance an individual wearing fine clothes, who seems to be an emissary of some other land.”

“You notice a fine ring on a local passerby, marking them out as a person of high rank.”

…and so on. These again depend on the specific of each nation but are far less general than the first kind and don’t point to anything specific, but give a lot more life to each area. I’ve written a large number of these, including allowing them to vary and change depending on the specific place and context, and there’s also code in place to make sure that they don’t repeat too soon. Both of these systems are relatively small additions, but I’m actually really happy with how they’ve come together, and they give a heck of a lot more life to the world! Also, in the case of these ambient messages, the game keeps track of which ones have been recently used and doesn’t recycle until a large number have been gone through; it also slightly randomly generates the precise wording of each one in order to boost variation; and the time between these messages gets longer the more time the player spends in an area, in order to make the full selection last longer and because a player spending quite a while in one map area is probably working on something specific, rather than necessarily exploring. I think these are another really nice addition, and while the database of these isn’t finished as I write these – though there’s already hundreds! – I’m really happy with how these have worked out so far.

(A large number are shown in these testing screenshots, but in practice, they are far rarer, and have more variation in phrasing!)







Starting Relic Generation

One of the objectives for 0.11 will be generating religious relics. These will be very important items, having a lot of value (obviously) to particular religions, but also a lot of trade value if you can find the right people to sell to, a lot of potential for religions to become very pleased with you if you are able to return a relic that perhaps is being sold in a distant land, and relics will also sometimes be the rewards that one can get for figuring out the location being referred to in a treasure map. I’m really keen for these all to be very interesting, striking, distinctive items, that really get the player’s attention and signal clearly that this is something of high importance. As such, I have begun laying out the basic foundations for generating the images of the relics. As mentioned previously there are now several dozen different archetypes for religious relics, some tethered to particular archetypes of deity or religion (e.g. a “Lovecraftian” relic or a “Demonic” religion) while others can appear for any religion type, or most of them. I have posted a bit about how the image generation process in URR works before – both in the sense of “how do I design them?” and the sense of “how does it work under the hood?”, and I’ve just been making a little bit of progress beginning to sketch out some very basic initial text grids. Even without the slightest degree of colour or shading or anything else, some of these initial drafts are already giving a sense of how interesting and colour and distinctive some of these items are going to be, and I’m really happy with this initial groundwork I’ve been laying now for next year.



University planning

I’ve made a major decision here for the game – given that the game is / is going to be about information, discovery, exploration, reading, cryptic puzzles, etc, I’m not sure any more how much sense it makes for the player to begin the game in an upper-class district, or to begin the game in any way as part of a noble house. I’ve also been thinking for a while about adding in “university” areas to the game, similar to “towns” or “fortresses” or “mines” and so forth, and the more I think about it, the more I like this idea. I think starting the player off in a university would be a very novel opening; would enable me to develop a very cool and interesting little opening cutscene (which I will say no more about until I start working on it); and would give the player a very clear framing about what sorts of thing this game is about. It would also be a logical way to get the player started on the main quest and to give them a few initial items – maybe a book or two, a note or two, a cryptic item or two – to help them out on the start of their journey.

My current thinking right now is that universities will contain classrooms, halls, student accommodations, libraries (maybe you can pay to access any book there, but it costs more than finding the book in the wild and buying it? Would be strange in the real world but makes more sense in gameplay terms!), study rooms, maybe a museum of some noteworthy items (the University of Sydney, where I’m based IRL, has a number of these), and I think an observatory will be a cool addition as well (but I won’t say any more about that just yet). They will also vary, of course, across nations depending on their policies. For example, the university in a nation with “populist” politics is probably going to be quite limited (no intended commentary on the real world inverse relationship between educational attainment and voting for populist candidates should be inferred) whereas a university in a nation whose culture is far more focused on intellectual and cultural attainment will likely have a far larger university. Nevertheless, all nations will spawn with one university – for the player to start in – while I might perhaps have more intellectually inclined nations to have an extra university or two elsewhere in their territories. Like towns and mines and the like, these structures will be outside of cities and will be found somewhere in that nation’s territory (though I’m going to set them to generate near to the city to encourage new players to head into the capital city of that nation first when they depart the university starting location).

Anyway – at present I’m not sure whether this will be something for this 0.10 release, or for 0.11, but I’ve begun sketching out the initial code required to generate these areas, populate them with people, etc etc, and I’m really keen on this rather more novel start than what we currently had. More on this in the near future, I am sure!

Bug fixes / tweaks / etc

- Resolved a long-standing bug that somehow neither I nor any player had noticed for years (!) in which, rarely, the last letter in a sentence in a multi-line message would be chopped off and not displayed in the message window. In fairness URR has until now had very few multi-line messages, but I still can’t quite believe how long this one survived for!
- Fixed a bug with animal-archetype religious altars barely having any colour distinction between the background and the foreground of the altar and the design on it – it was very hard to make out the image, but is now much clearer.
- Given that I’m actually looking to do a big overhaul of the dialogue system to make it far more fluid and “human”, I’ve temporarily removed the variable questions (“What do you think of [X]?”) with the intention of coming back to them in 2023. - - The initial work on the questions and the replies however will still be useful – it just won’t be in this release!
- Fixed an issue with certain items very rarely not possessing the properties required to draw them correctly when in the player’s inventory, but only if they were added in a very specific manner.
- Dealt with a bug that very very rarely caused world generation to crash when it was trying to figure out embassies in city centres for certain kinds of civilizations (or rather, civilizations in certain contexts).
- Put in a few more optimizations and improvements to the systems that draw the terrain around the player when the player moves; I am keen to really improve this further in the future, but another little set of small refinements here again supports the objective of making the whole game a bit faster, a bit smoother, and a bit easier to navigate.

What next?

I’ve decided to shift releases to January instead of December, because releasing between the 25th of Dec and the 1st of Jan doesn’t really get much visibility because people are, generally, busy during that time. I’m therefore going to try a model of instead releasing “some time in January” the default going forward, and we’ll see how that goes. My next objective is to working on food / water / equipment consumption out in the wild, and start programming in some dreadful maladies to befall the player should they venture too far beyond their means; I’ll also in the next few weeks be working on bug-testing and refining these above systems and the ones from the previous updates, and working to clear out more bugs and polishes on my larger list of these as well. Next update in a couple of weeks, everyone!

[JobLeonard]

One of my favorite games of last years (Heaven's Vault) starts in a university, and it shares more than a few themes with this game actually, so you'd be in good company! I'm sure you've heard of it, but if now here are some really nice articles on the game:

https://archaeogaming.com/2019/01/25/an-interview-with-jon-ingold-of-heavens-vault/

https://archaeogaming.com/2019/04/16/the-archaeology-of-heavens-vault/

Actually, are you famililiar with archaeogaming.com? They have some really nice articles on archaeology in games, maybe interesting for you to see others tackle this topic you're working on.

Will there be university politics too?

The new fountain looks great, and it's crazy how a "simple" gradient improves the archery target.

Good work with the perf improvements! It can be a pain to do but it's sooo satisfying to see things run smoother in the end, no?

[Ultima Ratio Regum]

One of my favorite games of last years (Heaven's Vault) starts in a university, and it shares more than a few themes with this game actually, so you'd be in good company! I'm sure you've heard of it, but if now here are some really nice articles on the game:

https://archaeogaming.com/2019/01/25/an-interview-with-jon-ingold-of-heavens-vault/

https://archaeogaming.com/2019/04/16/the-archaeology-of-heavens-vault/

Actually, are you famililiar with archaeogaming.com? They have some really nice articles on archaeology in games, maybe interesting for you to see others tackle this topic you're working on.

Will there be university politics too?

The new fountain looks great, and it's crazy how a "simple" gradient improves the archery target.

Good work with the perf improvements! It can be a pain to do but it's sooo satisfying to see things run smoother in the end, no?

Thanks so much for the comments Leonard! Heaven's Vault is on my to-play list, I'm really excited about giving it a look in the near-ish future. University politics, haha... maybe, but probably not! I get enough of that in my real life . And re: performance, it really is. There are still some BIG optimisations I want to get in either for this release or as part of the next one, and they're so desperately needed. The game runs "okay" but some parts are shockingly slow, particularly generating a map grid and printing the right characters on screen as the player walks around. These need working on...

(Oh, and - yes, but I haven't checked it in a long while! Time to do so...)

[mobilelast]

Extremely interesting and ambitious project.

I’ve done some deep procedural stuff (mostly about genetics) previously, and have a lifelong interest in world generators. But I’ve had a hard time finding a starting point for such a project; perhaps I just haven’t been interested enough.

There seems to be lots to read and learn in this thread. Maybe it restores my passion (along with the Dwarf Fortress Steam release).

[Ultima Ratio Regum]

Extremely interesting and ambitious project.

I’ve done some deep procedural stuff (mostly about genetics) previously, and have a lifelong interest in world generators. But I’ve had a hard time finding a starting point for such a project; perhaps I just haven’t been interested enough.

There seems to be lots to read and learn in this thread. Maybe it restores my passion (along with the Dwarf Fortress Steam release).

Thank you mobile! I really appreciate the feedback and the kind words . I know what you mean, it can be hard; my starting point was, to be completely honest, "I'd like to make a game like Dwarf Fortress!" but has long since evolved into "let's make a giant procedurally-generated puzzle / riddle game set in the Renaissance / Scientific Revolution". I honestly think that starting out in the footsteps of those who are already doing these kinds of games can be completely valid as a method for figuring out what *you* want to do yourself.

[Ultima Ratio Regum]

Lots more has been coded in the past couple of weeks, so let’s get to it!

Supply consumption and use

I have now implemented an initial working draft of supply consumption use as you walk around the game world. So first off, here I am after a few days of walking around in a city (exactly 24 hours / one day increments each time you change map tile, whereas it’s in moving around on a map tile that moves time forward on a minute-by-minute level) and you’ll see that there are no messages in the message window talking about the fact I’m consuming food, and the counters for my three types of supplies in the sidebar are greyed out. Whenever you are in any kind of settlement – city, fortress, town, monastery, even a farm or a mine or (later) a university, you will not require supplies, the rationale here being that you’re able to get food and water in the place you’re staying.



However, I’ve now moved out of this city and two immediately important things are happening. Firstly I am using one ration of food per day as I move around (see the message log on this), and also the relevant part of the sidebar is now lit up to emphasise that these supply considerations matter because the player has now journeyed outside a settlement of some sort.



Later I find my way to a town, and although I’m not exploring it in foot, entering it is enough that my next movement will not cost any food (or water or equipment were I in desert, or polar / mountainous, terrain) because I’m in a settlement.



I then leave again and keep exploring, and two important things happen here. I find a desert, and roughly as I enter the desert, I use up my final food ration and the game gives me a warning to let me know that I’ve used up all my food supplies, and that unless I eat soon I’ll be in danger of two illnesses. A lack of food, a lack of water, and a lack of equipment, now all come with two potential dangers. A lack of food can bring on malnutrition (weakening the player) or starvation (potentially fatal); a lack of water in the desert can bring on dehydration (weakening the player) or heat exhaustion (potentially fatal); and a lack of equipment in polar or mountainous regions can bring on frostbite (weakening the player) or hypothermia (potentially fatal). I’m still working out the exact gameplay impacts of each of these – while also keeping in mind that combat will be coming soon and so I need to think about some of these in terms of effects to the player character’s body, abilities, etc – but this message is the warning that the first of these might be on its way before too long.



A few days later – note again that the messages are telling us we’re using a water ration with each step we take in the desert – we also run out of water, and are now in danger of both malnutrition and dehydration. Oh dear!



The same is also true for your use of equipment in mountainous or polar terrain:





There are still a few minor bugs I need to iron out here involving some potentially unusual map movements always correctly consuming supplies, and making sure that the sidebar is always correctly grey / not-grey depending on where the player is, but this is all coming along nicely.

General messages finished

Next, I’ve now finished the general messages that can appear when you’re just wandering around. This had several parts. Firstly there were a number of message contexts that I hadn’t finished writing out when I posted the last update, particularly potential messages for if you’re out in the wilderness (i.e. you are not in a settlement of any kind) and also potential messages for some of the more obscure cultural possibilities and combinations within a given civilization. Secondly I needed to implement a system to make the initial words in each one actually vary, and so rather than them all saying “You hear people” or “You hear someone” you will see in the screenshots below way more variation here in how the messages are actually framed and presented by the player. Thirdly, I needed to add a system that keeps track of how long it has been since you entered an area, and how long it has been since you’ve seen an ambient message, and to have that tick up over time as you’re going around and doing whatever you’re doing in a given area. This took a little while but wasn’t too difficult, and the game now works hard not to repeat these messages and also not to swamp you with them. Fourthly and lastly, and related to the last bit of the above, there is also now a system to prevent the same message from appearing twice even if the exact wording would be slightly different, so you can’t get “You hear a distant argument” and “You find yourself overhearing a distant argument” in immediate succession. I’m very happy with how these are working, and they definitely bring some nice extra life to the game world!





Bookmarks

You can now save your own bookmarks in any area in order to fast-travel back to that bookmark! You can do this by pressings the ‘B’ (or ‘b’) key and in each area you can, at present, place up to five bookmarks of specific tiles; when you do so the game asks you to select a description from a large number of presets (rather like the messages system in From Software games, except without quite so much potential for euphemisms) and to say what direction you should begin looking when you come back to this area. You might, therefore, save a bookmark as “Mystery Plant” or “Strange Statue” or “Important House” or “Cheap Merchant”, or whatever it might be. Any bookmark, once saved, is then added onto the end of the list of fast travel locations when you re-enter that district, so you can go straight to a shop, for instance, or instead go to the bookmark you placed in a location where you think something important might be buried, or which might be outside the home of an individual you think might be very consequential. You can also place bookmarks in areas that aren’t even settlements, so if later on you find something strange in the wilderness and want to come back to it later, you can put a bookmark on that. I really like this system, and again, it’s just another little quality of life thing that will start paying dividends more and more in the coming years or two of development. I haven’t yet programmed in the ability to return to them (that’ll be coming shortly), but the ability to save them is now fully implemented. So first you press ‘b’ and select a tile with the crosshair, shown here to the right of the player:



Then you put in the name for the bookmark you want:



And then your bookmarks, up to a maximum of five per map grid, show up on your map:



I’m really happy with this! In a game that is going to be all about information, discovery, exploration and the like, the more systems I have for the player to keep track of things, the better.

Plants

Now, let’s talk about plants. For several releases now the game has had appropriately generated images for plants in farms, with an appropriate range of permutations and the like. Although these were actually pretty early in the whole procedural graphics thing, I remain very happy with how these look (especially as a lot of standard farm vegetables and grains are surprisingly hard to make into interesting ASCII-esque graphics).



However, this doesn’t cover procedurally-generated plants which should be filling the game world, varying according to area and climate, and (like everything else) potentially being a part of a puzzle (e.g. maybe a riddle directs you to a place where a specific plant grows in immense numbers?). The original intention (And by “original” here I mean “in the early to mid 2010s”) was for plants to be important things that one could pick up and use to craft various things (this is obviously a common idea in many games), and back when URR was essentially a Dwarf Fortress clone, I was really inspired by the use of plants in things like Ancient Domains of Mystery and Skyrim, and felt this would be an interesting addition. I seem to recall I even – although sadly I can’t find the documentation now, ha – that I developed some interesting systems in my head for how plants would spawn, spread, potentially interbreed creating new strains, all these sorts of things. However, as URR moved away from “Dwarf Fortress clone” to “procedurally-generated clue-finding mystery”, I abandoned this and binned it. Nevertheless plants could appear on the map, denoted by a different symbol to the normal grass or savannah terrain or whatever it might be, and the game would generate names for plants that would be found in appropriate local areas. However, at some point I removed plants from the maps altogether – I think they were causing generation issues of some sort? – and somehow after five years I haven’t got around to putting them back in. This is particularly strange because the presence of plants as a terrain “type” was actually quite important for making some areas – such as city centres and upper-class housing districts – look a little bit swankier or more interesting, and without them some areas do actually look surprisingly sparse. Then, finally, because I just wasn’t sure what role if any plants would play (wanting to avoid implementing any kind of mechanic that encourages tedious grinding or searching around for valuable plants in a see of useless ones), I just shrugged and decided that I would figure out what the heck to do with plants at some later point.

Well, that time has finally come, and now plants have returned to the game-world and are merely decorative aspects to make parts of the world a bit more interesting. They now show up on the map and make areas look, frankly, a lot more interesting with these involved. It took a surprising amount of wrangling old code to get them to appear again, but here they are:









Don’t they add a ton of colour to the world?! Even better, though, is the fact that we also now have an image generator for all in-game plants! Whereas previously this was limited to the plants in farms – which have a relatively small number of possible visible permutations – this has now been extended to all of the game’s generated plants as well. Each plant essentially has three generated components based on the name of the plant. The first word – e.g. “lush” or “bristling” or “budding” or “broad-leaved” – determines what the stalks of the plant look like, how many leaves they have, their size, their number, these sorts of things. The second word or the first half of the second word – e.g. “azure” or “sun” or “somber” or “copper” – determines the colour of the flower, and also the colour with which this plant will appear on the human-scale map (as above). The third word or the second half of the second word – e.g. “lily” or “cup” or “flax” or “thistle” – determines the shape and size of the flower that the plant has. Combine these three, add in some general variation in stalk colour and some low-level grass and turf in front of the plants, and, kaboom! We have procedurally-generated plants, where the name of each plant and its geographical / climate distribution is determined during world generation, and you can now find them in the game itself.



The stuff at the bottom also varies of course based on the terrain the plant spawns in, so you might get things like this:



There are many thousands of possible generated plants, and as with everything else these will potentially be mentioned in clues, hints, riddles, and so forth, and I’ll be working on other ways to give you information about the local flora (and later fauna) too. Again, as well as adding lots of life and colour to the game, these – like everything else – will be in the pool for potential clues, such as hints pointing you towards areas where a certain plant grows, or areas where the plants are certain colours, or even second-level clues like one that mentions the plants researched by a particular scholar, and you need to study that scholar to discover the plant they studied, and then use that to discover where something might be located. And so here, finally, are some examples of the player in-game checking out some of the local plant life:









I have to say I’m incredibly happy with these, and with them appearing on the map again, they really add a ton of new life into the game world.

Bugs / polishes / etc:

- Given that black markets don’t actually appear or generate in game (and maybe never will, we’ll have to just see whether I can think of an interesting and worthwhile way to integrate them), they are no longer listed as appearing in districts.
- Resolved a number of lingering issues with several of the fast travel mechanics in cities, such as a Currency Exchange building in a market district adding to your fast travel list multiple times, the homes of noble families not adding correctly, castles failing to place you at the correct door when you fast travel to them, and various other minor issues.
- Fixed a bug where farmhouses would appear surrounded always by some other kind of terrain rather than the local terrain of the map grid they’re on. This was a rather strange one and I’m not entirely sure what triggered it, but it has now been resolved.
- Fixed a bug where sometimes a mysterious plant would appear in farms called “livestock” and the game would utter the immortal sentence “this is a clump of livestock”, which makes absolutely no sense at all.
- Cult shrines in cities no longer take a random potential shape for their basis, but instead use the appropriate shape that their home nation likes to use in its aesthetics.
- Fixed a laughably long-running (and often reported!) bug with the area of vision around the player being just one tile miscalculated when you’re facing in one of the four cardinal directions. I can’t even imagine how long this one has been here, but it’s gone now!
- As well as ‘?’, the Guidebook is no longer accessed via ‘B’ or ‘b’ (as those are now needed for the bookmarking function), but rather by ‘G’ and ‘g’.
- Fixed one of the last lingering bugs from the conversation from Python 2 -> Python 3, which is that (for some reason) the colours of water in the game (rivers etc) are all basically an identical blue, rather than a nice variation of lighter blues and cyans and so forth. This has now been resolved, and water looks rather lovely again now.
- Also done the equivalent of the above for lava, and now lava (on the rare time one actually, er, climbs a volcano?) shows up as a nice mix of red and orange colours that change each turn, rather than a uniform dull red.
- Fixed a bug where you could very rarely get on a ship without actually having the required money to pay your way.

What next?

Next I’ll be working on the illnesses and ailments that you can get while out exploring the world, polishing how supplies are used (in both gameplay terms and data management terms), and starting to look at how we can get some more optimizations out of the game, both in terms of map generation when you enter a map grid, and in terms of showing that map on the screen. Looking at the code now with my old (early 30s) eyes I see my earlier (early 20s) attempts to be, frankly, abysmal, and I’m sure that there are huge improvements to be made here. Again, 0.10 is a release for making everything faster, smoother, easier, and this is a big part of that. More in a couple of weeks!

[a-k-]

Gorgeous as always! A special mode for playing the game without resource limits or combat would be cool, will there be any cheats?

[JobLeonard]

Oh wow, what an update! Food system! Fast travel! The plants are back!

I feel you on the general messaging system - I've only done a few simple simple game-jam games in the past but even then I've noticed that I never managed to get satisfying system for in-game messages running. I mean I get a system, but not a satisfying one.

[Ultima Ratio Regum]

Gorgeous as always! A special mode for playing the game without resource limits or combat would be cool, will there be any cheats?

Thank you! Not planned at present, but combat is going to be extremely optional . I actively like the idea, however, of this huge game world where you *cannot* visit it all (like in real life, no matter how much of a traveler one is) - there will always be things unseen and undiscovered, and one has to make decisions about what to visit, and what to perhaps overlook.

Oh wow, what an update! Food system! Fast travel! The plants are back!

I feel you on the general messaging system - I've only done a few simple simple game-jam games in the past but even then I've noticed that I never managed to get satisfying system for in-game messages running. I mean I get a system, but not a satisfying one.

Thanks Leonard, I really appreciate it! Yeah, I agree totally. I've been playtesting the general messages quite a bit and I'm honestly really happy with how they work.

[Ultima Ratio Regum]

Hello! Since the last update I’ve made some major progress on a large number of major optimizations and improvements to the code and speed of the game, and in also in the development of new features, for URR 0.10. So, let’s have a look:

Field of view / map drawing optimizations

The first place I found to improve matters was in discovering that the fov computation was going significantly beyond the actual scope of the area the player can see. In URR you have a directional field of view, so what the player is able to see is dependent on which of eight directions (i.e. the eight main compass directions) they are facing, with a roughly 140 degree range of sight. Given the range of the sight coded into the game, this realistically meant that the player can see around 18 tiles in any direction at any given time. By this I mean they can actively see what is going on there, i.e. that area is lit up; of course if the player has previously explored some larger area they can see what buildings and terrain and so forth are there, but they are not actively seeing it, i.e. they are not seeing whether NPCs are moving around in it. Here are some examples of what this currently looks like:





So, even though the player cannot see things actively beyond eighteen tiles or so in any direction depending on what direction they are facing, I discovered that the fov calculation was using numbers more like 25 in each direction. So when the player is facing north, they can see a maximum of 18 tiles to the north and fractionally under 18 tiles to the west and east, meaning that the extra 7 or so in each direction are being unnecessarily calculated each turn. I recognise that I implemented this because we need a small buffer of tiles outside the player’s vision range to ensure that a tile which was visible the previous turn, but is now not visible, is correctly rendered not visible – but that needs to be only one tile (or two tiles to be absolutely confident), not seven. The initial and quite rapid improvement I was able to make was therefore really tightening the area around the player where these calculations are taking place, leaving only the slightest buffer of tiles which might have changed between this turn and the last. This saved a little bit of time on each calculation, but there was clearly more to be done.

The second optimisation was to notice that in the field of view code, a particular calculation was being done twice. There were some lines of code which in essence asked “if [calculation] < x, then do y”, and then if that was returned as a false, the next line was “else if [calculation] > x, then do y” – but it was doing the calculation again. This is a common mistake I made as an early programmer and lots of this code is literally a decade old or close to it, and was of some consequence here as this was a relatively computationally-demanding calculation that was definitely slowing things down by virtue of being unnecessarily run twice. It was therefore a trivial fix to just have a single calculation done for each tile and then have the outcome of that referenced twice, instead of doing the calculation anew each time. This again saved a handful of milliseconds on each fov calculation, but there was still more to be done.

The next optimisation was the realisation that there is actually a significant chunk of area which does not need calculating again each time. Take this diagram for instance (I’m doing all these diagrams in desert areas as they are the most devoid of stuff that gets in the way, and hence the clearest):



In this diagram imagine the red circle as being all the potential areas that the player might be able to see in (with a tile or two of buffer), and the green being the only area that needs to be calculated on this specific turn, i.e. the part of that red circle that the player is dealing with, as well as a small buffer on each side for any tiles which were visible and now should not be. My next big realization was that unless the player just changed height and some things might now be hidden over a hill that were previously visible, or the player has just entered a map tile for the very first time and hasn’t yet moved around within the map tile, or the player has just turned around and is looking at something that wasn’t in the green rectangle from the previous turn, then nothing within the blue square needs to be calculated each turn!



This seems a bit counter-intuitive, so let me explain. The player enters a new map grid and everything within the green rectangle is calculated and presented – all well and good. Then the player takes a step forward – whatever they might see has already been calculated within the green rectangle precisely because it has that 1-2 tile buffer around what the player is actually seeing that turn, and therefore it is the edges that need calculating again (as the green rectangle moves onto previously untouched tiles) – but not the middle. More broadly, generalising this to all directions, we could note that once the yellow rectangle is calculated on a given turn, anything within the blue rectangle does not need to be calculated on the following turn (again unless the player is changing height on the map, for example). This then looks like this…



…and all of this led to this realisation that because the buffer is always being calculated around the edge of what the player can see, whenever the player moves into those already-calculated areas (i.e. they become part of the blue rectangle), they’ve already been calculated! This was a big breakthrough, although it took a while to implement all the exception cases as mentioned above – the player first entering a map grid, the player changing height, and the player changing their facing direction, all require the blue rectangle to be calculated afresh. Nevertheless, this overall reduced by half the time it takes the time to calculate field-of-view stuff for the player! FOV calculations started at around ~15-18ms per turn; the previous optimizations had reduced it to something like 13-15ms/turn; and this reduced it down to around ~4-6ms/turn, and around ~10-11ms/turn when the player is, indeed, changing height.

With all of this done, it was then time to turn my attention to how the game prints this stuff on the console for the player, i.e. the actual playing of specific characters with specific colours. There was one obvious initial improvement to be made here – much like in the field-of-view context, the game was printing (and therefore re-printing) characters in slightly too wide an area compared to what might actually be changing on a player’s given turn. I reduced these numbers to just take in the barest of margins with a small buffer and this bought us a few extra milliseconds of grace on each calculation – but again, this was only the start. Looking over the code with a fresh eye I then noticed that there were a number of places where “player.z+1” and “player.z-1” were being calculated over and over and over, so I again just made that a pair of initial calculations, which between them maybe saved us a millisecond (but every little helps!).

I then discovered a piece of code that was actually completely superfluous under the new developments and improvements that I’d put in. There was a calculation being made for – I think (!??) – checking whether something was not in your fov but was a little bit outside of it and needed updating (I’m genuinely uncertain what this ancient code was for), but I discovered that disabling it changed absolutely nothing (I tested this at length!) and saved us another few milliseconds, so that mysterious line of code was out. I also then found that when the player was facing in a diagonal direction, i.e. northwest / northeast / southeast / southwest, a small optimization could be added by identifying the corner of the screen that is opposite from the direction you’re looking and automatically assessing that as an area that by definition must be out of vision, rather than doing a relatively complex calculation over every tile which would lead to the same conclusion. Again, removing this mysterious bit of ancient code another millisecond or two on average saved.

So: when I started work on this it was taking ~20ms to calculate the field of view each turn, and ~60ms to print what the player saw (and then on top of that it had to take the time to have all the NPCs in an area have their turns, etc). After about a week of work it now takes around ~5-10ms to calculate the field of view each turn and around ~30ms to print what the player is seeing. This is a more than 50% optimisation! I confess to being very, very happy about all this. My skill in programming is – to put it mildly – not to be found in this kind of deep optimisation / clean code sort of stuff, and I generally find it quite dull to work on this kind of deep-level stuff and it’s relatively unrewarding in m brain, as well as being the sort of programming that just doesn’t really resonate well in my mind compared to the more creative stuff. Given that general orientation to this kind of work, I’m actually pretty proud of myself for finding the brain space and energy to get this done; for finding so many solutions for improving the speed with which the game runs; and for the overall result and the > 50% saving of time in the fov calculations which the player has to encounter every time they take a movement. A lot of this release is about optimisation, about small improvements, smoothing off some of the rough corners and making the whole game just a smoother and easier experience to play and to navigate and to find your way around in, and the game really does run so much faster on the back of this. I’m very satisfied with all these improvements and all the workarounds I was able to find here, and I really think everyone will find the world a far more pleasant place to navigate as a result, especially when coupled with all the new options for fast-travel and all the new options for bookmarking and all the map generation optimisations I’ve also put in this week (see below!).

Map grid generation optimisation

My second main target for optimising the game’s speed came in the last week via working on map grid generation. To begin with we would note that this shares two main characteristics with the turn-by-turn rendering of the game world: this was code I generally wrote around a decade ago, and this is code that is incredibly slow for what it does. When I started work on this the average map grid took around 12-20 seconds to generate which is absolutely shocking for an ASCII game. Each map grid does admittedly consist of 40,000 tiles (200×200) but that should honestly barely take any time at all for a modern computer to create and fill with stuff according to some appropriately-scaled code. My goal was to get everything down to under five seconds and the lighter map grids – such as those which are just wilderness without buildings and NPCs and all this other stuff – to ideally maybe three or four seconds. I am unbelievably pleased to say that this has now almost been completed, with every map generation certainly now taking below eight seconds, and wilderness maps generally only taking five seconds – and there are certainly more optimisations for come. For now, though, I’ve managed to hugely speed up map generation in three major areas:

Terrain Dithering

Firstly, one area which I found was taking between two and five seconds (!!!) to generate for each map grid was the dithering of terrain on the edge of a map grid. What I mean by this is that if you enter a map grid which is savannah, for example, but the map grid next to it is a different type, such as tropical or desert or temperate, then the game will dither the terrain at the edge of that map grid in order to ensure a sense of a smooth and gradual blending between the two areas. This generally looks something like this, with the other terrain type becoming more and more pronounced closer to the edge of a map grid:







To my absolute horror I discovered that the method I developed for this when I was 22 and had barely finished the Python roguelike tutorial was to have the game go over the entire 40,000 tiles, calculate a random chance on every single one, calculate what possible terrains it should be on every single one, and then decide which of those terrains (if any) the existing default terrain for that map grid should be changed to. This is frankly atrocious and uses a staggering amount of wasted time engaging with tiles, and doing calculations on tiles, that don’t actually have anything to do with creating the intended dithering effect, especially if the dithering is only required on one side or even one corner of the current map grid. Instead, I have now created large sets of tile lists for each possible dither (each side, each corner, so eight in total) and if that side or corner needs to be dithered, the game goes through that set and dithers the tiles in that set. This means that no unnecessary tiles are touched by the algorithm, no calculations have to be performed over and over, and the final effect is literally indistinguishable from the earlier version. This has taken the time required to dither from potentially as long as 5 seconds (5000 milliseconds) all the way down to 0.1 second (100 milliseconds), with no loss of functionality! This is a massive improvement and I honestly can’t believe that such a catastrophically awful and time-consuming section of code has remained in there for so long – but either way, it’s good to be rid of it.

Spawning Plants

The next thing was to take a look at how plants were spawning. They had a similar method to what I’ve just described above and were carrying out a ludicrous number of calculations on every map tile, especially when we consider that relatively few map tiles actually end up having plants, especially in areas like deserts and tundra regions. These were therefore reworked in the same way as above, giving us a list of potential plant locations – where the list is of a sufficient size – in order to skip the tiles that don’t actually need to be addressed. This process took an unconscionable five seconds or so under the previous model, but now takes between 100 and 200 milliseconds (a tenth to a fifth of a second). Another huge improvement! Reworking how plants spawn also required me to interact with some other systems for spawning plants with certainty in specific places, such as gardens or other arrangements in upper class, middle-class or city centre districts, rather than (or as well as) just spawning them randomly. Some of these were actually fairly efficient already, but others needed a little bit of refactoring – again generally just changing them to a list of potential tiles, instead of iterating over every tile on the map – and this saved us a little bit of time here and there again.



Spawning Trees

The third area I’ve found so far for making huge time gains during map generation is in the placement of trees. The existing model was, again, alarmingly similar to the plants and dithering model – go over the entire map, do loads of calculations on each tile to decide whether a tree should be appearing there, and then eventually place the tree itself. Instead, therefore, I deployed a new model where the game now has a set of lists of potential locations for trees, and for plants. There’s a large enough number of these lists (and more than enough other stuff that varies with each map grid generation!) that I can’t imagine a player will ever spot when it’s repeating, but essentially it’s a long list of tuples – e.g. “(125,17)” – where trees or plants might spawn. A new map grid coming into existence selects one of these lists and then attempts to place some trees and some plants by looking at each tile according to the list (which totals only a small percentage of the total tiles on a map grid), rather than iterating over every tile on a map grid and running some randomization decision about whether or not some kind of plant should be appearing there. In other words, the old version tried to place a tree 40,000 times per map grid; the new version tries, at most, 1,500 times, and each of those attempts is more efficient than each attempt in the 40,000 attempt model. I think it’s not hard to see how much snappier this now is! The original version took 3-4 seconds while this new version is down to around 0.1 second, again with no change in the final effect or how things look when the player explores a given map grid.



Fast travel within a map grid

I’ve also been further refining the fast travel system. You can now fast travel to any of the important areas you find in a map grid (all the areas in your starting civilization being as pre-explored) but I’ve also now implemented a model whereby you can fast travel within a district. Pressing ‘T’ to travel, but then not moving outside your current district or town or whatever and just pressing enter instead, will again bring up the list of potential fast travel locations. You can then pick one and the game will quickly increment the required turns to get you there, and put you in the appropriate place, without having to reload the area. This again will help you get around faster (as I’ve said before, a lot of this release is about speeding everything up and making the whole game faster, easier, smoother, more user-friendly) and is a really nice improvement to assist in getting yourself around the map. Here’s are two gifs of me doing this in a town and in a city:





(If these gifs seem slightly “slow” given all that I’ve been hyping up speed improvements, don’t be alarmed – the gif recording slows things down, and there are debug messages playing in the background, but without both of these the in-district movement is genuinely *cracking* along!)

[Ultima Ratio Regum]

Farms, fences, hedges

With plants now fully implemented I want to start laying some early groundwork for animals. As such, I spent a couple of hours preparing some areas in the game’s generated farms. As well as plants and orchard areas, plants can also spawn with “blank” areas, i.e. fallow fields with nothing currently growing.



Half of these are now labelled instead as “livestock” areas instead of “blank” areas, and the first thing to do was to wrap a fence around them. A little bit of work quickly generated a system that could easily identify the limits of one of these farm quadrants:



And then a little bit more work enabled me to generate and place one of two new feature types, either fences or hedges. Here’s an example of a fence…



…and here’s an example of a series of fields enclosed by some hedges:



(And yes I know there’s a minor fov error in one of these screenshots, but it has since been fixed!). Each of these now finally implements the graphics for these that I’d generated during 0.9’s development cycle, so you can check those out as well:





This is all obviously just a very minor addition, but one that didn’t take up much time, adds some more variety, and prepares things for a later release as well once animals (wild animals, domesticated animals, horses the player can hire / ride, etc) come into being.

Bookmark fast travel returning

Lastly, in the previous release I described how the player could now place bookmarks of their own – up to five in a map grid – in order to then fast-travel back to custom locations such as the places that particular NPCs are, or a place where they think something might be buried and they need to come back with the appropriate equipment to dig it up, and so forth. I’ve done some more work on this and there are now a number of developments moving this feature closer to completion. Firstly, the actual act of placing the bookmark has now been limited substantially, ensuring that you cannot place a bookmark on a tile that you have not explored, and you also cannot place a bookmark on a building or some other structure. I immediately realised this would essentially be a tool that could be used to essentially teleport the player onto a rooftop or onto some previously-unseen part of the map, so this really needed resolving. As such, in the below screenshot, you can only place a bookmark on somewhere that has been explored, and somewhere which is the not a building (you will also see the two possible errors messages that can generate when you try to place a bookmark in an inappropriate location). I’ve marked excluded areas in red to illustrate what this looks like:



You also cannot place a bookmark on top of something like a tree trunk, a hedge, and so forth. The next thing was to not just have bookmarks appearing when you look at something on the world map, but also have them appear in the fast travel list as something you can warp to. The first part of this, however, was to rework part of the world map. Currently the game only shows you stuff that you’ve found if you’re in / hovering over looking at a city…



…but not if you’re doing the equivalent for a town or a fortress:



A few changes later, however, and the world map now gives you a proper description of what you’ve discovered in a town or a fortress (or anywhere else for that matter) and you can view these much as you would in a city:



There is still a minor bug in this screenshot – it should of course say that you have explored it! – but this screenshot nicely demonstrates how the map now looks, telling you both what is there and telling you at the same time what sorts of things you might be able to fast-travel to when you enter that area (town, fortress, later university, mine, etc). With this done the next step was to get the custom bookmarks appearing alongside the standard bookmarks whenever you enter an area that contains both. I will need some extra code for entering a wilderness area that contains no standard bookmarks but does have some custom bookmarks, but for now I focused this on cities, towns, and fortresses, which will always have the potential for standard bookmarks but can also include custom bookmarks as well. After some work, here’s what we have (with some silly bookmarks just for testing!):



You can now select any of these when you go back into an area you’ve placed bookmarks in, and much like the normal fast-travel locations, it will warp you to the place where you should be, and in doing so increment an appropriate amount of time. One thing did come up, however, which is that there is nothing visible which shows you where the bookmark is; if you were to mark out somewhere you want to dig, for instance, warp back to it, and then wander off to do something else just for a second (or even just leave the computer and come back!), it might not be immediately obvious where the spot is. So, to resolve this, I have also added a little feature that when you place a bookmark, the game prints a little message along the lines of “You have placed a bookmark with the label [XXXXXXXXX].”, and actually adds something new onto the tile where you placed the bookmark!



This is a “feature” on that tile like all other map objects (e.g. plants, trees, terrain types, doors, staircases, vases, shop stalls, tables, whatever) but can obviously be walked through and walked over since it isn’t really “there”, it’s just in the user interface, but can be looked at as a feature which just tells you that you placed a bookmark here, what it is called, and when you placed it.



The game will also place a ‘?’ on the world map if you place a bookmark in an area that doesn’t have anything else registered, i.e. is not a settlement or a farm or whatever, in order to aid in recalling things that might be far out in the wild.



I think these are nice little details and again, in such a vast world, should help the player to keep track of what’s going on and what they’re doing and when they did it. One of the next things to add is of course some way to see all of your bookmarks (this will probably be on ‘B’ whereas bookmarking is currently on ‘b’), and also a method to delete your bookmarks to free up room for others – I think these are all some very good additions to the fast travel system.

Ultimately it is clear to me that URR is, really, not very user-friendly at the moment, and so such a large portion of this release – speeding up every turn, speeding up generating every map, giving the player all these new options for fast-travel and custom fast-travel and everything else – is all in service to really trying to make the game a lot more approachable and a lot more accessible, and to give players all the facilities they might ever need for making sense of this vast world and its slowly coming-into-being mysteries . I’m really happy with how all of this is coming along.

Bugs, miscellany, errata, etc

- Found a major issue with shops in towns sometimes not functioning correctly when you try to buy or sell something (unlike shops in cities which seem entirely unaffected by this) and causing a crash, but managed to resolve it after a fair bit of work.
- Fixed an issue where items that were not actually on stalls within shops were being counted as being “in” the shop and hence something you could purchase (and hence something the merchant would try to sell!).
- Pressing “P” now lets you press Tab to switch between information about the policies / culture of the nation you are currently in, and the policies / culture of your home nation, rather than just showing your home nation regardless of where you actually are in the game world. This now makes it a lot more useful.
- Fixed an issue with courts in appropriate civilizations not always generating correctly when the player tries to enter, and getting stuck in an infinite loop.
- Dealt with a bug whereby selecting unusual religion types in sufficient number during world generation could very, very, very rarely lead to a crash.
- General messages now accurately say “district”, “town” or “fortress” instead of (in some circumstances) always just saying “district” and assuming the player must be in a city.
- You can no longer just endlessly look at the same thing over and over – which tends to lag the game especially if you stack keyboard inputs – and instead you can only look at each thing once. This makes no gameplay difference except it stops some potentially quite significant lag if you press the same button repeatedly.
- Noticed that docks in towns were not correctly triggering with the new stuff in towns – i.e. intro messages didn’t mention them, they weren’t saving correctly as bookmarks, you couldn’t warp to them, etc – and resolved all of this.
- Resolved yet another bug that sometimes prevented docks from properly spawning in certain towns – docks should now always be able to appear no matter what.
- Fixed an issue with dock doors still sometimes spawning facing the ocean rather than facing the land – again, I was pretty sure this had been resolved before, but it has definitely (…?) been resolved now.
- Moving across a grid manually on foot, rather than with fast-travel, but not being in a city (so you’re moving through a gate between districts), now correctly handles things like calculating the initial field of view when you set foot for the first time in the next map grid rather than sometimes temporarily placing the player into a tiny shadow world for a few turns before allowing them to see the rest of the area.

What next?

My next tasks are essentially to continue working and finishing the systems already being implemented in 0.10 – fast travel, speed improvements, custom bookmarks, supplies and ailments, etc – and continue working through my list of known bugs, existing issues, small things that need polishing from earlier releases, and so on. I’m really happy with what I’m getting done here and enjoying the whole process just so much. As ever, if you enjoy this kind of detailed devlog, please do share it (https://www.markrjohnsongames.com/2022/12/26/ultima-ratio-regum-0-10-update-5/) around on social media or with friends you know who you think might be interested! More soon!

[Ultima Ratio Regum]

Welcome back everyone! I think barring catastrophes this should release in around a fortnight, so this will either be the final update, or the penultimate update, before getting 0.10 out. I’m determined to stick to my schedule of putting out a new release every year – even if this is a relatively small release, albeit one that I’m really very happy with – and 0.10 will be put out some time in January. I think from now on January is a much better option than the end of December since although the holiday period is not something that I personally engage with to any great extent, it is for many people, and it just seems like a foolish time to do each release in terms of actually getting attention for the update. Anyway, given that 0.10 is a small release I have decided not to make a big fanfare about it, but instead to save that for 0.11 once (I hope!) I’m back into a rhythm of coding throughout the year rather in just a burst – albeit a very productive one! – in November and December. This has been another hard year for me, unfortunately, though I’m feeling cautiously optimistic about 2023 and beyond. But enough of that: let’s get to the updates!

Multiple purchases of supplies

To begin with, I have now implemented a ton more stuff in the “buying supplies” page which you can access whenever you enter or leave a city. The first thing you’ll notice are these five extra and appropriately colour-coded lines which tell you again what your current state of affairs is when it comes to supplies – how many canteens you have, how much water you have and how much space in canteens you have for more water, how many food rations you have, and how much equipment you have. Again, I’m not interested in what you get in many “survival” games where you have to eat every two minutes; instead, food and supplies here are strategic rather than constant concerns, and are much more about making sure that you have enough to safely get from one location to another, or you have enough to explore the wilds and try to hunt something down. You don’t consume anything when you’re in settlements (cities, towns, fortresses, mines, universities, monasteries, etc) – which is going to be a very large portion of the game – so it’s a very specific concern for exploration and nothing else. The supplies screen therefore does now give you a lot more info, not just those extra lines I mentioned but also the ability to stack how many of something you want to buy (the x1 and so forth on the right-hand side).



Pressing left and right (or 4 and 6 on the numpad, etc) will allow you to stack up how many of something you want to buy, and pressing enter will add or remove the total for that thing (i.e. the number of the thing multiplied by the cost of the thing) to how much money you’ll be spending. Confirming the purchase will then, just like in other shops, give you the option of adding each thing to your inventory or sending each thing off to storage in another nation. This is now an easy way to buy resources in bulk, and although obviously the precise costs of these things are certainly going to need some balancing in the future – this will become easier when smaller denomination coins are introduced back into the game, being one of the features that didn’t ultimately make it into 0.9 – this system is working pretty nicely at the moment. To help you decide what to buy you can also, by pressing ‘C’, access a screen where you can manage your canteens.



Here you have two options. The first to empty out whatever’s in a canteen and make it empty and free to get another liquid added, and the other is to combine canteens by pouring the content of one into another. When you purchase water (and this is generalise for any other acquisition of any other liquid later to be added) the game also now makes sure to fill up your canteens with water (and later on with any other liquids) in the most efficient way. If you have two canteens containing 0 water and one canteen containing 4 water and you acquire 5 units of water, for instance, it will always add it to the 4 water canteen taking it to 9, and leaving the other two free, instead of leaving you with a 0 canteen, a 5 canteen, and a 4 canteen. The game will always try to fill the canteens closest to already being full first, and then slowly work down from 9 to 1, and then only if all possible water has been put in canteens already containing water (or whatever the liquid is) will the game then start filling up empty canteens, and will of course try to completely fill a given empty canteen before moving onto another one. Nevertheless there are certainly scenarios in which canteens might be mixed and moved around a bit, and scenarios where you might want to pour Liquid X out of a canteen in order to make room for Liquid Y, hence the canteen management screen. With all of this added buying and managing your survival equipment is now way easier and way smoother than before!

More speed improvements

There are also a number of new and substantial improvements and optimisations to in-game speed to report on this week (as part of this release’s overall project of making everything smoother, faster, easier, etc). These new issues fixed this week all came again in the turn-by-turn functionality of the game. As I continued playtesting two rather annoying sources of time loss became apparent to me – one of them was taking place in cities, and the other was taking place in anywhere that wasn’t cities but contained people, so towns, fortresses, settlements, and the like. In both cases I was able to find a part of the set of functions that gets called each turn that was sometimes, or always, taking vastly longer than it should be taking. Both of these issues took quite a long while to resolve, but I’m pleased to report that URR is running even more smoothly as a result of dealing with both of these residual issues. As I’ve noted before this sort of very technical bug-fixing isn’t really my forte (nor my passion) but I’m pleased that I was able to hunt them both down and get them both sorted.

In the first case, we had a very rare but quite significant burst in the milliseconds used to iterate a turn that would appear when the player was walking around a city. This seemed to happen around one in every thirty or forty turns and would be a significant spike in time consumption that the player would notice as moving around; the player character would seem to just “stick in place” for a noticeable fraction of a second before coming loose again and continuing to navigate the area. In having the game print some debug logs in order to have a look at this, you can see the milliseconds consumed for each part of taking a turn (aside from rendering the field of view that the player can see), and the spikes in milliseconds that rarely appear here (in two categories, not just one) are very obvious. (And yes, I notice that one part of one turn apparently went backwards in time, but I assume this is just some strange artefact of how Python tracks these things, and is not actually indicative of my discovering time travel.)



So there were two possible spikes here, each one happening in a different part of the turn-handling sequence. The former one, i.e. the third from the end, took place during the game trying to take a turn for the NPCs who had already spawned in a map grid. The latter one, i.e. the second from the end, took place during the game trying to spawn a new general NPC, of the sort who just make up the general crowds in areas that keep things looking interesting. A little bit more investigation showed that the latter one was rarely an issue in cities – but when it was it tended to be a big issue! – whereas it was a ubiquitous, if slightly lower-level, issue in towns…



…while being even more (horrendously) pronounced in fortresses:



As you’ll see from the top screenshot in this section this was, in cities, rarely longer than the briefest heartbeat of time being consumed, and also often registered as a “0” in some cases as well, but in all kinds of settlements this could potentially generate issues. This was the first one I tackled because the spawning-a-new-NPC function is – relatively speaking – pretty simple compared to an AI actor taking a turn, basically because URR’s NPC AI is (reasonably) complex while spawning a new general NPC to be part of the crowd mingling around a settlement is a fairly short function. With that said, though, it took quite a bit more investigation until I was able to zoom-in on and really pin down where the issue was, which is to say the issue mostly appeared when the new NPC was trying to find a position where it could start, and when it was trying to find a position it should be moving to. The function for both of these, called pick_new_local_target(), turned out to be a block of code that I had clearly written in some kind of cataclysmic mental fugue. It was indicative of an issue that a lot of my early code had – thinking that something that might take, say, 10 milliseconds on average really wasn’t all that much, while neglecting to appreciate that a) this function being called multiple times in a given second, and b) the timing of this function is on a bell curve rather than a guaranteed 10 milliseconds, were both enough to add up to serious potential efficiency problems further down the line. The main issue in this function turned out to be how the game looks for a door either for someone to come out of (i.e. that is where they spawn from, and the game is pretending that they were always inside that building all along) or for someone to go into (at the end of their movement around the map). The game would basically pick a random x and y coordinate on the map grid (of 40,000 tiles)… and then just keep doing that, over and over, until it found a door. On some more sparsely-populated map grids this could take a while and is very indicative of the kind of utterly incompetent innocent and amateurish coding a few bits of the game still exhibit. It was the work of a moment to add a list of all doors to the generation of any map tile, and this function now uses this instead, and those 10-20 millisecond computation times (and sometimes far more) have now disappeared. This fixed the majority of the issue here and has led to the whole game being sped up noticeably, and having fewer jerks / sudden pauses, when you are walking around.

In the process, however, I discovered a secondary part of this was to be found in the act of creating the NPC itself, i.e. making an in-game object, giving it all the appropriate stuff (facial detail, clothing, items, political and religious alignments, and so forth), and sending it out into the world. Again a heck of a lot goes into this, but after some serious searching I found that the issue was in the assigning of clothing to NPCs, and specifically in the creation of rings (a character, including the player, can have one ring per hand). Only when a ring was being created were 10 milliseconds being lost, and again this seems like nothing, but when potentially being done in substantial volume and over a long period of time, and alongside other 10 millisecond delays that sometimes appear, the time losses do actually add up to noticeable jerks in the smoothness of the game. A quick bit of research later and I was able to ascertain why exactly rings were so slow to generate, and I fixed it – the issue lay in generating a location-based ring showing a local flag of a town or a fortress, and trying to find an appropriate location in a shockingly slow manner.

With all of these issues resolved, the timings on the turn now looked like this in cities, towns, and fortresses:



…which is an immense improvement over what we had before!

However, the second issue remained, and still needed sorting out…

…except it didn’t. I soon discovered that the rare huge jump in milliseconds in the other category had actually been solved by fixing the first category! I therefore think it was something to do with more unusually high times trying to find a location for an NPC to go to (possibly for a very rare kind of door?). I’m not entirely clear which of these various above fixes also fixed the other issue, but they did, and that’s fantastic. With all of these changes made, walking around the game world is just so much faster now and an infinitely more pleasant experience.

Wilderness general messages

I have now implemented general messages for all the wilderness areas! When you are in any settlement it currently totally overrides wilderness messages and doesn’t give you anything about the specific terrain or biome you’re in – I might change that later, but I think it’s good to have a clear difference here in terms of atmosphere – but when you’re outside a settlement you instead get appropriate atmospheric / background / general messages for the biome you’re standing in. There’s again quite a large set of these, though some biomes were much harder to write good messages for than others, but they again really help to flesh out and develop this feeling that the world is a little more alive. Here are some examples:









However, I also realised that we needed some different comments to come up on some more obscure terrain areas. When the player is on a river or a lake or a coastline, for instance, they should get messages appropriate to those as well as the terrain type (e.g. temperate, desert, etc), whereas on things like mountains and volcanoes the underlying terrain type is generally not particularly visible, and so it should focus on the mountain or the volcano instead. With a little bit more work, therefore, I implemented a system that would notice your presence on a river/lake and add new messages for that, and the equivalent for if you’re on a coastline (you’ll also see in one of these a time-specific message):





And then I went back and added words for volcanoes and mountains that override the usual set, instead of just being added to them:





Indoor speed optimisations

As mentioned in a previous blog entry, indoor speed rendering is also far too slow – this is especially unforgivable given how simple indoor rendering is because a) the areas are far smaller and b) the game never has to think about the alternative heights of things on an indoor map. I devoted a fair bit of time this week to working on this stuff, and I’m pleased to say the process of optimising the speed of the indoor rendering was, largely, the same as the process of sorting out the outdoor rendering. You can read about this is unnecessary extensive detail in the previous blog post, but essentially the problem here was the same set of issues that were taking place outside – rendering far too large an area, rendering the inner area unnecessarily especially if it might not be changing, failing to adequately define the area around the player that should be rendered, and going about some aspects of the whole thing in just a generally slow manner. I believe these have all been resolved, and the rendering speed of indoor areas is once again now cracking fast.

[Ultima Ratio Regum]

Custom bookmarks without normal bookmarks

The game now correctly handles areas where they are potentially plenty of normal bookmarks – i.e. areas with no existing normal bookmarks the player might find such as buildings or other constructions and the like – but the player hasn’t found any of the normal bookmarks, but has found custom bookmarks. It now shows up correctly on the world map, and when you enter that map to start walking around:





Custom bookmarks in the wilderness

You can now add custom bookmarks to wilderness areas and can correctly fast travel to the. This took a little bit more work since a lot of the game is designed to handle a lot of this stuff only in settlements – cities, fortresses, towns, whatever – and so a fair bit of effort was required to integrate the ability to fast travel and present the player with useful menus, etc, when you’re just doing wilderness stuff. Nevertheless this now all works perfectly – and as mentioned last time a small ‘?’ symbol is added to the world map when you place a bookmark in the wilderness – and it’s all very fast and intuitive.





Draining the marshes (for now)

There is a very, very rare biome type in URR which I call the “marsh” biome, and it can only appear in tiny numbers each world generation (if it even appears at all). By chance on one of my test runs I generated in a city with the marsh as the surrounding terrain, and was able to have a look around, and enjoyed reminding myself of how interesting and novel this terrain looks.



However, it also became quickly apparent that because this biome is so rare – and having small ponds of water scattered through it, so very unlike every other biome – I have been unable to test it regularly with all the new content added in the next few releases, and there are some serious problems. For example, I walked into this slum and found a patch of water that was somehow on a higher z level than I was, and was therefore essentially floating in the air:



And, as you can see, deeper into the slum I saw that these lakes had basically destroyed the generation algorithm of the slum while the algorithm had nevertheless placed soil (instead of marshland) around them, resulting in some very profound weirdness going on:



As such, I have decided to remove the potential for the marsh / swamp biome to generate – but only for now. It’s novel and I’d like to include it, but that’s something to bring back later when I can a) have it generate in far higher volume so that it becomes a meaningful part of the world generation rather than a rare niche exception to the norm, and b) where I can test it extensively with all the different things that might need to generate on it. Farewell, swamp – you will one day return!

Vines

I noticed this week that vines in tropical areas, or rather how they appear in the look-up window, is absolutely dire.



The terrain image generator is one of the earliest I ever made, and while the main generator itself is still perfectly adequate, these vines placed on top are… truly, truly shockingly awful in how they look. I actually couldn’t quite believe how bad these looked when I saw them again – what on the planet was I thinking allowing something so aesthetically repugnant to exist in the game, even back when I starting out?? Truly horrific. I have removed the vines part of the image generator and at some point in the future will update this to a modern-standard image, but for now, it’s just too awful to appear and so vines will appear on the map you’re actually walking around (as in the rest of the screenshot here) but just not in the lookup image.

Bugs and the like

- Fixed one of the handful of major long-running bugs in the game, with NPCs walking around and doing their thing in certain buildings being, very rarely, unable to figure out something to do and causing the game to get stuck in a loop. I think this is now totally resolved and I can no longer get an NPC frozen without a task. In the process I discovered the system for making these choices is appallingly inefficient, though since it still takes up so little time, it’s not a priority to change; but one I’ll keep an eye on for the future. (Seriously though: it’s shocking. I should have known better by 2017!)
- Fixed another major bug involving the game rarely deciding to crash when entering areas of the world – such as city centres, or towns with diasporas of foreign citizens, etc – which should be spawning NPCs from a range of different backgrounds. It would sometimes get confused between which name archetype to use in generating the name for each person (i.e. the archetype of the home nation) and which to use in trying to display their names (the archetype of the local nation). This might sound like a trivial fix but was actually surprisingly complex because of how it’s all handled, but this crash bug is now well and truly purged.
- Resolved a related issue where very rarely in other contexts the game would try to use the wrong name type to present an NPC’s name, potentially leading to a crash (e.g. if they didn’t have a middle name and the game was specifically asking for a middle name).
- Fixed an issue where holy books in religious buildings could spawn almost anywhere (including in reflecting pools and on top of an altar!) despite the fact that they should be only spawning on tables. They do now, indeed, only appear on tables.
- The game now correctly says “You have explored…” or “You have not yet explored…” on the world map, in a long overdue bugfix.
- Fixed a rare crash bug when, upon entering an area of a city containing a river running through that district, and doing so from a particular direction, the game would sometimes be unable to figure out where on that map grid the player should be placed, and would wind up just placing you nowhere.
- Changing the colour of water each turn no longer causes the leaves of trees to change colour (and mysteriously become liquid?) if the tile is water but some tree leaves are hanging over it.
- Fixed a problem with the game sometimes not being able to calculate the time it will take you to leave the map grid when using the travel function if you’re on a river tile, and the game can’t work out how long it will take you to cross to the other side. This is a pretty obscure one, and will have to be adjusted again once swimming is implemented, but for now it just doesn’t cause a crash – and that’s the important thing.
- You no longer consume ludicrous amounts of food while on a ship (we’re treating ships here as moving settlements, i.e. you are fed and have somewhere to sleep and get water and all that stuff rather than needing to purchase supplies to do all of this). Again, it’s only out in the wilderness that you need supplies.
- Some weird black bars no longer appear on the screen when you use the world map looking function to look at a city that you haven’t actually yet found / explored, which thereby allowed the player to figure out things unseen on the world map.
- Cult shrines no longer incorrectly appear as a ‘u’ or a ‘d’ on the map when you’re looking at them from a higher or lower z level than the shrine itself.
- Fast-travelling to a training ground in a city centre (which appears when the nation has gladiatorial combat as its method of justice) will now no longer cause a crash, and correctly puts you where you should be and facing in the right direction to see the training ground.
- Looking at certain types of rings on nomadic people no longer causes the game to crash.
- Entering a farm under very specific circumstances – when the game is looking to try to place a political delegate in a democratic nation, but cannot find one to place there – no longer causes a crash.
- Fixed another potential crash bug in farms where, very rarely, the game had not properly recorded the number of farmhouses there should be (I believe this only happened if no “important” farmer was generated, i.e. no NPC that the game absolutely must track even when the player isn’t physically present) and couldn’t work out what to do when generating a farm tile and it came to spawning farmhouses.
- Asking people about religious relics no longer sometimes causes a crash when they can’t figure out what relic they should be telling you about. The fix here for now is just a temporary fix before really enhancing and developing the in-game religions, but it gets the job done.
- The game can no longer assert that “You purchase 0 more storage space” in a civilization.
- The list of key commands in a dockyard no longer appears and disappears sometimes when you navigate around the menu.

What next?

Another update in a week probably, and that might well be the final update before release. Again, given that so much of this update is improving / optimising / tweaking I’m not going to make a big fanfare on this one, but I’m really happy with all the work I’ve been doing and how well this sets the game up for the future, for being so much smoother and more playable, and for not buckling under the weight of whatever features get added in next. Thanks so much for reading everyone! As ever, please do share about the devlog with anyone you think might be interested if you enjoyed it, and I’ll see you all in a week or so .

[JobLeonard]

My money is on the door-finding bug being the cause, not the ring. Since it's geography dependent, and I can imagine that variations in map layout and sparsity of doors can greatly affect the statistical approach of it.

Meanwhile one would expect the ring-placement timing to be constant across all locations.

Anyway, sounds like you got a few nice entries for the "accidentally quadratic" blog, if that was still being updated! Well done!

[Ultima Ratio Regum]

My money is on the door-finding bug being the cause, not the ring. Since it's geography dependent, and I can imagine that variations in map layout and sparsity of doors can greatly affect the statistical approach of it.

Meanwhile one would expect the ring-placement timing to be constant across all locations.

Anyway, sounds like you got a few nice entries for the "accidentally quadratic" blog, if that was still being updated! Well done!

Haha, thanks Leonard - I didn't know about that blog but I like the idea a lot. Yeah, the doors were a big issue but the ring bug was definitely there, as the game was previously soring through possible locations in a truly, truly stunningly inefficient manner. The issue came from potentially very large nations having their territories searched for workable locations in a dreadfully slow manner, and even in small nations it was achingly slow and stupidly done! Whoops. Ah well, one lives and learns...

[JobLeonard]

This is implemented in Python, right? This might help if you really want to dig in:





https://pypi.org/project/scalene/

[Ultima Ratio Regum]

It is, yes! I like the image in that link a lot. I think I might be done with optimization for now, BUT I will definitely keep this one in my back pocket for if/when some more work here is needed. I really have to be in the right (very rare) mood to do a lot of this sort of "back-end" work, and although I have been for the last two months, I can feel it fading...!

[JobLeonard]

Well, just remember for next time it hits you: scalene is the performance profiler you want

[Ultima Ratio Regum]

Welcome back, friends! This is probably now the final (or penultimate) update before release, which I am tentatively going to schedule for the first week of February. A slightly slower couple of weeks this time as there has been a lot of start of term work to get sorted (and my only family member is over here in Sydney visiting me at the moment) but I’m pleased with all the polishes and final steps I’ve been able to put into place. There’s very little left to do and barring any catastrophes I think a release at the end of this month should be workable. I also think it’s quite a “good” date to make approximately regular for future years in that (as previously noted) it avoids the holiday period quite nicely.

Anyway, here’s what I’ve been working on in the past fortnight:

Death

You can now die in URR! A tremendous addition, I think we can all agree. Upon death the player is given a record of everything that they achieved in that particular playthrough – how many cities they discovered, how many universities they visited, how many shipwrecks were uncovered (it’ll be fun to add these!), and also how many of what I think will be the three distinctive quest elements – how many secret locations you found, how many high-quality chests were opened (a generator I look forward to working on), and how many “puzzle pieces” were found. I’ve been working for a day or two now on this death screen and I’m actually really happy with how it’s looking at the moment! There might be more added here in the future (and I need to finish implementing all these collection systems for keeping track of the various things you can find or do in-game), but I think this does the job for 0.10 very nicely indeed.



(Also, whew, 1040 books generated in a single world! Working on generating the content of those books, and making it highly meaningful and logical and filled with potential game clues, is going to be a lot of fun.)

Number items and weight

The weight of canteens, food ration bags, and equipment packs, now changes logically as you consume the stuff which is in them. Food ration bags and equipment packs both have a weight of “2” – for having 6/7/8/9/10 rations / pieces of equipment in them – and now go down to a weight of “1” when they have 1/2/3/4/5 inside them. The same is also true of canteens, with a base weight of “1” but going up by 1 for every two units of liquid inside them, up to a maximum of a weight of “6” for 10/9 units (and “5” for 8/7 units, and so on down). These update and change whenever you use them and as far as I can tell this works in all contexts now that it should be working in. So for example, here are your supplies when you start a new game, i.e. a canteen with ten units of water and four packs of food rations with ten rations each:



And then after some exploring over half of the rations in this food pack have been used up, and so the weight (and the player’s total held weight!) have both reduced by one:



And then later after eventually finding our way to a desert and using up some of the canteen, it no longer contains 9 or 10 units or water (for a total of 6 weight, 5 per 2 units and 1 for the canteen itself) so now weight 5 instead (4 of which comes from the 7-8 units of water it holds and from 1 from the canteen). All of this also has the nice side effect that the more you explore on an expedition the more weight you’ll free up in your inventory to bring back what you find. This was a key mechanic in one of my favourite games from two years ago, The Curious Expedition, and I don’t mind admitting that I think it’ll work really very nicely here as well.



Religious issues

I also found a graphical issue with some religions in the “normal” archetype (i.e. not a “demonic”, “Lovecraftian”, “pantheon” or “Egyptian”-style religion – the “normal” archetype is generally use for around 75% of the religions in a generated world with a smaller number selecting one of the other types). This graphical issue was manifesting in two places, with the religious symbol on religious books sometimes appearing very strangely indeed (on the left hand side of this image) and the symbol on altars sometimes just deciding of its own free will not to be shaded at all, and consequently looking rather strange (on the right hand side).



It took a little while since it has been a long time since I did anything with this particular graphics generator, but I was able to hunt down the issue and deal with it. Incredibly this was a hangover frmo the transition from Python 2 -> Python 3 years ago and was – I hope – the very last thing that I hadn’t previously noticed as being a little bit amiss as a result of making the shift. I believe these are all now fixed though, resulting in some much nicer looking religious altars and holy books:



At the same time I also noticed another bug, which was that the colouring of the religious robes for the priests in some religious buildings is incorrect. It seems to always be correct when it’s for one of the special religious archetypes, but for the “generic” religion archetype the wrong colour of robe was definitely popping up from time to time. For instance, here’s a book, altar, and robe for the religious building I was testing the above thing in…



…and one can pretty clearly see that one of these does not match (and one can also see that one of the image qualities here is much lower than the others and came from a much earlier time of working on procedural image generation, and will need updating to come in line with the image quality I’m working with now, but that’s a task for another time). A quick bit of fiddling and work later, however, and this problem appears to be solved, with the game now correctly giving priests the right (if aesthetically mediocre) robe for the religion in question:





I also in this process noticed that holy books were sometimes not spawning in appropriate numbers in some religious buildings. This issue seemed to be focused on the tables that might spawn in the branching sections away from the core of a religious building, i.e. holy books might spawn on tables in the middle of a religious building, but seemed very disinclined to spawn on tables in the branches (which in the generation system are placed later on). Again it happily wasn’t too much work to hunt down the issue here and get it fixed:





On foot

A number of the new features and mechanics were working fine when used how the player will normally be using them, but were causing some lingering issues when being used in other contexts. These particularly involved doing things on foot rather than with the travel menu, which is always an option and needs to be appropriately catered for. The main two issues were the time of day iterating correctly when you were on foot – specifically when the day changed from one day to the next after passing through midnight – and the game giving you the menu to decide what you wanted to do at a city gate after unloading the current area but before passing through, leading to a crash if you just decided to turn back around and various other bizarre (both programmatically and visually) outcomes if you chose some of the other options.

In the first case the game can now correctly move from one day to the next by simply the time ticking over midnight – instead of the normal thing of moving one day to the next when you move across a map grid into the next one along – and doesn’t cause any weirdness with the visuals, nor incorrectly saying rubbish about you being in a town when you are not, actually, inside any kind of settlement. As a result of working on this I have also decided on a model where food and the like are only consumed when moving map grid – this might seem just fractionally strange ordinarily, but I think will work well under gameplay conditions, i.e. preventing scenarios where from the player’s perspective you are randomly charged a food or a water supply while you’re just walking around a map grid talking to people or doing whatever you might be doing. In the second case the game now gives you the menu you get at a city gate when you move into the city gate but before unloading the area you are currently in, allowing you to potentially turn back around and do something else without the game misbehaving, and allowing you to also use the other options (exchange currency, buy supplies, etc) and then be able to immediately go back to moving around the map grid you are on without a crash, a need to reload, or any other blasted weirdness.





Fungus

The game presently generates large numbers of plants and animals – though only the plants at present actually appear in the game world with lovely new generated images in 0.10 – all of which are designed both to enhance and further the alive-ness of the game world, but also to serve as potential clues.



Maybe you learn a mansion with a garden full of plants with particular properties houses a great secret, and you need to research with herbalists and through books which plants possess that property, and hence which plants to look for in the gardens of local manors. Maybe you hear of a treasure buried in the area where the Two-Antlered Snow Deer performs its mating rituals; then you find a book about that animal and discover the exact location; and then you go there and try to find what’s buried. Although they might not appear for a little while, I’ve now also implemented a generator for fungi. I think these are mostly going to appear in cave / underground areas once those are implemented (though maybe also, far more rarely, above ground – or perhaps the more they appear above ground, the closer you are to a cave entrance?) but it was a really fun hour to design this generator and get these names implemented into the game’s tracking for future reference, future image generation, and future clue integration.



Bugs and the like

- General / walking-around messages in areas where the main thing is only in the centre of the map grid, such as monasteries and fortresses and towns (and later mines, universities, etc) no longer trigger if you’re at the edges of the map grid. This is a good change since it seemed a bit strange when you were talking through trees and the game said “Two people walk past you discussing [whatever]!”.
- Fixed, for what feels like the fifteenth time, the bug with priests sometimes perching themselves on top of altars like some kind of mad religious bird. I am now pretty certain priests will never stand on top of altars, and at most will stand next to them, regarding them with fervent awe.
- Entering the travel menu, moving into an exit from the city, and then choosing to turn back around rather than go through that exit, no longer results in a crash.
- Spawning a religious building, leaving and then coming back under a very specific set of circumstances, no longer causes the game to crash trying to figure out what the priest should be doing when you return.
- In anticipation of replacing reliquaries with the actual relics themselves in 0.10 (and because the reliquary as an item/feature no longer really works with the ideas I want to develop for religions), all reliquaries have now been replaced with offering tables in religious buildings, and will subsequently next year have relics spawning atop them.
- The text on the edge of the currency exchange screen will no longer sometimes get chopped off when dealing with currencies that have particularly long names.
- The starting year, month, and day of the game are now lightly randomised.
- Buying something or a number of somethings from the supplies menu now correctly and at the right time updates the sidebar showing your supplies of food, water, and equipment.
- Offering tables in churches now actually have different colours for when in vision, and outside of vision.
- Trying to place plants in a snowy biome can no longer sometimes lead to a crash; instead the game looks for plants that can spawn in that location, but if it finds none it selects a nearby area of tundra and uses the plants from that instead. Plants are also relatively sparse in snowy biomes compared to the others.
- You can now use the numpad 5 and the numpad enter to confirm things on even more menus which previously didn’t allow this (such as exchanging currencies).
- Indoor water now flickers and shimmers and changes colour each turn just like outdoor water does, and although one cannot currently find any kind of lava indoors, just in case this one day changes, the same would now work for indoor lava as well.
- Fixed a problem where monks would sometimes struggle to work out what religion they should belong to, and would instead opt for atheism, and crash the game.

What next?

Release!