I'm a very big Diablo fan (I like the original one specially), and I always wanted to kind of create my own clone of it someday, with my own game mechanics and such.

I'm learning a lot by watching the streams, but I'd like to know what would be required to transform HMH into an isometric game. If the game was 3D to begin with, i figure it would just be a matter of changing the camera position so that it matches the desired angles, and maybe also project the game orthographycally.

But what about 2D content? Would the tilemap/chunk structures be the same and just the rendering that would be changed somehow to display it's content in an isometric view, or are there more implications to it?

I'd assume every asset in the game would have to be created with isometric dimensions to begin with too right?

Would it be trivial to make the current game display in an isometric view?

I don't see any incompatibilities between the current game and isometric graphics (well, except the drawing part, obviously, but that's quite minimal at the moment).

When you think about it, an isometric map is just a tilted grid :)

I'm not sure what you mean by "isometric measurements", but as far as I understand, you can just use the same units of measurement in flat 2D as in isometric.

One thing that might be a bit different is that you may want to bind the arrow keys to "diagonal" movement w.r.t. the isometric map. Unless I've missed it, the code still has diagonal movement twice as slow as vertical/lateral movement.

It's not much different. Most of the gameplay code would be identical, the main difference would be in the rendering. The math for mapping world pos and tile pos to screen pos gets a little more complicated. For a 2D isometric engine, the main difference is in the rendering. You'd have to draw tiles and sprites together, and make sure that they are drawn in order back-to-front to ensure things overlap correctly. But from the hints Casey has given about the renderer, I suspect when we get to the renderer part we'll be doing something like this anyways, so adapting the final engine to support isometric might be pretty trivial.




Here's a really craptastic iso tile game I did for a game jam a while ago, you can see the drawtiles code here:

wander drawtiles on google code

This is game jam code, so it's really messy and worse than even prototype code, but it loops over the tilemap in diagonal rows, and just skips everything that's out of bounds. Then I just loop over every object for every tile I draw and draw any sprites that are on top of that tile, not quite right because it overlaps the edges, and def earns a piggy cap but a game like diablo 1 would be pretty much the same thing as this just a lot more elegantly written.

The main point to realize is that in isometric perspetive there is no foreshortening. What this means is that whether something is "close" or "far" relative to the vieweer (ie, drawn on the screen relative to it) everything retains the same height.

In 3D things that are close to you appear larger than things that are far away (both in computer game 3D or in real 3D, aka in real life). Isometric perspective is set up in such a way that this doesn't apply which makes rendering a map of objects a lot simpler math-wise. If you look at the image that joeld42 posted, you will see that the sizes of the characters in the map (and the tiles themselves) remain constant no matter how "far" they are.

Thus, as norswap mentioned, an isometric grid is just a tiled grid, but as joeld42 said the order in which the tiles are drawn is important since those "closer" need to be drawn after those that are far away or everything will look wrong. This will require a little more thinking of the rendering order (something Casey will probably get into once he starts adding more sprites into the screen), and a slightly different movement code (diagonally as norswap mentioned). Other than that, making an isometric game from the handmade hero base code will be a trivial change.