Provided for perusal, the main control flow chart for Epigon.

This is the way things work inside Epigon.

This is the way things work inside Epigon.

In the beginning, there are two possible sources of input, the Player and the Dungeon Master (also known as the DM). For those that don’t know, the Dungeon Master is the person at a traditional pen and paper role playing game table that controls all the monsters and other things in the world that the players don’t control. These two sources operate on a different information set and have a slightly different set of ways to attempt actions. The differences lie largely in cases such as the Dungeon Master can create a new mountain, while the player can’t directly do so. There is a third source of an action request, which is the result of another action, but more on that after the jump.

If an action causes some sort of chain reaction, such as the player moving onto a trap, the previous action becomes the creator of the new action. This new action contains a link to its creator however, so when information about the action is gathered it can be causally linked. In the example given, the display may print out “You moved North and stepped on a poison gas trap. The poison doesn’t penetrate your Mask of Gaseous Barrier.”

This setup allows each of the steps to be broken out into separate control units and the action requests can queue up while the DM and Rules Enforcer do their work. Not shown explicitly here is how actions may be unrelated or asynchronous. The DM may do some work simulating time passing in the nearby village which has no immediate impact on the player’s experience. This work can then be threaded so that it still takes place during regular play rather than during a loading phase.

The message passing is a side action to the main flow of the program. The Post Office gathers the messages as the observer part of the Observer-Listener Pattern, while the Message Listeners are, naturally, the listeners. This allows for a lot of asynchronous flexibility in the program.

One example of the flexibility is that the Post Office provides a means for the UI to display information in a manner which is relevant. The text output can display messages relating to things within the player’s perception, while the dungeon view might do things like flash a creature red to show a hit landed. Things like floating damage can be added as well without modifying any of the code doing the actual simulation work.

In addition to the obvious use of the Post Office by the UI, the Post Office can also be used by two other very important elements of the game. One of these are the NPCs (Non-Player Creatures), who may revise their planned tactics based on changes occurring. By listening in on the messages generated, they can pre-plan actions in their own thread rather than wait until the main process runs their AI algorithm. While they will not be able to pre-plan definitively, they should be able to build an approximate plan, and that approximate plan may well be a more interesting form of AI than a concrete deterministic plan.

One of the things I’m very excited about implementing in Epigon is an Achievement system. There will be more on this later, but talking about the data flow and the Post Office makes it somewhat relevant now. One of the primary goals in implementing the Achievements is that they do not slow down the player experience. Letting them listen in on the messages through the Post Office allows them to do their work at a low thread priority and allows for new Achievements to be added later with ease.