Dev Log #19 - UNIVERSAL PAUSE SYSTEM AND NOTIFICATIONS

In the previous couple of weeks, I have been reworking the way players have access to blocks. Now, players will need to purchase blocks, giving them some smaller goals to work towards, as well as a different level of strategy to interact with (like which block to buy, and when). They can also trade access to blocks with different deities, gaining Affinity with these deities by giving away access to the blocks they own, or spending Affinity to gain access to blocks from domains owned by rival deities. This week, I had to extrapolate that system in order to catch scenarios where the player loses access to blocks that are already in graphs they have built. For example, if they have a block like "FindEdible" in their folk's behaviour graph, and they give access to that block to a different deity (thus losing access themselves), what happens?

This forced me to revisit a system that needed some love and care anyways, which is the pause system. I already had to deal with graphs changing during runtime and how that would work when the player could change the behaviour graph that their blueprints run on while the game was playing. My solution to that was to task the Blackboard with keeping track of whether or not the game is running while it is opened, and pause the game if it is. This was a hacky solution that worked while it needed to, but was simply not scalable.

So I've created a universal pause system where different "pause owners" can call for the game to pause, and the game can only resume once all pause requests have been resolved. Only once all individual owners have released their gates the game can resume. The Blackboard is now one of many different pause owner. Another pause owner is a system that is responsible for validating player's behaviour graphs. When access is lost to a block, it checks if any of the blueprints are invalid and asks the game to pause, only resuming once the player has opened that blueprint's graph on the Blackboard. The Blackboard in turn keeps the game pause, and can't close until the blueprint is valid, so that takes care of itself!

A secondary user of this universal pause system is the new notification system, which is the second thing I worked on this week. I got some handy feedback from the Tartarus playtests that players were having a hard time keeping track of when their Folk died, or when rival deities unlocked domains. Playtester Isaac from our discord community gave the suggestion of customizable notifications, which allow players to choose whether to receive notifications about certain events, or even have the game pause altogether when, say, a blueprint they own has died. I have now finished a first pass of this system, and I think it has a lot of promise. Thank you, Isaac!

The three different levels of notifications are as follows:

• Silent, meaning no notification at all

• Notification, which gives you a little pop-up on the side of the screen, and saves the notification for later viewing and

• Alert, which pauses the game and requires the player to acknowledge it before the game can resume

WHAT NEXT?

With this new notification and pauses systems in place, and the edge cases of block access lost taken care of, it is time for the next phase of our post-tartatus design shifts: deity quests. These quests will give players the chance to collaborate with different deities, doing their bidding for a bit of Affinity in return. They can use that Affinity by strategically gaining access to important blocks down the line, even if they missed out the chance of unlocking that domain for themselves.

Thank you, as always, to everyone who reads these Dev Logs! If you haven't joined our discord server yet, please do! I am a team of one, and am always looking for playtesters to guide the direction this game will take. If you would like to help the project, playtesting is the SINGLE best way to do it.

https://discord.gg/8qWrUvqYZa