Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

graveyard filla

managing possibly 100's of maps in an RPG

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

high, im working on a 2D urban action/RPG.. anyway, there is going to be lots of maps because the player will be able to walk around a city and go into the buildings... so each city would have a bunch of buildings and each building could have multiple maps (probably 1 for each floor) im just looking for anyone who has past experiance or could just point me in a good direction... there will be a "load map" tile in my editor.. where i could make a tile load a map if the player stepped on that tile (IE a door or elevater or something). i was thinking of having the path to the maps that would be loaded in stored in that map file... ie at the top of BuildingA.txt (the first floor map of a building), it would say something like "BuildingA2.txt", meaning that the "load map" tile in this map would load BuildingA2.txt... BuildingA2 would probably link to the third floor of the building or BuildingA3.txt... of course CityA.txt would link to BuildingA, BuildingB, BuildingC, etc... im just looking if anyone could give some hints /advise if this is a bad idea or not. thanks for any help and yes i realize i should not name them .txt and do the file i/o in ascii.. but that is not important now

Share this post


Link to post
Share on other sites
Advertisement
Make a graph. At the top of your map files, specify all the maps that could potentially be loaded from this map. I.e. in "CityA.txt", have "BuildingA1.txt" though "BuildingD1.txt" listed. Your game can then precache these levels whenever a player enters CityA. "BuildingA1.txt" though "BuildingD1.txt" will also have "CityA.txt" at the top of their files, because this is a bidirectional graph (the player can go both ways). If you go from CityA to BuildingA1, since CityA was already loaded, no need to load it again. The utility of putting "CityA.txt" at the top of the building file is if the player goes to another floor. The idea is if the player then goes to BuildingA2 (second floor of first building), you unload all the other maps that were connection to BuildingA1, which was just CityA. Then, when you go back to BuildingA1, CityA is loaded again. BuildingA2 stays in memory, since you were once there, but when you go back into CityA, BuildingA2 is unloaded. BuildingA1 stays loaded.

See where I'm going with this? Each level is a node, that connects to an arbitrary number of other nodes representing levels accessible from the current node. Whenever you move more than one node away from a level, it's unloaded, and whenever you move within one node from a level, it's loaded into memory again. This ensures that all adjacent levels are in memory, which everything else isn't.

[edited by - Zipster on June 6, 2004 2:06:27 AM]

Share this post


Link to post
Share on other sites
Zipster's idea is very good. I'd pay attention to that one.

Personally, i'd export a lot of that info to XML (which is what i'm doing with my own project right now). TinyXML is simple and works great for this kind of thing.

I'd give each "map swap tile" an ID handle and a GOTO handle. Then create an STL map of all the tiles there are.

struct MapSwapTile {
string filename; // file to load the data from for this tile
string goto_tile; // the handle of the file this tile points to
};

// maps a string handle to another swap tile handle. ID -> MapSwapTile
std::map< string, MapSwapTile > map_swap_tiles;



When you want to know where a tile goes to, you do something like


string going_to = GetHandle( map_swap_tiles[ "this_tile_name" ].goto_tile );
ChangeMap( going_to );



where ChangeMap looks like


void ChangeMap( string handle ) {
string filename = map_swap_tiles[ handle ].filename;
// load stuph with filename
}



Then i'd export all the handle names and their associated files into XML, which you load up when you start the game. Then you can change handles and filenames, and basically create all the worlds and areas in the game without compiling a single thing. Woohoo!

If you take the time to make it slick now, you'll save time later.



[edited by - leiavoia on June 6, 2004 3:36:14 PM]

Share this post


Link to post
Share on other sites
thanks for your guys replies..

do you really think ill need to chache the maps? i was planning on only having one map loaded - the one your currently in... then, i would load them as soon as a user stepped on a "map swap tile"...

is this bad? why would i want to chache them? i think loading them in on the fly should be fine.. i mean, yes sometimes i will have to un-load a texture, re load the new one, then re-assign the map[][] to the new maps data... do you think this will be too slow to do on the fly? it will be a huge bitch to figure out what maps connect to what maps, like that. i mean, anytime i add a map, i could be effecting lots of other maps... it would just be a real pain to try to do a system like that, although it sounds very nice..

