GalaxyQuest, you didnt really read what I wrote. I did not say make your game 3D, I said to keep it 2D and continue to use DirectDraw, but just use some 3D principles but only applied in 2D.

For example, what you would have is a unit_type class (which i am sure you do already) and in that class you contain values for like attack, defense, hit points ect..., but now just add size_radius, and movement_speed. These would be floats and movement speed could thus be like 7.8 pixels (per second or per frame update, per frame update being the better choice).

Then in your unit class, which there is an instance of for each unit you have the units location x and y (there is NO z).

Your map would be normal 2D tiles.

For example, say your tiles are 32x32, and unit "Fred" is located at x=79.3 and y=135.7
so the tile unit "Fred" is in, is:
x_tile = (int) 79.3/32 = 2
y_tile = (int) 135.7/32 = 4

so the unit "Fred" is located in tile (2,4).
For drawing fred to the screen, the center of fred would be at pixel (79,136)

So you still keep your normal 2D tiles and normal 2D game.

Now you have 2 possibilities for drawing the units. When you move a unit each frame, you can calculate what tile I it is in and then set a pointer in that tile to that unit, or you dont need to do that and use 3D methods (like in fps games) used to determine what is located on the screen and needed to draw.

If you dont want to store the units location on the tile, then its still easy to know if you need to draw it, one way would be durning each frame, you go through the game update and cycle through all the units in the game, you move each unit, check for collisions ect..., and for each unit, you also check if its on the screen (which is a simple check). You just check if the screen can see the location where the unit is at, if so, then you draw the unit then.

So for the rendering loop, you would first go and draw all the tiles to the screen, and the terrain ect..., then you go and updated all the units in the whole game, and when you come upon a unit that is visiable on the screen, you then draw it.

For collision detection, you use bounding boxes or bounding spheres (from 3D) but applied in 2D, it will be just bounding squares or bounding circles, if the bounding squares of 2 units overlap, then a collision occurred, and there are a crap load of articles out there on how to do this.

Possibility

quote:

---

Original post by Possibility

If you dont want to store the units location on the tile, then its still easy to know if you need to draw it, one way would be durning each frame, you go through the game update and cycle
Possibility

---

I suppose it all depends on the number of units. If you had
thousands then some kind of sectoring system would have to
be in place because a *lot* of them would never be on the screen.

I am a big fan of spatial partions because it put''s the
objects into a structure that lends itself to optimisation. I
remember studying Doom and when I looked at the map they had
a sector structure which split the world into a grid. Doesn''t
matter if it''s 2D,2.5D,3D or whatever. Imagine passing every
poly in the world through the renderer to see if it ended up
on the screen or not! I don''t think so.

Another point that I agree with you on is that because you only
have x,y and not Z makes very little difference the collision
problems are practically the same.

I always think of an Isometric engine as actually being 3D because it''s an orthographic projection. I am not saying to
use 3D rendering techniques but if you have a building in an
Isometric game and you have an object/sprite on top of that
building then an x,y space is not going to help you figure
out if you have collided. If you have a bridge in the game
and you walk under it and so on.

x,height,z doesnt''t matter what you call them but I would
certainly build in the 3rd coordinate into any Isometric engine
I was going to write. Then I could do neat things like walking
under bridges and stuff