Scheduling, World Travel, NPC Replacement

Short-Term Replacing

Now, 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:


Nice Robe

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 Scheduling

Once 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.


As 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:




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!

Be Sociable, Share!

13 thoughts on “Scheduling, World Travel, NPC Replacement

  1. Your villages seem very… complete. Why not have the guards assigned to a house, instead of spawning/despawning? This seems like just a tiny step forward when you already have to make pathing scripts anyhow. It would make the home areas more interesting, too… a baker wife to a second shift guard husband and a farmer son. The son wakes up first and heads out to the fields, then the baker starts her fires, and later the husband goes out to his post, etc. Also, you could then arrive at the home and kill the guard before he could go to his post, allowing you to schedule some interesting exploits.

    (Maybe this is all very very complicated though.)

        • Started typing 5 times now and deleted it over and over again, because it spiraled out of my “willingness amounts to write”-scope (so sorry for this vocabulary-Abomination )
          Something very simple would be:

          1. Wander off in search.
          2. Come back after checking the killed guys house.
          3. Do a whole shift again.
          4. Next shift the missing guard would be replaced with a respawned one.

          As a player you could try to get in while phase 1, although there should be consequences to the killing where there will be more guards guarding the place now, or something?

          On the other hand you still seem uncertain whether you want to have combat in the game at all, which seems to me like “killing” somebody would at least not work in the classical sense. Maybe you can just lock him in his apartment, or poison his dinner with sleeping herbs?

          • Ha! Yeah, that could definitely work. Although in previous replies on this post I’d expressed how challenging I thought it would be to assign everyone to houses this release, I’m actually having second thoughts about this, and I now think it might not be anywhere near as tricky as I’d feared, with a little bit of trickery which the player wouldn’t currently notice. It might get added in this release after all (we’ll see).

            Interesting killing ideas! Very interesting…

    • I may do this – but the complexity quickly begins to spiral when some parts of a schedule (house or place-they-guard) might be spawned, whilst another part might still be unspawned because the player hasn’t gone near enough yet to spawn it. I might develop this, but I might not, and I’m not quite sure – as you say, though, there is potential for some interesting exploits there. It’s possible that this release I’ll leave the complexity at the level we have now, and then in the next release attempt to really tether everyone to a house and work out the timings to-and-from that house whether it is spawned or not?!?! It’s very challenging though, and I know it’s something the DF guys have had a lot of trouble with too.

      • ugg… always responses… sooo hot +10

        okay, so I wasn’t aware of the DF guys having trouble with anything… just choosing to develop in a different direction! 🙂

        That seems to be the most distinct advantage of being huge! Best of luck!!

        • It definitely is – the way I think of it is that what DF is to physics (and simulation), URR is to culture. But yeah, they did have some problems marrying different “scales”, and from my own experiences now, it is *really* tricky…

  2. Pingback: Important NPCs Part I | Ultima Ratio Regum: The Roguelike

Leave a Reply to Kasaris Cancel reply

Your email address will not be published. Required fields are marked *