Now its time to lift our heads up out of the weeds and take a final, short look at our high level game logic.

Previously we talked about:

• Foundations
• Level Maps
• Entities
• Collision Detection

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.

Last time we looked at our game entities and their update() methods and talked a little about monster AI - which really boiled down to:

move towards the player!

What we glossed over was how the entities occupy() the map, and trymove() within it.

This article will reveal more details about those methods, what the maps internal data structure looks like, and how collision detection works within the game.

Last time we looked at how to parse image files in order to build up our map levels. Now we are going to take a closer look at the entities that make up the level itself.

There are a number of different types of entities in a Gauntlet game, but we are going to concentrate on the primary ones:

• Treasure
• Monsters & Generators
• Players

If you understand how these entities work, then the other types (Doors, Weapons, Exits, and Visual FX) should be easy to understand.

Gauntlet is a top-down dungeon crawler that needs lots of different level maps.

I originally imagined that I would build a simple level editor that generated some kind of JSON data structure, but to get started, I prototyped a simpler idea …

Why not just use a normal paint tool to build the maps, use the HTML5 <canvas> API to getImageData and use different pixel colors for different tiles such as walls, generators, treasure etc.

Before I embark on trying to make a multi-player Gauntlet-style game, I wanted to spend some time writing up how the single player version works first, while it is still relatively fresh in my mind.

This game is a little bit more complex than my previous games, and so requires a little more structure, and in turn, a little more explanation for how-it-works.

This first article will try to cover a lot of ground to establish the foundation upon which the game sits, including:

• Code Structure
• Dependencies
• The Game Engine
• The Game Loop
• State Machines and Events
• Configuration
• Gauntlet Classes

Most of the topics for this article are all quite general topics that can apply to any javascript game, many of which have been touched on in my previous articles, and will quite likely resurface in future games as I build up more and more of a re-usable ‘engine’.

Subsequent articles will be more Gauntlet-specific, and cover topics such as maps, entities, collision detection, and game logic…

… but, for now, lets go ahead and dive into the game’s foundations

As a kid, my 3 favorite arcade games were Donkey Kong, Outrun, and Gauntlet. Last summer I had a go at making an Outrun-style racer that turned out reasonably well, so next up was Gauntlet.

I’ve been poking at it on-and-off for a couple of months and I think its in a reasonable state to share with the world… with one really, really, important caveat:

IT’S SINGLEPLAYER ONLY!

I know, that’s utterly ridiculous, how can you make a Gauntlet game without multiplayer? But there are only so many hours in the day (full disclosure, I also didn’t have time to do any cheesy speech synthesis - so no “elf needs food badly” - sorry).

Now, I fully intend to build a multiplayer version, but I probably won’t get the time to tackle that until later in the summer, but I didn’t want that to stop me from putting the single player version up and writing up a few ‘how-to’ articles while it’s still fresh in my head.

So, with that mea-culpa out of the way, let’s play Javascript-Gauntlet:

At the end of last year I went on a little walkabout for a 2 month trip down to New Zealand, away from the computer. It was a fantastic vacation, with a lot of outdoor activities, lots of fresh air and hiking, and some well deserved time away from the computer, but it wasn’t long after returning that I got itching to build another javascript game, and I’d been promising myself the next one would be a version of the classic Gauntlet arcade game.

Time for another minor update to my javascript state machine library. The code, along with updated usage instructions are available on github.

New features include:

• Generic callbacks
• Optional final state(s)
• Cancellable ASYNC events
• Fix undefined return codes

Enjoy!

I have released a minor update to the sprite-factory ruby gem. This version adds 3 small features:

Support for .ico files

If you are using RMagick as your image library you can now include .ico image files as input to the sprite factory.

(see issue #18)

Order pseudoclasses by importance

If you are generating CSS psuedoclasses (e.g. :hover, :active, :visited etc) then the generated CSS class definitions will now be sorted in order of importance:

  img.icon         { ... }
  img.icon:link    { ... }
  img.icon:visited { ... }
  img.icon:focus   { ... }
  img.icon:hover   { ... }
  img.icon:active  { ... }

(see issue #20)

Replaced :csspath with :cssurl

I previously introduced a simple outrun-style racing game and followed up with some ‘how to’ articles describing:

• straight roads
• curves
• hills

… and now we’re into the final lap! (groan). In this article we will add:

• Billboards and trees
• Other cars
• Collision detection
• Rudimentary car AI
• A HUD with lap timer and fastest lap

… which will give us just enough interactivity to justify finally calling this a ‘game’.