leai, could you explain what XML is. i mean, google says extensive markup language, and i THOUGHT XML had something to do with web pages, something about writing your own syntax for commands... but now im confused, what is / and how would XML help in this situation? could you describe how it all works? thanks again for all your help!! and yes, i want to make it as slick as possible (keep in mind this is a mutliplayer game..)

Share this post


Link to post
Share on other sites
you do not need to pre-cache your world spaces. That''s just a nice little extra. What you might want it for is like this though:

Let''s say you clear all the monsters out of Area1, then move to Area2. You dink around for a second, then retreat back to Area1 ("I forgot my hat!"). Guess what? All the monsters you just killed are back! If you keep several worlds open at once, this won''t happen, but it''s not a big deal and there are other ways to solve the issue. Lag time to parse an XML file, create the world, and display is still a small fraction of a second, even without pre-caching the world. For your game, it''s not an issue. FOr an action game, it might be.

XML is a markup language for storing structured data. It can be used to mark up web pages, but it can also mark up database contents, grocery lists, anything you can think of. You don''t have to know XML in and out to get a config file working. It''s simple as dirt. The thing about it is that you specify what the contents are and how to mark it up. My resource config file looks like this, for instance:


<?xml version=\"1.0\" standalone=\"no\" ?>

<!-- RESOURCES CONFIG FILE -->

<TEXTURES>
<TEXTURE HANDLE="laser_light" FILE="workshop/graphics/weapon/laser_light.png" />
<TEXTURE HANDLE="light_sphere" FILE="workshop/graphics/weapon/light_sphere.png" />
<TEXTURE HANDLE="light_sphere_pointed" FILE="workshop/graphics/weapon/light_sphere_pointed.png" />
<TEXTURE HANDLE="light_sphere_sharp" FILE="workshop/graphics/weapon/light_sphere_sharp.png" />
</TEXTURES>




<TEXTURESHEETS>

<TEXTURESHEET HANDLE="lasers" FILE="workshop/graphics/weapon/lasers.png">
<AREA HANDLE="laser_blue" X1="0" Y1="0" X2="64" Y2="16" />
<AREA HANDLE="laser_green" X1="0" Y1="16" X2="64" Y2="32" />
<AREA HANDLE="laser_red" X1="0" Y1="32" X2="64" Y2="48" />
<AREA HANDLE="laser_yellow" X1="0" Y1="48" X2="64" Y2="64" />
</TEXTURESHEET>

<TEXTURESHEET HANDLE="explosion1" FILE="resource/graphics/anim/explosions/explosion1/explosion_128px_sheet.png">
<AREA HANDLE="f1" X1="0" Y1="0" X2="128" Y2="128" />
<AREA HANDLE="f2" X1="128" Y1="0" X2="256" Y2="128" />
<AREA HANDLE="f3" X1="256" Y1="0" X2="384" Y2="128" />
<AREA HANDLE="f4" X1="384" Y1="0" X2="512" Y2="128" />

<AREA HANDLE="f5" X1="0" Y1="128" X2="128" Y2="256" />
<AREA HANDLE="f6" X1="128" Y1="128" X2="256" Y2="256" />
<AREA HANDLE="f7" X1="256" Y1="128" X2="384" Y2="256" />
<AREA HANDLE="f8" X1="384" Y1="128" X2="512" Y2="256" />

<AREA HANDLE="f9" X1="0" Y1="256" X2="128" Y2="384" />
<AREA HANDLE="f10" X1="128" Y1="256" X2="256" Y2="384" />
<AREA HANDLE="f11" X1="256" Y1="256" X2="384" Y2="384" />
<AREA HANDLE="f12" X1="384" Y1="256" X2="512" Y2="384" />

<AREA HANDLE="f13" X1="0" Y1="384" X2="128" Y2="512" />
<AREA HANDLE="f14" X1="128" Y1="384" X2="256" Y2="512" />
<AREA HANDLE="f15" X1="256" Y1="384" X2="384" Y2="512" />
<AREA HANDLE="f16" X1="384" Y1="384" X2="512" Y2="512" />
</TEXTURESHEET>

