# Illustrated newbie’s guide to isometric game development

Out of cat-killing curiosity, I searched some information about isometric game development. I’ve listed bunch of resources to the end of this blog post, although I start the blog post with my own thoughts, code sample with bunch of images from me.

Please notice that my experience about isometric worlds is limited to about 2 hour time I spent during this weekend checking stuff and coding. I’m total newbie on this subject, but since I have some background on programming I feel have a thing or two to say that might help.

So, use these with a caution – and feel free to correct what I say.

Isometric game development principle #1: it’s just a VIEW
I have one principle which greatly helped me to understand isometric view. And here it is: isometric view is just that, a VIEW (in a way). Let’s take a simple example: think of chess board. Chess board has grid size of 8×8. We could say that there’s X-axis and Y-axis. If you say that Queen is in location X=1 and Y=5, then she sits there.

Here’s the point: Whether our game is basic square 2D, 3D or Isometric doesn’t change a thing in terms of gameplay: Queen is still located in X=1, Y=5. Isometric view only means that we look the board bit differently.

The bottom line is: your game can very well run “normal” 2D grids and whatnot in the background, it’s only the VIEW – the REPRESENTATION – that we change when we have isometric view. First code your chess game code – without thinking isometric view – and only after you’ve finished all the game logic, you could add View methods and functions that ensure things look fine.

Isometric game development principle #2: use “levels” (or “layers”) to help think
In this following I assume that all objects in the game reserve “one block” (you may think of Minecraft if it helps: (almost) all blocks have width, height, depth that all reserve 1x1x1 space).

In some isometric articles, you are recommended to create multidimensional arrays that contain 3 parameters (grid[x][y][z]), and then you are given (somewhat) complex systems for drawing the stuff on screen. I think this is somewhat okay, although it might be also bit complex. Therefore, some games can benefit from this other type of thinking:

With this in mind… let’s get back to our Chess board example.

Let’s say you’d want not to have 2 dimensional board, but also 3rd. Instead of using multidimensional arrays, I would just pile one board on top of another.

So, instead of having “board[x][y][z]“, I would have this:
- class Board, containing “grid[x][y]”
- then I would simply add more boards on top of each (board1, board2, board3… boardN). And when I need to draw something, I’d keep track on boards, and draw them from bottom to up, by saying “loop boards > board.draw”

For example, I’ve written code to draw one layer to see something like this:

And by just adding new boards, I can get this (without need to mess with additional dimension pretty much at all)

This way I can keep calculations bit simpler in one level, without need to worry about upper levels. I say again why this is important: it’s because the drawing order becomes very simple since I just need first draw bottom layer, then layer above that, then the next and so on.

I know this method is closely the slowest possible way to draw each tile always, but if you want to get started, I think it’s okay starting point and helps understand. Also, I do realize that this works when all block sizes are the same. If for example you’d have a Dragon that is 3 blocks tall, then something else would be needed (I leave that for you to ponder).

Bear in mind, this is my very first piece of isometric code, so I don’t claim it to be the best/fastest/most optimized (quite the contrary), but I do get some credit for having somewhat easy to understand code.

Isometric game development principle #3: Sun should shine from some angle…
Isometric is fun that it can produce visual oddness that nobody’s perception cannot properly resolve, sometimes at all. That’s why it’s good if some side’s of the blocks are highlighted (bit like if Sun would be shining from certain side)

Here’s example image:

I’ve highlighted some sections using white, and look at those sections… it’s quite hard to say which block is next to which block.

The solution is to change the block style a bit, as done here:

With this tiny change, we’ll get results something like here:

It’s not perfect yet, but this small change alone solved some problems (especially for the topmost layer as in some cases “holes” were difficult to spot). It’s not complete yet, so see the next principle.

Isometric game development principle #4: In Isometric view, consider changing brightness of the tiles
If you need to pile several levels in one screen, you might want to consider using brightness

The previous picture still gives us headache on some locations, and one way to handle the issue is to change brightness of the tiles, depending on which level they are.

Now, this is much better. There are still some blocks that create visual oddness (see blocks in the very left corner, highest layer: one of them looks bit odd), but much of the problems were solved merely introducing change in darkness.

Code example:
I wrote a small isometric drawing “engine”, which is not perfect, but here you have it: (comes with .bmx file including code, 3 different cubes to test things, and .exe to run in case you are curious to see how it looks)

ZIP file including art etc.
isometric.zip (678kB)

TXT file, with just the code syntax:
isometriccode.txt (2kB)

Basically, this example produces image as you saw a few paragraphs earlier.

If you want more commented examples (although my variable naming is pretty ok), then check some of the resources I’m going to list right about now.

Here’s some resources:

Introduction to Isometric Engines (1999). While “bit” old, I found this article informative stepping stone into isometric worlds. In fact, I used mainly this article to do brief sample code on my own.

Isometric pixel art tutorial – This tutorial shows you how to draw a box. Yes, that’s correct. Isometric box. While this might sound bit silly, I found this article definitely a must-read for newbies (such as me) to understand how isometric worlds work.

Isometric view – This tutorial is part of several other tutorials (see menu in the left for some “Iso” topics). Similarly to previous pixel art article, this tutorial helps get idea on how isometric view works. Illustrated images helped me.

The Complete Guide to Isometric Pixel Art (2004) – I received this article after reading any other articles (or before wrote any code) and I must say this article alone very well covers the aspects of isometric view. Most recommended.

Designing Isometric Game Environments (1996) – This article was pretty good, although I disliked chapter long links. If you can get through the visual “clutter” this article gives some fine points about isometric worlds.

Then two other resources:

GameDev forums: Isometric land – several topics about isometric stuff. Dig deeper if you want.

Making Isometric Social Real-Time Games with HTML5, CSS3 and JavaScript (book, 2011) – I didn’t read this and have no idea how good this book is. Nevertheless, it seems to be almost the only book on isometric worlds and costs \$15-20 so not too pricey to give it a test drive. If you do, feel free to tell how you liked it.

That’s it folks.

One last word: please notice that I’m like the newbies newbie when it comes to isometric handling. Use with caution.

Also, if you have some ideas/comments on obvious things I’ve missed, please feel free to share.