Better Rumour Spaces

I started the week by tidying up the very long and knotted movement code. Over time as the game has gotten more and more complex, more and more logic was needed for movement. I ended up creating a special AgentMover class which is instantiated each time an agent takes a step. The module for that ended up around 600 lines of code.

After that I went back to working on the rumour system. Previously, I had built a system where the location of all important items is determined right at the start of the game and a bank of rumours is generated to give clues as to where these items are. The issue was that there was just one pool for rumours about things that were scattered all across the world. So if the player tried to gather information, they would mostly hear rumours about stuff that was very far away.

To deal with this I sorted rumours into "rumour spaces" and then put those spaces into groups. A single dungeon represents a single rumour space, so if you wander around in that dungeon, you will only hear rumours pertaining to that dungeon. However, if you visit towns on the surface, these will be linked in with a whole group of rumour spaces spread out across a certain region of the world. From a town you can hear rumours about the nearest major dungeon, plus whatever other caves and tombs are in the area.

There also exist some general rumour spaces about stuff you can hear about no matter where you go in the world. This is reserved for stuff that is relevant to the final game goal.

I also needed a way for rumours to get flagged as 'expired' once the player had already investigated them so that the screen that shows rumours isn't cluttered up by stuff already found. For this I gave a rumour_id property to items, so that when they are picked up and identified, the rumour is flagged as expired. This was actually trickier than it sounds because of all the systems that have to pass down the information. It goes like this:

At the time a dungeon's metadata is generated at the start of a game, it determines the position of important items and agents. Then the RumourMill is called to store a rumour and it gives back a rumour_id. For each level of a dungeon, a vector of dungeon_site structs is generated and these contain relevant rumour_ids. At the time a level is generated when the player arrives there, it grabs its parameters from the Dungeon class and populates a vector of LevelSites by ripping the data out of the dungeon_site structs (including the rumour_ids). LevelSites are generated and positioned around the level, and each of these will contain one or more Rooms. Room classes are populated by ripping data out of LevelSites. When the Rooms are finally decorated, items and agents will be added according to the data that was passed down, and if there is a rumour_id, it will be assigned to an item.