<TEXTURESHEET HANDLE="grey_pipes" FILE="resource/graphics/world/pipes/grey_pipes_sheet.png">
<AREA HANDLE="body" X1="0" Y1="0" X2="128" Y2="64" />
<AREA HANDLE="cap" X1="0" Y1="64" X2="64" Y2="128" />
<AREA HANDLE="turn" X1="64" Y1="64" X2="128" Y2="128" />
</TEXTURESHEET>

</TEXTURESHEETS>

Share this post


Link to post
Share on other sites
Yeah, you don''t have to precache.

However, with such a system in place you could do all kinds of cool things. For example, instead of just having the levels be loaded in memory, you can also do AI processing on them in the background. Thus, monsters who were at position (X,Y) when you left the room can still move around and do monster things, so when you return, they''re at a different location. You could even allow the monsters to move around from map to map just like players. Of course, this would only work between maps that were loaded, so if you were to increase your precache level to more than one node, it''s possible to have a world that appears more dynamic.

Just some food for thought.

Share this post


Link to post
Share on other sites
what about in a client/server environment? how do you think i should handle the NPC''s ? i was thinking about having the server keep a master list of each NPC and there position and sending them out when needed (alot) would cause too much lag... im just curious to see how people thought i should approache that... thanks for anymore help

Share this post


Link to post
Share on other sites
client/server setup is a whole 'nuther ball of wax. If i were you, i'd try to make a workable single player game first. Really, it's that painfull. Adding non-trivial multiplayer support is like taking all the technical issues and bugs you have now and multiplying it by x10.

Let me say this: some games are easier to do multiplayer for. For instance, a simple pacman game with two players is very simple. There are only a few things that need to be communicated between machines: positions of players and enemies, existance or eating of dots, collecting of power ups, win/loss, maybe even in-game chat if you want to get fancy. That's pretty much it.

For a strategy game or RPG or similar, there are hundreds of messages that have to fly back and forth. Think about it: movement of characters, adding/subtracting party members, battles, enemies, hits and powerups, collecting things, statistical changes (level up), map areas, GUI control of clients, screen changes, connection, disconnection, chat, an army of system signals, new players joining, old players quiting, the state of the game as a whole + + + + + Then you have to worry about data control, who has access to what info, preventing cheating, verifying packet contents, handling cleint/server crashes gracefully, saving and loading multiplayer games, keeping everybody in sync, what to do if client data doesn't match the server state, hardware architecture differences, how large an INT really is, and on and on and ON ...

It will get to the point where you will just give up and scream SCREW IT ALL! SCREW IT ALL!!!

If you're looking for an overwhelming and excruciating challenge, go for it! But with game i know you want to make, you might just be asking for a double handfull of frustration at this point in your development.

If you are insane enough to try and do it anyway, make sure you code you networking engine smart enough that you can take the entire core out of it and transplant it into another future project of yours. That way you only have to suffer once.

"Fairly warned, be thee, says I!"

[edited by - leiavoia on June 7, 2004 12:22:11 AM]

Share this post


Link to post
Share on other sites
well.. im not working alone.. i have someone who is working on the server and writing a very nice wrapper for winsock for me.. im going to be working with him on all the networking side.. it really isnt THAT much data to be sent.. im not talking about a MMORPG here, im talking maybe 8 people connected killing eachother / NPC''s.. ok, so there is a lot... but i would still like advise on how to handle enemies.. i have to discuss it with my teammate of course but id like to know what you guys thought.. everything is going to be sent with commands / a string, and i have a pretty good idea on how to handle player interaction, but enemies are going to be a pain... keep in mind this is an action/RPG that is taken place in a city so there will be lots of maps ie for buildings and such...

Share this post


Link to post
Share on other sites
also leai, im trying to figure out what your talking about with the std::map. i just dont understand what the goto_tile member does (ie the ''handle''). what do you mean by handle and what does this member do? and im a little confused about the relationship between this handle and the key of the map...

Share this post


Link to post
Share on other sites

  • 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!