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.
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
.
Author
Topic: Dwarf Fortress meets The Outer Wilds? "Ultima Ratio Regum", v0.10.1 out Feb 2023 (Read 642175 times)