krawaller

We've already laid down the foundation of the project, defining the basic idea: ripping off the age-old idea of a labyrinth where the player object can travel in all cardinal directions, but always as far as possible. The why behind the adoption of this seemingly bland idea can be found in the previous post, now we're going to get started on the how!

In this post we're going to define the data structures involved. Let's start with deciding what a labyrinth data object should look like! To do that, we have to jot down our ideas of what a labyrinth can contain:

• Of course, it has to contain some walls. 
• As the screen real estate on the iPhone is rather limited, we might do well to also allow the borders between the squares to block passage.
• We might also want special squares which somehow affect the player, for example teleporting him to a different square.
• A neat addition to this otherwise rather stale game concept might be to have other entities in the labyrinth apart from the player object. These can be moved along with the player (and kill him upon contact), or pushed along by the player, etc.
• One clone that I played had the concept of bonus objects, and you wouldn't get a perfect score when you reached the goal if you hadn't also collected all the loot on the level.
• We might also want things to happen in certain conditions, perhaps allowing passage through a wall if the player has collected the key, or pressed a button no more than three moves ago, etc.

These wishes can be abstracted into the following concepts:

• Walls, borders and entities are all of a certain type. A type has a look (class), and a flag to say if it moves with gravity or not (if it is an entity).
• We need to have effects, affecting entities / walls / borders (changing their type, or position if an entity) or the game itself (flags, counters)
• Then we can define what effects should happen in a collision between two types.
• In order to spice things up we might also want to allow things to happen conditionally.

Using these concepts we can build up an object defining a level with a somewhat advanced functionality:

With this structure, we should be able to define levels with a wide range of behaviours. Probably we'd do well to hardcode some shortcuts for the most common usecases, but this should set us off on a good start.

Now let's consider what's required to save the state of a level. What can change from the definition object?

• We need to track the position of all entities, that will fall around the labyrinth as the player makes his moves.
• The entities might also change type, so we need to track that as well.
• If a wall or border has changed, we have to store that.
• The flags and variables of the game must be kept. 
• Finally we also need to save the number of moves.

So a save object should look something like this:

In the first post, we mentioned the idea of a level analyzer module. It should take a level object, and then use game logic to calculate all possible states, and the transitions between them. The returned analysis object would have keys made up by serialized states. The corresponding values is an object with the states you can reach from that particular state, and what graphical transitions should be shown for this move. This analysis object will then be used for the gameplayer module, which will simply transit between the states, performing the animations. 

Here's a blueprint for such an analysis object: 

The level analyzer module building that object will look something like this:

And here's a sketch of the gameplayer module: 

So the bulk of the project consists of creating these two modules! I called dibs on the analyzer, so I'll get started on that right away. Little brother, get cracking on some CSS3 magic for the gameplayer module! First one to report back here with a post about the module wins remote control control for a week!