What with a few extra side projects, I've let myself get a little bit behind on the iOS Shooter designs. But I set aside some time today to crack on and hopefully I can get the momentum back up. Today's design: modelling game data.

As I've previously identified, there will be a number of different objects that could interact with the player, with one another and with the interface as a whole. It will be crucial to ensure that each object in the game can be easily accessed with a minimum of additional processing. So today I'm looking at how these objects can be organised and related to one another bearing all this in mind.

The point here isn't to create a complete class hierarchy, with inheritance and attributes. I'm aiming to get an idea of what the objects are and how they relate to one another, which will later inform more detailed object design. This also saves me from trying to find a decent UML package in a hurry.

The hierarchy I came up with was as follows:

The starting point here is the Game object, which will hold references (directly or indirectly) to every element of the game currently in progress. A reference to this object will be available to UI Views, the main game loop, event handlers, etc, either directly or via a singleton.

Below this, the Level object contains the complete state of the level currently being played. This object may be rebuilt when a new level is started, so the Player object must be kept outside the Level to retain state between levels.

A Level will consist of currently Visible elements, and those that are yet to be encountered (which I'll call a Queue for now). The Visible object represents the moving window on the level as a whole. As the player progresses, this window will advance and objects will move from the Queue into the Visible hierarchy.

As previously discussed, the Visible and Queue trees can be divided into Background, Active objects and the Foreground. The background and foreground will be entirely graphical, so only need to consist of image segments (the ellipsis - ... - denoting collections of objects). The active objects can be divided into Obstacles, Enemies and Power-ups (not pictured - my oversight). Enemies may be grouped to create compound enemy types.

As Enemies may be grouped, it is important to note that an object will move from the Queue to the Visible tree when any part of it is in the area covered by the Visible window. As such, a group of enemies will all be moved into the Visible tree when the first enemy in the group becomes visible.

When a level is first loaded (or generated procedurally), all the objects that make it up will be instantiated in the Queue tree.

Getting a little ahead of myself at this point, but as the number of objects in the Visible tree will typically be small (<100), and queued objects will be accessed in order, linked lists can be used for storing collections of objects in the Level tree.