Quote:Original post by Lode
What's the ratio they normally use for the width and height of the diamond shaped cells? EDIT: actually I think I can answer my own questions: 2:1 ratio with power of two sizes. Correct?

2:1 is fairly standard. I've seen other ratios used before but 2:1 works well.

Quote:
How would one make something like a sloped roof in an iso game, because the iso cells are only useful for 90° directions. I have tried to draw it on paper and could draw sloped roofs that were useful for any wall that is 3, 6, 9, 12, ... cells wide, but not for other widths. Is that the way they do it in iso games?

I may not be following this question fully. You can make slopes of any angle you want really, but it's useful to have the end of any slope line land on a tile corner offset by the tile height, this allows you to place flat tiles at the top of the slope. This is easier to draw than describe, but I don't have access to photshop here so I'll do my best.

Let's say that the ground (in world space) lies in the x, y plane with positive y pointing to the top right corner of the screen and positive x pointing to the bottom right. With the isometric projection this puts the z axis pointing straight up towards the top of the screen. To move things "up" along the z axis in world space you can simply shift them up the screen space y axis towards the top of the screen. The units aren't really the same but since this is all 2d art anyway we can talk about them in terms of 2d pixels.

Every tile in the map then has 3 coords (x,y,z). When drawing, the x and y screen space coords are found by a transform into screen space at the z=0 plane, (we can go into that transform later if you want, it depends on your map representation) followed by a shift along positive y for the world z coord.

When creating the tiles for a sloped tile (or other height transition) I start by drawing the outlines of tiles that represent the top and bottom of the transition. Then I find the corners of one tile and connect them to the matching
corners of the other tile to form slope edges. This defines regions that you can shade to give the illusion of height. As long as the corners are in the correct positions the slop tiles will fit perfectly together with each other and with other tiles. Some of the slope lines are hidden behind the tile surface and should be discarded.

When creating a raised tile with out a slope (such as a cliff or a stair step) you place both the top and bottom tiles at the same place, and shift the top tile straight up. The slope lines in this case run straight up and down.

To create sloped tiles I take one tile and place another next to it in one of the 8 neighboring positions. Then I shift the second tile up to the desired height and draw the slope lines. Once you create a set of tiles with the same slop you can hook them together in many differenc ways, they will tile nicely. The smallest "hill" you can create this way is a 2x2 base.

If you need a different base you can create "cap" tiles where instead of having the slope lines come to the corners of the tiles, the converge to another arbitrary point on one of the tiles (such as the center). These tiles will still tile correctly on one end of the height transition, so you can combine them with other tiles, but they will not tile at the other end of the transition so they effectively "cap" the slope. (note that they will tile with other tiles based on the new arbitrary corner, so you can use these for roof line ridges and such)

In my previous iso engine I used height transitions of 1/2 (in pixels) of the tile's screen space y height.

Here is a post I made a while back with some images showing some of this. Scroll down a bit to find it.

Quote:
What features should a user friendly iso map editor have? For example, a window of a house is not a single iso cell but uses two halves of two iso cells. Should the map editor make you place the two cells separately, or modify two cells with a single mouse click when you select "window" from a list?

I would add support for multiple tile "feature groups". This would allow you to define a group of tiles that go together and drop the whole group on the map at once. You could take it another step and add rules that are used to pick a tile based on nearby tiles (see the NWN map editor of an example of this). However I think that might be mroe work than it is worth.

