I'll be using an array of pointers hold the TILE information but I wondered what people were using to store information on walls. I'll be having some maps that are mostly open ground and I wouldn't want to waste all the memory on storing NULL pointers. I've been looking at sparse arrays. Maybe they're OK for retrieval and storage but in the end it's a linked list from what I understand. Suggestions? ZoomBoy Developing a 2D RPG with skills, weapons, and adventure. See my character editor, old Hex-Tile editor, diary, 3D Art resources at Check out my web-site Edited by - ZoomBoy on 11/11/00 9:29:27 PM

My main reason for replying was to say very good job on your coding so far. I read your website about a week ago and its nice to hear from the actual programmer. I couldnt help but laugh when one of your testers complained about your graphics...hehe.

Anyways, your question is a little vague so you can clarify after my post if its not what you asked.

[note: im still in design phase..no implementation yet!]

The way im gonna start the tile structure is to inherit all tile map objects(ground, npc''s, trees, walls...) from a base object class. Each map x,y will be a linked list with the base or "head" object being of course the ground(always). This way all objects will have the potention to be manipulated..such as walls being built or destroyed.
As far as actual data members of a wall object i can only give some ideas of what i would include (excluding the obvious tile coordinates and related). I want walls like in AoE so there would be multiple images corresponding to the stage it is in being build/destroyed along with data members to relate these phases..like simple int phase = (0,1,2,etc). Im kinda just pulling stuff out my ass right now but hopefully you can get some ideas from here...i kind of think of a wall as a standing NPC only without the AI and such.

post more if i didnt address your question right. 8)

aka John M.
Never give up. Never surrender!

</body>
</html>

You can implement sparse arrays on top of hash tables. It can be more efficient, depending on how you plan to use the sparse array.

To SiCrane:
Hashing it hmmmm.....so

x_arrayposition * SuitableMultiplier + y_arrayposition

SuitableMultiplier - I'd prefer 1000 for debugging purposes but to save some mults I'd shift for "de-hashing"

Back to the books to search for hashing

To GalaxyQuest:
My main concern was the memory cost for having a few walls up
in a 500 x 500(these would be the max) array for the map(each TileInfo object would have 20 to 40 bytes(I have AI path-finding info there as well), Each WallInfo Object would have 10 to 20 byte cost)
500x500x30 = 7.5MB
500x500x15 = 3.75MB for 100 or so walls
I'm looking to get at a lower memory budget
=================== later =========================
Actually I've just done a test of 500x500
map 13.6 MB
walls 5.8 MB
If I offload the AI stuff and create section that hold the info dynamically
map 8.8 MB at max 500x500

Each screen would have 26 tiles across by 33 down
18 screens across by 15 down Probably my maxes are too high
=================== later =========================

I think in the editor I know can get away with it(64MB available after basics on my machine). But for the game itself I'd look at a different system. Your linked list has the memory advantage going for it. There is the cost of the next pointers plus the time spent flipping through the list. (in your base object make sure you do the linked list stuff) But it should be a reasonable compromise.

ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, old Hex-Tile editor, diary, 3D Art resources at
Check out my web-site

Edited by - ZoomBoy on November 13, 2000 3:47:17 PM

I hear that one way to conserve memory is to have only so many screens loaded into memory at one time. Like, 9 screens at once. One for the screen the player is in, and 8 around the player. Then, when the player gets to a certain spot, free the screens not in use anymore and load the next bunch in. It sounds like it could work, especially since you seem to store your stuff in screens.

So that is only 26*33*9*20 bytes or 154.4 KB max. Nice if you can manage it without the speed decrease. If you need to save information that happened in other screens (like opened doors), you can always do what apps do and have temp files.

-Blackstream

Excellent suggestion Blackstream.
I think I''m going to keep the large memory cost for the editor and for the in-game stuff I''ll have the wall information in a linked list/sparse array and I''ll take a look at your idea of temporary loading just a section of the map at a time.

They''d be zoning like in EQ oooooooooooh


ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, old Hex-Tile editor, diary, 3D Art resources at
Check out my web-site

Just wanted to say that I think world subdivision is the way to go and will eventually be an absolute necessity.

It also frees you from a fixed map size.

I used 8x8 tile subdivisions. I find smaller subdivisions preferable because of loading times. I personally would get away from using sizes based on screen width and height for portability. What if at some point you decide the user needs to zoom the screen in and out? Make you''re subdivisions smaller than the screen. You want them to be able to enter and leave memory rapidly so the user doesn''t experience hiccupping as they wander around.

Within each subdivision I have the 8x8 tile info and then linked lists for static objects.

I maintain completely seperate lists of all non-static objects

example: (c++ pseudocode)

#define CHUNK_WIDTH 8
#define CHUNK_HEIGHT 8
#define WORLD_CHUNK_HEIGHT 100
#define WORLD_CHUNK_WIDTH 100

class MapChunk
{
private:
Tile Tiles[CHUNK_WIDTH * CHUNK_HEIGHT];
Wall *pFirstWall;
Object *pFirstObject;

public:
DrawAll();
DrawTiles();
DrawWalls();
DrawObjects();

//and of course methods to modify and access all the data
}

Better if walls where a sub-class of objects.

my world class looks something like this:

class world
{
private:
int CurrentChunkX;
int CurrentChunkY;
MapChunk *Chunks[WORLD_CHUNK_WIDTH * WORLD_CHUNK_HEIGHT];
Object *NonStaticThings[WORLD_CHUNK_X_WIDTH * WORLD_CHUNK_Y_WIDTH];

public:

//simple display routine
void Draw(int x, int y)
{
//check my zoom level
//zoom factor is radius of chunks to draw around current
for(yn = y - ZOOM_FACTOR; yn < x+ZOOM_FACTOR; yn++)
for(xn = x - ZOOM_FACTOR; xn < x+ZOOM_FACTOR; xn++)
{
if(Chunks[xn + yn * WORLD_CHUNK_WIDTH)
Chunks[xn + yn * WORLD_CHUNK_WIDTH]->DrawALL();
else
{
LoadChunk(xn,yn);
Chunks[xn + yn * WORLD_CHUNK_WIDTH]->DrawALL();
}
}
}

};

I have a file containing all the map chunks in the world. The header for this file contains offsets for each chunk.

As the player moves around I load the necessary chunks into memory, usually an area of about 5x5 chunks, but since I allow zooming in and out that can go up or down. Each time I draw a chunk I time stamp it. I have a seperate thread which just cycles slowly through the map and removes chunks from memory that are beyond a certain distance from the player or haven''t been drawn in a very long time. It''s easy enough to keep track on the number of chunks in memory and force a clean up when approaching it. If you''re forward thinking enough you can also add background threads to load chunks into memory that the player is approaching and only pause when needing to draw a chunk that isn''t fully loaded yet.

Freeing up the static and non-static has advantages as well. A big one is that you can update the lists of non-static objects around the player more frequently.

I am a firm believer and keeping the editor and the game code very close together. I do everything the same except for the "clean up thread" which is disabled during editting. And editting is just a seperate mode of the actual core game.

''sall,
luck,


mat williams
zero sum software
www.zero-sum.com

that/Mat

Thanks, your response was an eye-opener for dynamic map culling and storage.

As for the editor/game combination there''s something to be said for handing off an editor to someone else that isn''t tied into your game engine. I think it forces you to compartmentalize things more effectively in your game design. Not that the editor/game combo is evil but just a different way of looking at things.

ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, old Hex-Tile editor, diary, 3D Art resources at
Check out my web-site