For this final article I want to talk a little more about the Finite State Machine and
the Publish-Subscribe model that keeps the game logic clean and decoupled.

Finite State Machine

Using an FSM can be a great way to manage the high
level transitions within the game. On first glance, for a simple game like Gauntlet, you might think there
are really only 2 states, the menu, and playing the game, but it also helps to have smaller,
transitional states, for example, while we are loading each game level.

Using a declarative model to define our game states and the events that transition between them, along
with short, simple callbacks when those transitions occur, allows us to keep the main game object clean and
avoids long, complicated, spaghetti-like conditional methods.

Publish - Subscribe

In addition to the high level state machine, within the single playing state we should
also be able to publish that certain events have occurred. Any other objects within
the game can subscribe to be notified of events that are relevent to them, and ignore
those events that they don’t care about.

This keeps our game objects decoupled and minimizes their need to know about each other. The
main objects that subscribe to events are:

game - controls the primary game logic by responding to events

scoreboard - updates itself when key events occur.

sounds - are played for many key events.

player - needs to reset on every START_LEVEL event

The biggest consumer of events is the primary game object. It uses event handlers to coordinate the
game logic itself. The handlers are declared using a small data structure:

Conclusion

The finite state machine, and the publish-subscribe model, are 2 great patterns to help tidy up
any game code base. It helps to decouple object dependencies, and avoid complex conditional logic
which might otherwise end up as spaghetti-code.

… and, that’s about all there is for Gauntlet… at least for this single player
version. The game works pretty well, its fairly fun (at least for a short while) and
feels (to me at least) like a Gauntlet game. There is certainly plenty that could
be added or improved:

More maps

More monster types (e.g. lobbers)

Teleporters

Secret doors

Special potion types

Better graphics

Better gameplay balancing

Speech Synthesis

Mobile Support

Performance (particularly loading sounds over a slow network)

But of course, the biggest ommision is multiplayer support. I hope to work on a multiplayer
version later in the year, time permitting, so we will have to wait to see what happens with that.

I haven’t said much about how the game is rendered, but its pretty straight forward <canvas>
sprite rendering using drawImage api calls. I’ve spoken in more detail about these in the past with
boulderdash and sprite rendering with outrun.
I think the code for the Gauntlet render object mostly speaks for itself. Finally, the sound is
all managed by the AudioFx library, which I’ve spoken about in a
past article.

Until then, thats about all I have to say on the single player version.