While the isometric perspective provides an interesting art style and gameplay, it also presents us with a few challenges. Currently, I am working with a team on a Bomberman-style game. In this particular world, players are able to explore a multitude of heights in an isometric environment.

When working on an isometric game, drawing order of tiles and entities becomes important. When done incorrectly tiles or entities will be clipped by others. To ensure that they overlap correctly the isometric map tile rows should be drawn top-down. This is to say that rows of tiles in the back of the map (farthest from you) should be drawn before the tiles closer to you. (This TIGSource forum thread discusses some further potential clipping problems with isometric draw order.)

Simple isometric draw order

When dealing a multiple layer game like we are, identifying the different layers may prove difficult for players. This situation gets worse when tiles of different layers match up visually where a tile could belong to any two layers. In the image below, how can will the player tell where their character is standing? Can the character move down or will it collide with a tile?

Where is the Murid standing in relation to the other tiles?

It is not hard to lighten up the tiles of each layer. In that image above, you should notice a subtle color variance between the layers. Our character is standing on a tile which is slightly darker than the tiles in front of it. This effect is very subtle.

We can also outline the edges of tiles that have no neighbors in that direction. In our code, we set it up so that each isometric tile knows its neighboring tiles (if it has any) in every direction. With something like this already set up it should be relatively cheap to determine which edges of which tiles need outlining so that the edge is more obvious. Note that edges facing us do not need outlining since these edges and their sides are already facing us.

Left: No shading, Right: Some edge shading

Outlining these tiles can look awkward when we introduce ramp tiles. Ramps are essentially distorted rectangles where two nodes join with the bottom layer and the other two join with the layer the ramp leads to.

Isometric ramps with valid shading

The problem lies with the distortion of the ramp. Ramps facing the player appear vertically elongated, and ramps facing away from the player are vertically squished. An outline x pixels thick will appear thicker for ramps facing the player and thinner for those that aren’t.

Notice the smaller outline for the ramp

What happens if a character is completely covered by the map? Some games overcome this by showing an outline of the character sprite in such situations. Of course, in many cases outlining is more involved than taking the difference the character sprite silhouette and a larger one. For complex shapes, the technique described will not generate a uniform outline thickness. Alternatively the character sprite could be inverted to indicate the same thing.

This second solution doesn’t sound like much of a solution: We could chose to ignore this problem completely. Level designs should reflect this decision so that this situation is impossible to create. Even if players could see their own characters, should we really burden players to interact with parts of the level environment they can’t see?

Lazyfoo has a set of SDL tutorials that served as a starting point for the very first prototype. Tonypa’s and OutsideOfSociety’s tile-based game tutorials for Adobe Flash were also aiding in this development process. The first demo featured a red block that could move collide with black tiles.

Initial demo

A revision was made to make use of smaller sprite sizes to test how it scaled with a larger number of objects/tiles.

Larger (320x320) platformer demo

As I began to get a better grasp of C++, I wanted to recreate what I had done. The demo was recreated with the inclusion of a level editor using point and click. Left click places a tiles and right click toggles between available tiles.

Platformer editor

Editor with a modified level

The next step was to place a character in the level and add collision detection with the tiles. This next screenshot shows a character that is controllable by the user. The red box indicates where a collision has occurred. The collision method was based off of the jnrdev tutorials. (In the process, I came across some issues with the tile collision method described by the tutorials.)

The red box show environment collision

This project has been abandoned for the time being to work on a top-down game called BAMA. The latest source code for this platformer is available via github.

The browser-based games I have done in the past have been directed towards the design. Since my focus this time is on game mechanics, I had to find something that is simple and fun. (An RPG would be a bad example because it needs to be content rich.) Many people might start their first game with a Tetris clone, but I feel this game has been overdone. Still, modeling after another game would require less game design work.

Let me introduce one of my several game mockups: Bama, or Bam Arena, is top-down Bomberman-style game.

Bama title screen mockup

The basic functionality is simple enough. The player moves through the level placing bombs. Bombs destroy tiles and other bombs. Destroyed titles may reveal power ups to increase bomb count or flame strength. The player must complete a task in a set amount of time, such as reaching a door. Later possibilities include additional power ups, enemies, multiplayer, and specialized tiles like teleporters and pads that force the player in one direction.

Game proposal document - Click for larger

I like to keep things simple and yet visually appealing whenever possible. I’m not a graphic artist, but I can pull a few things off. As you can see in the gameplay mockup, everything is one solid color.

Bama gameplay mockup

All layouts spring from some sort of inspiration. For this one, I came across Douglas Bowman’s stopdesign. The design used several color schemes of the same layout for different pages. His brown rendition was particularly interesting because brown is not a common primary color, and yet it worked very well.

Douglas Bowman’s stopdesign

As I was playing around with my own take of a brown layout, I recalled having taken a picture of a gourmet French dark chocolate bar. The chocolate wrapper provides many of the colors as well as the logo design employed in this layout.

French chocolate bar used as design inspiration

The following is the final design as it appeared before its conversion as a WordPress theme:

Final layout design

Reflecting upon the design, my primary criticism is that it isn’t as sharp/bright as it should be. This layout may evolve in the precedent to address this and other small issues I have yet to iron out.