I am making a 2d rpg game and I was wondering what would be a good stl or boost container for the map.
It will probably be using the Cartesian coordinates system were (0,0) is spawn because it has a semi infinite world (Think minecraft). It needs to be able to jump from point to point because I want to implement large distance teleports in my game (A few thousands of tiles).
Any good ideas to use?
(list, array, vectors, map, multimap, unordered_map, unordered_multimap?)
A good container class for my tile based game map
In general std::vector is normally the right container for the job. However, without more details about how you will be using it is difficult to tell.
Assuming you break up your map into chunks and chunks are loaded/generated on the fly I would start with something like.
[source lang="cpp"]
typedef std::vector<std::vector<Tile>> Chunk;
std::map<const Point, Chunk>
[/source]
Of course you will want to have the implementation details of the map abstracted away. So I wouldn't spend too much time thinking about it and implement it as simple as possible and if there are performance/memory problems then investigate if your choice of container is at fault.
Assuming you break up your map into chunks and chunks are loaded/generated on the fly I would start with something like.
[source lang="cpp"]
typedef std::vector<std::vector<Tile>> Chunk;
std::map<const Point, Chunk>
[/source]
Of course you will want to have the implementation details of the map abstracted away. So I wouldn't spend too much time thinking about it and implement it as simple as possible and if there are performance/memory problems then investigate if your choice of container is at fault.
For my own game, each area in the game is is split into 'chunks'. I just load the chunks around the player.
Each chunk is 'x by x' tiles wide/high (where I made 'x' to be 20 for my game, so 20 by 20 tiles), and an unbound number of layers.
For storing the tiles, basically I just use a std::vector, and dynamically allocate each tile in the vector. Tiles share images if they happen to be the same.
I could have just as easily used an array, since the size of the layer is constant.
Lists and maps wouldn't be good, because your priority is speed of traversal, and you don't ever remove/insert elements into the container (if you want to change/add/remove a tile, you just alter the Tile object in the container, but you never remove the element itself).
So either use an array or a vector of pointers pointing to a small compact dynamically initialized class that shares the images between each other.
'No' on lists, 'no' on maps in this situation.
If you need fast seamless loading of chunks, there's lots of great optimizations you can do - but you'll cross that bridge when you get there.
Each chunk is 'x by x' tiles wide/high (where I made 'x' to be 20 for my game, so 20 by 20 tiles), and an unbound number of layers.
For storing the tiles, basically I just use a std::vector, and dynamically allocate each tile in the vector. Tiles share images if they happen to be the same.
I could have just as easily used an array, since the size of the layer is constant.
Lists and maps wouldn't be good, because your priority is speed of traversal, and you don't ever remove/insert elements into the container (if you want to change/add/remove a tile, you just alter the Tile object in the container, but you never remove the element itself).
So either use an array or a vector of pointers pointing to a small compact dynamically initialized class that shares the images between each other.
'No' on lists, 'no' on maps in this situation.
If you need fast seamless loading of chunks, there's lots of great optimizations you can do - but you'll cross that bridge when you get there.
[Edit:] Going off of colinhect's point, I'm assuming you are talking about tile-based maps since you mentioned "tiles" and "Cartesian coordinates". If you are going for sporadically placed images, then a list would be preferred.
No, it doesn't make sense at all to have access the "-5th element" in any container that exists in real life or in programming. That's a logical impossibility. You have to think of all the container classes as "containers". How you use the containers is up to you, but don't start thinking that the containers are anything other than ways to store generic elements.
You should to create a MapChunk class, or whatever you want to call it, that uses the container internally. The container (the vector) isn't the MapChunk, it's a container that the MapChunk uses internally that the programmer using MapChunk (you) doesn't need to know even exists.
Your MapChunk can take negative player positions, and MapChunk internally converts it as needed to make things work. But don't think of the internal implementation (the container) as the class itself (the MapChunk).
You should to create a MapChunk class, or whatever you want to call it, that uses the container internally. The container (the vector) isn't the MapChunk, it's a container that the MapChunk uses internally that the programmer using MapChunk (you) doesn't need to know even exists.
Your MapChunk can take negative player positions, and MapChunk internally converts it as needed to make things work. But don't think of the internal implementation (the container) as the class itself (the MapChunk).
[source lang="cpp"]
typedef std::vector<std::vector<Tile>> Chunk;
std::map<const Point, Chunk>
[/source]
Why the `const'? What does it even mean in this context?
[quote name='colinhect' timestamp='1332868008' post='4925740']
[source lang="cpp"]
typedef std::vector<std::vector<Tile>> Chunk;
std::map<const Point, Chunk>
[/source]
Why the `const'? What does it even mean in this context?
[/quote]
Perhaps I meant to make the Chunk const. There is no reason to have the key const.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
