## Tilebased Games: organizing

Moderator
Posts: 508
Joined: 2002.09
Post: #1
Hey all,

I have a big interest in making an isometric game, and though I know the coding procedures more or less I still have some problems regarding the organization of my tiles etc. So I write this with an isometric game in mind but I'm sure the techiques apply to all tilebase games (hence the title of this thread).

If I understand correctly, the tiles don't have to be square, so rectangular tiles are also accepted, right?
Now, let's take StarCraft as an example. If I get this correctly there are basically 3 layers in the game. One layer for the ground (grass, water, road, ...), one layer for the buildings and creatures and one layer for flying things.
What troubles me is basically how to organize this. For example, in a game with just the ground layer, it's easy to detect where the player can walk and where he can't. But in most games there are also buildings, and if I'm not mistaken the tiles for the buildings occupy more ground tiles (eg a bulding can occupy 2x2 ground tiles).

To get a bit more technically, do I need 3 arrays for each layer? So I can check whether the player is on a ground where he can walk, if so check whether the tile I want to move to doesn't have a building, etc..

Sorry if I sound complex, but basically I wanna know how to organize my tiles (and this includes the map files aswel) so I can start writing a tile based game. I tried doing a tile based game before, but I got stuck in organizing my files and my map file to generate the world.

Hopefully someone can help me out here.

Big Thanks

"When you dream, there are no rules..."
Sage
Posts: 1,487
Joined: 2002.09
Post: #2
In the StarCraft editor you might notice that even though the ground tiles are isometric, the world is still built on a screen oriented grid. You also might notice by the way that the characters on the map react to the screen oriented grid. The last point to make is that the map is oriented to the screen and not to the isometric world. By keeping the graphic data and collision data separate, they kept themselves from getting fatal migraines.
Diplomtennis
Unregistered

Post: #3
I don¥t now if this is the "correct" way to go but what I do is:

a) a tile based map with the data stored in an array.
b) a list with the Players, Monsters etc. This can be a linked list or an array.
c) the same as b) for flying things, shots etc.. if you need any.

I found this a practical way to go.

D
Moderator
Posts: 508
Joined: 2002.09
Post: #4
OK, so I think I basically understand how an isometric engine works, but I have one little doubt. What about shadows? I mean, suppose you have a tile that represents a tower, but that tile has a shadow.
Do I need to make additional floor tiles with the shadow on them or are there better methods?

I'm thinking that perhaps making a real 3D world and just change the perspective of the camera might be easier, but I do wanna try doing this in 2D first.

The first thing I intend to do is write a sample map editor and from there I can build up my game engine.

Ah, one last thing. Does anybody have any idea how I would animate my player from going from tile A to tile B?

"When you dream, there are no rules..."
Member
Posts: 233
Joined: 2003.05
Post: #5
I am working on an isometric engine right now, and I'm having some major headaches. My problem is that I am allowing rotation and I'm mixing 2D sprites with 3D tiles and... well, it's messy.

As with shadows in any game you can go from basic to realistic and the more realistic you get the harder it is to pull off.

If the shadow of your tower is going to land on a flat area (no graded surfaces like a ramp), it's not too hard. Just use a transparent sprite and lay it down. If it reaches across more than one tile, break the sprite up into sections. You could even drop the shadow on different heights that way. However, if you are going to have slanted surfaces in your isometric engine... it will get tricky.

Of course, you can just make assets that use lighting from above and all the shadows will be directly bellow objects. This is most useful for gauging heights of items that fly or float anyway.

"Pay no attention to that man behind the curtain." - Wizard of Oz
Sage
Posts: 1,487
Joined: 2002.09
Post: #6
I'd really have to say that 2D isometric games aren't worth the hassle anymore. You can do a lot of the stuff in 'real' 3D from a fixed orthographic angle and be far better off. If you set it up right, it will look exactly the same, and everything will be easier, shadows, blending, sorting, etc.
Member
Posts: 233
Joined: 2003.05
Post: #7
Also, OpenGL is almost always preferrable for 2D game graphics anyway. (Especially on the mac!)