Quote:
How to store an iso level? A non-iso level (but a normal square grid, like in the game chip's challenge or sokoban) it's easy, it's just a 2D matrix. But in an iso game, when you store the level as a 2D matrix, how should you translate the x and y direction of this matrix of the level file to the rotated iso map on screen?

You really have two choices here, and they both have disadvantages.

One is to store the map essentially in screen space, with every other row offset by half a tile. This has two advantages. First it's very easy to draw the map to the screen: just multiply the rows and columns by the tile size, offset every other row, account for scrolling, and y shift for z. More importantly it has the advantage that a rectangular map covers a rectangular area of screen space. As long as you cap scrolling to mid tile boundries you get a nice smooth edge and the map always covers the whole screen. On the downside, the coord system the map is in is really unsuitable for doing game logic in. It's genreally much nicer to work in a system where y and x lie along the diagonals of the screen. In that system you can pretend the tiles are square, and the distances work out nicer, plus most of your features tend to be aligned along these directions. Also doing hit checking is a little tricky in this space, although it's not exactly straight forward in the other map representation either.

The other option is to store the map in the world coordinate system I mentioned earlier. The world to screen transform is a more complex, and drawing from back to front is harder. Worse is the problem that a rectangle in screen space is now a diamond in the map. If you want to make sure that every part of the screen is always covered by map you end of with parts of the map you can't enter, which means wasted space in memory and in the file. Of course if you don't mind people seeing the "edge of the world", or you wrap your maps at the edges (think ultima 7) then this isn't an issue. You could also fill the "unmapped" area with a proceduraly generated map. (works good for oceans you can't cross)

The advantage to the is that second option is that your map is already in a nice coordinate system to use for your world.

Quote:
How should "world coordinates" work in an iso game?

I prefer the diagonal system I mentioned above (+y = upper right, -x = upper left). In my last engine this was handled as discrete integers representing rows and columns of tiles. I also supported a z coordinate, where one z step is half a screen space tile in height. My new iso engine is similar, but it uses floats for position instead of ints.

Quote:
What's the easiest algorithm to detect which iso cell corresponds to an x, y pixel position of the screen (for example for knowing which cell the mouse is above in the map editor)

There are a few options here. My old engine used a brute force approach where it considered each tile on the screen to see if it captured the mouse click and assigned it to the one with the highest z.

If you don't have multiple heights you can simply find the rectangular tile sized area containing the click using simple algebra. This rectangle covers 5 tiles (one fully and the corners of 4 others. Then using either the slope of the edges or a bitmap you can find which tile is actually hit.

Once you add z to it though there could be more than 5 tiles covering a rectangle. You could still find the rectangular volume containing the click and use a 3d spatial partitioning system to find tiles in that volume to test against. That might save you a little over the brute force approach, but if you limit the search to on-screen tiles (and you'll need a way to find those) I'm not sure it would be worth it. Whichever way you go if you have z you need to remember that a given pixel on the screen can belong to multiple tiles, so you'll need a way to pick the one you want.

Another option would be to steal a page from 3d engines in regard to picking, if you allow z positions to vary you are really in a 3d space anyway even if you are using sprites. If you have the ability to cull sprites quickly (say you are using a 3d api) you could find the volume containing your click and redraw all sprites in that region to an offscreen surface (or the back buffer) using their alpha mask, but using a different solid color for each sprite. Read the color from the surface at the click point and you know what sprite you clicked on.

Another option would be to calculate the isometric transform matrix and cast a ray back through the inverse transform into world space. If you had a spatial partition structure containing the bounding boxes of your sprites you could determine the set of tiles you hit (tiles will be square in this space). Then find the one with the highest z value. This wouldn't work quite as well for sprites since you would want to incorporate the alpha mask into the hit check, which means you would have to do a per sprite test against it's alpha mask.

Quote:
Is it a lot harder to design a tileset for an isogame than for a game with square tiles? Are there good iso tilesets available as an example?

Hmm, hard to say. Adding slopes increases your work a lot, but the same would be true for a square, top down map if it had slopes. If you don't have slopes it's probably about the same, creating an iso tile isn't really harder than a square one once you make your template. It's a little harder to make sure they tile since you can't use something like texture maker to check that, but really since you are making a whole tileset tile that's an issue for square tiles as well. Also my art skills are somewhat limited (I'm a programmer mainly), so you might want to ask an artist.

Quote:
How many layers does the map of a typical not too complex iso game have?

Well my engine supported an arbitrary number of them, as did ultima 7 and x-com. Once you add true z coord support it's not too much extra work to support lots of layers. If you don't want to go that far it's typical to have one or two "playable" layers with at least one overlay layer above it for roofs, clouds, tree tops, etc. You can do multiple overlays if you want paralax. I generally consider the sprites (players, items, npcs) to be on the same layer as the tiles, but drawn second, but you could also treat these things as being on different layers.