Short-Term ReplacingNow, some stationary NPCs require two special things: they might need to be replaced in the short term (so there will always be a guard in any guard location, but at certain points in the day a new guard should come along and relieve the other guard, who would presumably be getting tired), and they might need replacing in the long term (e.g. gladiators who have died by now, or sailors lost at sea, etc – the game needs to replenish its volume of some of these NPCs when some are killed or cease to be important). Long-term replacing is not yet required (since NPCs, and the player, cannot yet die), but for short-term replacing, there is now a system in place to perform this task. When a guard spawns, the game sets a length of their watch, and when this period is up, a new guard is spawned as close to the guard as possible without the player being able to see the new guard spawn. The new guard then travels to the location of the old guard, and once they are on adjacent tiles, they switch places, and the old guard then moves out of the district and despawns, whilst the new guard becomes effectively identical to the old guard. I’ve also set up a system where there is a set “pool” of guards for each place, so perhaps you’ll be able to persuade certain guards to let you in if you know when their shift is, and their willingness to be bribed/persuaded/threatened/etc? Here, therefore, we have both the guards on a mint changing over, after which a priestess and her escort ramble past:
And the equivalent in a bank: they would not ordinarily all change over in this short a space of time, but for the sake of testing, it looks pretty neat:
Travel and Abstract SchedulingOnce I’d implemented this guard system, I then realized the game needed to track this wherever in the world the player was (or, at least, when the player next sets foot on that tile, work out which of the two guards should be on their shift, and spawn them). This seemed trivial, but it quickly became clear I was going to have to do other things before this. If I want the game to see how long it has been since the player last set foot on a map grid, then I have to know precisely how many turns/how much time moving on the travel map takes – and that, in turn, means programming that fully (currently there is just a placeholder of 20 “ticks” of the clock for each grid moved) and also making sure it cannot be exploited, and that moving on the travel map is never more/less efficient in terms of time spent than moving on the local maps (so, for instance, if on the world map you move north, north-west, then west, it should only count you a few turns as you move through the “corner” of the NW tile, since you wouldn’t walk to the middle before turning… but this rapidly makes the calculations very complex, as the calculations have to look at your previous two turns to figure out what would have been the most optimal way to move from Tile 1 -> Tile 2 -> Tile 3 if you’d been doing it on the local map instead of fast travelling). As such, I spent two days this week developing a detailed calculating system for working out the most optimal path the player could have taken between what I call two tiles and their outcome – the outcome being either pressing Enter to explore that tile, or moving onto a third tile – and thereby ensuring that, for long distance, fast travel is always equal to the most optimal path the player could possibly take on foot, i.e. the player should not be encouraged to spend real-world minutes slogging around the world on the local map, as it will never be faster (it will either be equally fast, or slower). So, basically, the system now tracks your previous two moves, and all the possibilities of those moves, and then when your third decision causes these possibilities to “collapse” (forgive the quantum terminology) the game calculates how long the most optimal way of carrying out that movement would all have taken, before then letting the player do any more interacting. This might sound strange, and it took a solid two days to code, but now it works perfectly and can handle all scenarios of the player’s fast-travel movement, and is always efficient, and allowed me to finally return to guards and ensure that the game knew which guard should be on patrol duty. In 0.9 therefore this system will be expanded to actually take account of terrain: moving on roads will be very fast if you have a mount, moving on desert will be extremely slow if you aren’t in a caravan, moving on mountains will be even slower unless one takes a mountain pass, and moving on ocean will, of course, be impossible unless one charters a ship.
ExplorationAs part of the above, I decided to do a little bit of work on how the world map is going to look to explore -this is still not going to be the first release where the map starts mostly shrouded (though it seems very clear that that will be 0.9 early next year), but I wanted to implement it at the same time anyway. When you move you now uncover all the tiles in a circle around you (effectively a 5×5 grid centered on the player with the corners removed) but you can also see all mountains in a far larger area, to simulate the ability to, naturally, see things which are higher up than other things (profound, I know). In the future I’ll probably let you see a decent distance across the ocean, too, but I haven’t added that yet. Here are gif and image examples of how this looks, which I’m very happy with at the moment:
Finally…Last but not least, many thanks to the extremely generous donations of the last couple of weeks; I really appreciate them! Over the coming week I’ll be working on completing the scheduling system for NPCs – day night cycles, going “home”, that kind of thing – and doing a lot of remaining edge cases and things like that, so once that’s all done, I might get working on one of the other clothing generators for this release, or keeping track of the “crucial” NPCs. We’ll see. See you then!
Author
Topic: Dwarf Fortress meets The Outer Wilds? "Ultima Ratio Regum", v0.10.1 out Feb 2023 (Read 636167 times)