I've layed the groundworks for a 2D isometric rts. But I have a couple basic questions if anyone would be willing to point me to an article or offer me advice.

1. Movement: So the movement I have implmented now is a basic Euler integration where I increment acceleration, velocity then position. Now that I have a tile map, sprite sheet and a few characters on screen I've quickly realized I can't have 2D movement with 360 degrees of freedom. I must restrict movement to the tiles on my map(duh!). Is the best way to do this going from point a->b simply to increment a.x and a.y until it = b.x and b.y? And have the character move from grid point to grid point?

2. Storing Units: What type of data structures would be best to use for this type of game. There are many actions that are going to require a quick look up on a few units. Selecting units, collision detection, etc... How have you guys implemented this? I was thinking of perhaps doing some sort of map where the key is from ymin -> ymax where each bucket is +50px from the last or something. Then sorting from xmin->xmax in each bucket with the same +50px offset.

Best,

Dish

Hi,

I never worked with that game type, but long time ago i build something like POSTAL (the first one in Isometric 2D) but with mouse control, also used a tiled map.

My characters had restricted movement and they can only move from the center of a tile to the center of the next adjacent tile. This way i only had a few animation sequences (moving and shooting)

Top

Top-Right

Right

Right-Bottom

bottom

Then mirror 3 of them and i got the remaining animations:

Top-Left

Left

Left-Bottom

Awesome, thanks.

In what sort of data structure did you store your units, and what sort of lookups did you do on subsets of units?

Well...not sure it's the best way but i used a colormap (not sure if i can call that) for path finging. After i had my level built e replaced walls, lakes, etc by red pixels and all the rest by black pixels. Then i rescaled my image so i can have less pixels (got something like 512x512) and put A* model working with my image. A low sized image will give you less accurancy but is faster.

Did the same thing for bullet collision with level static objects but with a larger image so i can get more detail.

Collision between bullets and dinamic objects i used pixel collision.

note: Did not use collision between objects because path find will not alow collisions.

(sorry my english)

1. Movement

You need not restrict your characters to grid positions. It's not necessary.

While you might decide that buildings or permanent things (obstacles etc) should be on grid positions, that doesn't mean your characters / moving things have to stay on them. The collision detection is marginally more difficult, but this is offset by not having to take special measures to handle the grid

2. Data structures

Just do the simplest thing which could possibly work. Initially there's no need to do anything fancy like space partitioning etc, just store everything in a big list (or some other container)

1. Hmmm, can you expand more on this?

Since I am using 2D I thought I can only have characters move in directions the spritesheet can support. While I've done no testing to see how it looks otherwise I just assumed this to be true. If the spritesheet has directions representing 0,45,90,135,180 degrees and I rotate to represent the other directions what if my character is traveling some path that represents 35 degrees? If I use the normal northeast animation will it still look fluid? It would make me happy if this were true because restricting movement to grid doesn't look that great either.

2. Sounds like a better idea than what I was thinking. I should tape a sticky note with the acronym KISS to my monitor.

Look at a graph for a doing movement and holding all the map data, use a std::list to hold all the units or std::vector depending on your needs.