"Pay no attention to that man behind the curtain." - Wizard of Oz
Moderator
Posts: 508
Joined: 2002.09
Post: #8
aaronsullivan Wrote:Also, OpenGL is almost always preferrable for 2D game graphics anyway. (Especially on the mac!)

Well, I'm putting my isometric game idea aside and instead of that I'm learning some OpenGL. I wanna try to make some easy to use Cocoa classes, especially for loading and using textures.
I'm gonna base my code from the NSOpenGLFullscreen sample code (from Apple) and see how far I go.

Also, I understand that for 2D usage of OpenGL I should use the glOrtho() function, but how exactly do I use that. I started my project drawing a simple square with the glPerspective() function, but when I changed it to glOrtho() I couldn't see my square.
Does glOrtho() put the camera looking from top to bottom or something, or how does it work?

"When you dream, there are no rules..."
Sage
Posts: 1,487
Joined: 2002.09
Post: #9
You have two options to use for an orthographic view. glOrtho and gluOrtho2D, they both do nearly exactly the same thing, but glOrtho is more flexible.

glOrtho is used like so:
Code:
`glOrtho(left, right, bottom, top, far, near)`

and gluOrtho2D is used like so:
Code:
`gluOrtho2D(left, right, bottom, top);`
which is the same as:
Code:
`glOrtho(left, right, bottom, top, -1.0, 1.0);`

What does all this mean? Say you want a viewport with the top left corner at (3, 10) and the bottom right corner at (5, 12) then you would call:
Code:
`gluOrtho2D(3, 5, 10, 12);`

so the call for the vertex glVertex3f(4, 11, 0.5); would put a vertex in the middle of the screen. What's the z value of 0.5 for? Nothing really, things will still draw at the same place on the screen, but if you have depth testing enabled, you can use it to have openGL automatically sort your sprites depth for you. The catch is that you have to stay between the near and far values.
Vertizor
Unregistered

Post: #10
Taxxodium Wrote:What about shadows? I mean, suppose you have a tile that represents a tower, but that tile has a shadow.
Do I need to make additional floor tiles with the shadow on them or are there better methods?
Your non-terrain assets such as player units and buildings, can be plain ol' sprites. When you design the sprites though, just scale them to fit in however many titles as needed. That does not imply that they have to all fit within the boundaries of the tiles.

Imagine your compositioning cycle to look like this:

- Layer 1: tile based terrain background. Layout your ground tiles.

- Layer 2: Now you're working with sprites not tiles, they can be any shape or size. Blit them on top of the terrain.

- Layer 3: Sky units. Don't for get fog of war and shroud.

Collision detection shouldn't be based solely on the number of tiles a structure appears to occupy on screen. Take for example, you mentioned a tower. Ok the structure itself takes up 2x2 tiles. But with the shadow, the overall size of this sprite may be 4x2. If your sprite rendering engine supports images with alpha data, the shadow pixels will be semi transparent. That way when this whole sprite is blitted over the terrain the shadow will blend with the underlying terrain. But the structure itself is still really occupies 2x2 titles. It gets trickier if units are allowed to go behind structures. Using Starcraft as an example again: sometimes units will look like they're going behind a building, the unit is blitted first, then the building so the building sprite is overlapping the unit sprite a little bit. Your collision detection code just needs to determine how much ground the structure really occupies. Do collision detection on that value, not the value of how much space a sprite occupies as seen on screen. Otherwise, units would collide with the structure's shadow and that wouldn't look right.

I wouldn't completely seperate everything into seperate layers. That thought process is like: First pass - blit the background. Second pass - blit the building sprites. Third pass - blit the land units. Fouth pass - blit the sky units. There are times where the land units can be overlapped by the building, like what I was describing above. Take for example: a unit that approaches a building from the bottom, the unit's sprite would overlap the building to show that its standing in front of the building, almost litterly on top of it. But if the unit approaches the building from the top, to make it look like the unit is hiding behind the building, you'd have to blit the unit first, then the building over it.