Jump to content
  • Advertisement
Sign in to follow this  
DpakoH

need help on terrain representation

This topic is 3817 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

hello guys , i am in a really desperate need for some help . now i am making some sort of 2d RTS and came across a huge problem . i cannot figure it out , how to represent the terrain. my only idea is to make it 2d array ,but i cannot come with solution how to render it based on this array, and later implement smooth unit moving from one "tile" to the next. any help will be appreciated. i searched the forum for some tutorials but most appeared to be dead. and the others didnt help. any links to resourses would be great. come on guys, help me out !! :)

Share this post


Link to post
Share on other sites
Advertisement
xna is not an option for my project. plus i checked, and i am still checking the tutorials there , but i didnt find anything useful for solving my problem .
and just to make it clear , i am trying to make a terrain like in starcraft , i call it 2d , but maybe it is right to name it isometric, i am not sure about that.

still looking for help :)

Share this post


Link to post
Share on other sites
It might help a little bit if we had more information on what you are using as far as a graphics lib but the concepts are the same regardless.

Here is an article on smooth scrolling a tile map that should be useful for you as it gets the concepts across in a pretty general manner.

The concept I believe you are looking for though is time based movement or framerate independent movement. In a general manner this means a sprite moves x amount of pixels per y period of time.

For example, a unit for some reason needs to move 2 tiles to the right. The actual distance is say 64 pixels. If your unit moves at 64 pixels per second you could use something similar to the following to move the unit:

void rts_unit::move( float elapsed_time_in_ms )
{
// unit speed is in seconds so we divide by 1000 since we have milliseconds
float change = (unit_speed*elapsed_time_in_ms)/1000.0f;

switch ( unit_direction )
{
case LEFT:
unit_position_x -= change;
break;
case RIGHT:
unit_position_x += change;
break;
case UP:
unit_position_y -= change;
break;
case DOWN:
unit_position_y += change;
break;
}
}

I recommend you read through the articles and resources section here on Gamedev a little more thoroughly. Many of the relevant articles are from the late 90s however the concepts are still sound.

Here are a couple more from the Isometric and Tile Based Games articles I found helpful:
http://www.gamedev.net/reference/articles/article934.asp
http://www.gamedev.net/reference/articles/article724.asp

Share this post


Link to post
Share on other sites
Data representation is important, and if you're using a square based tile map for your implementation, an array is definitely good. You need to keep in mind what needs to be stored per tile.

For example, each tile needs the following information
Texture ID - This is so you know what terrain to draw
Passable/units allowed - can a unit occupy this spot, a structure, only some units?
Currently Occupied By - The ID of the unit occupying the square

Why all the information?
The texture ID is worth storing for a fast reference to the type of tile this will be.
The passable variable determines if units can occupy the square, or what specific units, it's unlikely you'll allow building on some jagged rock formation for example, and that same location might allow only certain infantry units to occupy it
Finally the currently occupied variable would reference the unit in the square right now (or the unit moving into that square.) This is necessary to allow quick look ups of units within certain ranges, instead of searching the unit array, search by the map array location and use the array location in the unit array as the unit ID (one method.)

When you store the units, you'll double up and include their location as one of the variables, if you store it efficiently it won't take much additional space, but it will make looking up the location by unit much faster.

Figure out the minimum data required to store each item. For example, if you have no more than 256 different tiles, you can use a byte or char type to store that information, if you're storing an array ID, a 2 byte unsigned integer type will be sufficient for that.

There is a really good tutorial for basic tilemaps. The link evillive2 gave is one of the best, but the specific link in that set that would likely help you is this one on Tile/map base data structures

I hope that helps


Share this post


Link to post
Share on other sites
not entirely sure what you need out of your terrain, I'm working on a top down 2d game as well and have got a somewhat functional level editor together. It's definitely got some work to be done before it's finished but if you want to take a look at the source and see how i did it go right on ahead.

http://www.2shared.com/file/3534759/83eb03ea/leveleditor.html

I use sdl, but no matter what graphics lib you're using you can handle your map the same way

Share this post


Link to post
Share on other sites
Personally I would represent each array cell with a structure.

Also I would like to add that if you plan to have pathfinding in your game (as many RTS games do) then you will need to store the movement costs of your tiles. Since you might have improvements that can alter the movement values per tile then it might be a good idea to store the movement costs seperate from the tile ids.

If you are not planning to have support for things like roads, ect then you could get away with just setting the movement costs based on the texture id's though.

When it comes to file formats I would recommend searching around for an already existing tile editor. I have posted links to Mappy so often that I won't post any more links, do a google search. Even though this editor may not be all you need for your game, it would allow you to get started and it can export to a wide variety of file formats. Personally I would recommend saving the data to a binary file because your maps will take up less space then saving them in a text based format (and taking as small as space as possible is important if you were planning to share the maps over the internet or whatever like in SC)

Considering you more than likely do not want to constrain your units to a grid, it is a good idea to research various spacial partitioning systems like Quad Trees so that you do not draw units that are off screen.

Of course unless your drawing a straight top down perspective then you also have to concern yourself with depth sorting (a.k.a layering). Although using a 3d engine to render 2d graphics can give you "Free" layering, a lot of time you have to sort by depth anyway if you are using alpha channels (I know this is the case with OpenGL).

Keep in mind that when you are designing your level editor you will more than likely need to be able to place a graph system for your enemy AI to follow (I believe the SC editor has something like this, if not SC then C&C does).

Good luck!

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!