Jump to content
  • Advertisement
Sign in to follow this  
DishSoap

Beginning Isometric RTS

This topic is 1934 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!