From Tile To Isometric

the isometric projection

I will tell you, right off the bat, I am not going to waste time on definitions and too much theory on isometric projection. So nothing on angles, and no crap about "well, it should not be called isometric at all!"

You can find what I think is one of the best articles on the subject here. Also, you should check out the chapter on Isometric projection from Keith Peters second animation book. In fact, I based many of the methods I'll use in this tutorial on the ones he used on his. I use his depth sorting method almost verbatim.

One text (the article) is free, but covers the more advanced type of equations. Although they are awesome if you mean to use isometric to develop a game like Warcraft in Java or any more robust language. The bump terrain stuff is pretty cool. The other text (the book) is not free. But I will cover the more important points in isometric projection as far as Flash is concerned, particularly regarding game development.

Do the Isometric Dance

I want to start with the Isometric tile. You've probably heard how to build one before, but in case you haven't... you create it by drawing a diamond shape (or rotating a square 45 degrees) and then setting the width of the shape to be twice the height of the shape. Look at the final image: this is space in the isometric world. The basic movement you would have on a square, now is rotated and squished, forming what I call the isometric dance, it has to do with that 45 degree rotation and the squished height, meaning that the key for understanding it is in the angles formed by the squished diamond, and the fact that the width is twice as large as the height.

The first thing you should realize with this shape is that simple movement in a square-- that is, movement along only one axis (only X or only Y)--in the isometric space will now affect both axis. If you move an X amount, you will actually move two steps forward one step down, because of the width proportion to the height, plus the adjustments to the angles.

One way to control this movement in code, and I will point out now that this is the wrong way to do it, is to think of movement isometrically and code that way from the start. (I will call the non isometric coordinates as 2D coordinates and the other type I will call isometric coordinates, just for the sake of this tutorial.)

With this logic you start with an initial position for your sprite, I will call it positionX, and positionY. And as the user hits the arrow keys, the movement is handled like this:

//initial position is set elsewhere as the code is initialized
positionX = 250;
positionY = 250;

var speed:int = 5;

//when keys are pressed, movement is calculated doing the Iso Dance!
if (Left Key is Pressed) {
	positionX += -speed;
	positionY += -speed/2;

} else if (Right Key is Pressed) {
	positionX += speed;
	positionY += speed/2;

} else if (Down Key is Pressed) {
	positionX += -speed;
	positionY += speed/2;

} else if (Up Key is Pressed) {
	positionX += speed;
	positionY += -speed/2;

}

//add the increment value to x and y
sprite.x += positionX - sprite.x;
sprite.y += positionY - sprite.y;

You might then end up with something like this:

Use Arrow Keys to move and Space bar to make the sprite rise.

You will notice that the logic to lift the sprite is not present in the code snippet above. This will be covered later. I will give you a hint, however: that movement is not actually isometric.

So why doing things like this is wrong? Well to begin with, that code is incomplete. The initial positionX and positionY must be isometric values to begin with, and there is nothing in the code that allows me to put an object in the middle of the green square, meaning there is no equation to transform 2D coordinates to Isometric coordinates, so the initial position is nothing but a guess. In fact, there is no 2D coordinates at all in this way of doing things. I treat the changes to X and Y always as isometric coordinates. It is all very well for simple movement control, but collision? sorting? It's a mess.

The right way to develop in isometric space is to code for 2D coordinates and simply transform them to isometric when they are rendered to screen. It is the option that gives you the greater amount of control as I will attempt to prove here. So code as if everything is in 2D and in the end, just render things differently.

So how does one code a game like that? I will show you in the next sections.

One Note on Design

I must confess, I don't like isometric games in Flash. They are fine for multi user domains, and what I mean by it are those fancy chat rooms where you walk around an environment. But arcade games? Nah. They add an extra layer of difficulty which has nothing to do with the gameplay, as I will show you when we get to changing heights (altitude) isometrically. But the main problem with isometric applications is the art. When you decide to do an isometric game or chat application, make sure you have a great designer because he will do most of the work that will ensure the thing works, believe me. Visual cues are essential to isometric space, and programmers can't do much about them. What you can do as a programmer is add some neat features, such as turning blocks transparent when the hero sprite is hidden behind them, or using multiple views so when a sprite reaches a certain corner, the space rotates to that coordinate, again helping making the sprite more visible.

But what makes an isometric engine really cool is running it with a 3D engine, in games such as Killzone for the PSP, or Justice League for the PS2 and the many, many, many similar games out there. Sadly, you won't get to do that here. But I can teach you how to build something like the GameCube version of Lode Runner as you will see when I get to Isometric Platforms.