I have got two main goals for the next version of Molecular. I want to give the player more levels and to make progress through the game easier. With this version I’m looking to give the player about 60 levels. This will enable me to more gradually increase the difficulty through the game at a slower rate than the original. It also allows me to increase the difficulty further for the hard core amongst us.  This will be achieves partly by putting more atoms on the screen and increasing the variety. Some levels will have more than 20 atoms to move about the screen!

These two changes will be the topics of the next couple of blog entries. Starting today with the extra levels.

Being the lazy software engineer that I am I’ve changed the way I store the new levels to reduce the amount of work to create them and the amount of memory to store the graphics for them. The background of the level is represented by just the walls of the level, which is a single byte. The atoms are also recorded in this file, but we’ll go into that later.

In the first version of the game the floor of the level was described with a different id to the background and the shadows were also represented in the level map as different tiles than the floor tile. You also had to indicate the different parts of the shadow with a different tile index. So if you didn’t put it in the file there would be no shadow in the game. This time that has all changed. As I said above, now we just describe the level as walls and atoms, but what we need is the floor separate from the non-playable background. So what do you do? You implement a recursive flood-fill to fill in the floor inside the walls. For this to work though you need a starting point which is guaranteed to be within the walls. What better than the first atom you see in the level. I certainly wouldn’t use it for a rasterizing routine but for loading a few levels it was perfect. I now have levels with separate ids for the floor, the walls and the background. Next I added the shadows for the background. These would be cast from the walls onto the background. For these it was a simple heuristic that checked if the current tile was a background tile and the tile to the left or above it was a wall tile. If so, put the background tile in shadow. Of course there were a few more rules to catch the edge cases and different shaped shadows to be casted but that was basically it for putting a background tile in shadow. Great! So I’ve now got shadows, walls, background and floor all individually identifiable. Being able to differentiate between the different types is important for the rendering, effects and collision detection. 

The background is rendered as a collection of square tiles. Each 32x32 square of pixels is described by a single byte. This byte represents a tile from a palette of 32x32 tiles. We could actually get away with a nibble given how little variety there is at the moment in the tile set but its easier to just use a byte, plus it allows us to grow into a larger palette of tiles.

We render the back ground in four passes. I know it seems odd and quite inefficient but it does actually allow me to optimize the rendering of the background such that it renders quite efficiently on the original 2G iPhones. By splitting the rendering into a number of passes we can make each pass do one thing very well, such as animation or alpha blending by not changing texture states and render states too frequently as this can be a real killer on performance. The passes we have are the background the atoms move over, the tile for this is set at runtime, the walls, the animating background outside the playing area and the shadows. The atoms in the game are rendered between the background pass and the  shadow pass so they appear to move in and out of the shadow. 

One downside here is that it has caused me to put code that, while not specific to Molecular, is quite specific in functionality, into the TileRenderer, that really takes away its implied generic tile rendering functionality. Before the next product uses my iPhone libraries I’ll have to make sure to remove that code from the renderer. Most likely I’l just create an interface that the engineer can override if they want to modify the functionality.

That’s probably a good place to end this blog entry. Next time we’ll look at the atomic renderer and animation tricks used. I hope you enjoyed this entry and will be back for the next one. All the best!