a handle is an identifier. Instead of storing a pointer to another tile, you store it's handle or it "name".
a map is an associative array that "maps" one thing to another. In this case a string name to a structure tha containes a a filename and another handle name. That's something you can look up more on your own.
For the goto_tiles, it's just a "link" of sorts. It just says, "if you step on me, you go to goto_tile". And then you look up the goto-tile in the map, load the corresponding world and go there.
Enemies and anything having to do with the AI happens on the server. Their actions are determined on the server and the clients get updated with whatever the server decides.
And again on the multiplayer: "wrapping winsock" just provides a way to execute certain functions that do technical networky stuph. Actually integrating that into your game is the hard part. You still have to define what data needs to be sent in what order and to whome. It gets really complicated really fast. So really, even getting simple things to work can be frustrating. I'm not trying to say you shouldn't, i'm just saying you shouldn't :-)
[edited by - leiavoia on June 8, 2004 1:50:56 AM]
managing possibly 100's of maps in an RPG
Author
i already work with maps in my game (great for a resource manager type thing)... anyway, i think im confused on what your saying... heres what i *think* your trying to say, but i must have screwed up because i could accomplish the same thing with a vector.. i dunno, yeah i definetly screwed up.. heres what i "think" you mean, and heres what im thinking of doing..
i must of screwed that up bad.. here is what i got so far:
the problem with this, is that i have to hard-code GOTO1, GOTO2, etc.. this sucks, hard coding is evil. who knows, i might have a city which links to 20 or more buildings... i dont want to hard-code 20 if statements with GOTO1... GOTO20..not to mention in my map editor, i will have to make 20 or more "GOTOX" images.. anyone have better ideas? thanks again leai
about the networking, i dont plan on just jumping in to coding the game.. im going to network my pong game and possibly my pacman style game, before i even attempt at designing this thing. plus, im working with someone on the networking part who has some experiance and seems to know what hes doing... do you really think i dont have a chance in hell? be honest
[edited by - graveyard filla on June 8, 2004 2:44:18 AM]
[edited by - graveyard filla on June 8, 2004 2:45:49 AM]
[edited by - graveyard filla on June 8, 2004 2:57:01 AM]
//first load in the number of warp tiles, and the paths of the goto map//now when loading in a map...if(map[y][x].flags & GOTO1){ MapSwapTile mst; mst.filename = mappaths[0]; mst.goto_tile ="GOTO1"; map_swap_tiles["GOTO1"] = mst;} //now somewhere in collision detectionif(Hit_Tile (map[y][x] & GOTO1) ){ string going_to = map_swap_tiles["GOTO1"].goto_tile; ChangeMap(going_to);}ChangeMap(string handle){ string filename = map_swap_tiles[handle].filename; Load_Map(filename);}i must of screwed that up bad.. here is what i got so far:
vector<string> linked_maps;//read in how many maps are linkedlinked_maps.resize(number);//now read in the path's to these linked mapsfor(int i = 0; i < linked_maps.size(); i++){ file_in >> linked_maps[i];}//now, in collision detection somewhere..if( Hit_Tile (map[y][x] & GOTO1) ) Load_Map(linked_maps[0]);else if (map[y][x] & GOTO2) Load_Map(linked_maps[1]);the problem with this, is that i have to hard-code GOTO1, GOTO2, etc.. this sucks, hard coding is evil. who knows, i might have a city which links to 20 or more buildings... i dont want to hard-code 20 if statements with GOTO1... GOTO20..not to mention in my map editor, i will have to make 20 or more "GOTOX" images.. anyone have better ideas? thanks again leai
about the networking, i dont plan on just jumping in to coding the game.. im going to network my pong game and possibly my pacman style game, before i even attempt at designing this thing. plus, im working with someone on the networking part who has some experiance and seems to know what hes doing... do you really think i dont have a chance in hell? be honest
[edited by - graveyard filla on June 8, 2004 2:44:18 AM]
[edited by - graveyard filla on June 8, 2004 2:45:49 AM]
[edited by - graveyard filla on June 8, 2004 2:57:01 AM]
Zipsters post is a GREAT one! I love when a game is dynamic like that makes you feel more in the game and makes it more fun to do seach and find quests and such instead of "oh i remember seeing that over there by the building" and pre-loading and caching is always good for multiplayer games cause you don''t want some people with faster connections entering a map before others when they both stepped on a swap tile at the same time it give unfair advantage to whoever gets in first or... they my not have thier buddies to back them up against a monster that is there. So you wanna cach them so there is as little loading and lagging as possible
leiavoia system''s is a start, but I think he added a little more confusion than necessary with the handle explanation Basically, special tiles in your map would have a name. In the map container (std::map), each named tile will have a MapSwapTile object associated with it. This object describes the filename the key tile is in, as well as the name of the tile we want to go to.
So let''s say you have two maps you want to go between. Map A will have a tiled named "gotoMapB". It''s MapSwapTile object will contain "MapA.txt" for the filename, and "gotoMapA" for the goto tile.
Map B will have a tile named "gotoMapA", and a MapSwapTile object with "MapB.txt" and the filename, and "gotoMapB" as the goto tile.
This is how it would work. You''re in Map A, and you step on tile "gotoMapB". It looks it up in the map. It finds that the tile we should go to is called "gotoMapA". So we look up "gotoMapA" in the map, and find that the filename associated with that tile is "MapB.txt". So we load up this map and start out on the tile named "gotoMapA".
It works the other way around in Map B. You land on "gotoMapA". We look up the tile we should go to - "gotoMapB". We look that up now, and the filename is "MapA.txt". We load the map and start on tile "gotoMapB".
Although I''ll admit that I think this system is confusing, a bit redundant, and a bit restrictive. Each tile name is index into a ADS (I''ll use that from now on to refer to the associative data structure that stores swap tiles, as opposed to "map", which will refer to game levels), whose associated data is the filename the tile is in, and the name of the tile we should go to. Right there, we need an extra lookup on the tile we should go to, just to find out the name of the map it''s in. The problem is that all the relevant data needed to transfer maps is across multiple elements in the ADS. And since you thus need to reference the ADS a second time to find out the filename to load, this restricts your target tiles in other maps to swap tiles themselves, since they have to be in the ADS to be found. Lastly, since the target tile has to be in the ADS for the second lookup, this means that you can''t store a per-level ADS, unless you plan on precaching adjacent maps. You''d have to store a global ADS for all maps, since now this global ADS has to be modified whenever you add a map, rather than requiring only the adjacent map to be modified, which is a more robust approach. Also, tile names can''t be duplicated across maps, which is a bit of a hassle for developers.
A better structure would be more straightforward - each MapSwapTile object holds the name of the map to go to, and the name of the tile in that map we should land on. Each map can now store it''s own ADS. And, whenever you land on a swap tile, it goes like this: In Map A, you land on swaptile named "gotoMapB". You look it up in the ADS. We find that we need to load map "MapB.txt", and land on tile "target". Done! And then in Map B, there will be a tile called "gotoMapA". We look it up in the ADS (a different ADS from the one Map A used, because now each map has its own) and find we need to load "MapA.txt", and land on tile "target". You can see that this has the same name as the other tile, but since they''re in separate maps it doesn''t matter.
I hope that made at least a bit of sense
Basically, special tiles in your map would have a name. In the map container (std::map), each named tile will have a MapSwapTile object associated with it. This object describes the filename the key tile is in, as well as the name of the tile we want to go to.So let''s say you have two maps you want to go between. Map A will have a tiled named "gotoMapB". It''s MapSwapTile object will contain "MapA.txt" for the filename, and "gotoMapA" for the goto tile.
Map B will have a tile named "gotoMapA", and a MapSwapTile object with "MapB.txt" and the filename, and "gotoMapB" as the goto tile.
This is how it would work. You''re in Map A, and you step on tile "gotoMapB". It looks it up in the map. It finds that the tile we should go to is called "gotoMapA". So we look up "gotoMapA" in the map, and find that the filename associated with that tile is "MapB.txt". So we load up this map and start out on the tile named "gotoMapA".
It works the other way around in Map B. You land on "gotoMapA". We look up the tile we should go to - "gotoMapB". We look that up now, and the filename is "MapA.txt". We load the map and start on tile "gotoMapB".
Although I''ll admit that I think this system is confusing, a bit redundant, and a bit restrictive. Each tile name is index into a ADS (I''ll use that from now on to refer to the associative data structure that stores swap tiles, as opposed to "map", which will refer to game levels), whose associated data is the filename the tile is in, and the name of the tile we should go to. Right there, we need an extra lookup on the tile we should go to, just to find out the name of the map it''s in. The problem is that all the relevant data needed to transfer maps is across multiple elements in the ADS. And since you thus need to reference the ADS a second time to find out the filename to load, this restricts your target tiles in other maps to swap tiles themselves, since they have to be in the ADS to be found. Lastly, since the target tile has to be in the ADS for the second lookup, this means that you can''t store a per-level ADS, unless you plan on precaching adjacent maps. You''d have to store a global ADS for all maps, since now this global ADS has to be modified whenever you add a map, rather than requiring only the adjacent map to be modified, which is a more robust approach. Also, tile names can''t be duplicated across maps, which is a bit of a hassle for developers.
A better structure would be more straightforward - each MapSwapTile object holds the name of the map to go to, and the name of the tile in that map we should land on. Each map can now store it''s own ADS. And, whenever you land on a swap tile, it goes like this: In Map A, you land on swaptile named "gotoMapB". You look it up in the ADS. We find that we need to load map "MapB.txt", and land on tile "target". Done! And then in Map B, there will be a tile called "gotoMapA". We look it up in the ADS (a different ADS from the one Map A used, because now each map has its own) and find we need to load "MapA.txt", and land on tile "target". You can see that this has the same name as the other tile, but since they''re in separate maps it doesn''t matter.
I hope that made at least a bit of sense
The point about handles is that it allows you to export your data to some config file, which of course, gets around your hard-coding problem. If you want to completely reaarange your world, it just requires to to edit the simple file and replay. no compilation required.
Author
thanks guys,
my head hurts just thinking about the whole thing.. its gunna be a real bitch to do..
also, couldnt i ''fake'' the chacheing of maps... IE, when i leave a map, i will write to a file all the data of this map, including any enemies and their positions, and over-writing the original map... then, when i re-enter the map, i would open the map file.. of course now it would be the "newer" map, which had the enemies that were left and the positions they were left in... when i wrote out the new version of the map, i could stick the time with it.. then, when i loaded in the map again, if x amount of time has passed, i could re-set the map to the original, defualt one (which would be stored with each map... so i would have mapA.txt and mapAOrig.txt... does this sound like a good / bad idea? i realize the enmies couldnt be walking around and living / updating while im not on the map, but that would be cpu expensive and harder to implement, and you wouldnt really notice it (i could even change the positions randomly so it appeared that they moved around..)
thanks for anymore help!
oh, and now i remember why i came back to this thread. what is the purpose / advantage of using an XML file instead of a regular text file? thanks again!
my head hurts just thinking about the whole thing.. its gunna be a real bitch to do..
also, couldnt i ''fake'' the chacheing of maps... IE, when i leave a map, i will write to a file all the data of this map, including any enemies and their positions, and over-writing the original map... then, when i re-enter the map, i would open the map file.. of course now it would be the "newer" map, which had the enemies that were left and the positions they were left in... when i wrote out the new version of the map, i could stick the time with it.. then, when i loaded in the map again, if x amount of time has passed, i could re-set the map to the original, defualt one (which would be stored with each map... so i would have mapA.txt and mapAOrig.txt... does this sound like a good / bad idea? i realize the enmies couldnt be walking around and living / updating while im not on the map, but that would be cpu expensive and harder to implement, and you wouldnt really notice it (i could even change the positions randomly so it appeared that they moved around..)
thanks for anymore help!
oh, and now i remember why i came back to this thread. what is the purpose / advantage of using an XML file instead of a regular text file? thanks again!
advantages of XML?
- easy to read
- verifiable contents (error checking)
- easy to get working right away
- existing libs for parsing and organizing the whole mess means you don't have to program your own config file parser
- works as a standard for all config/data files you'll ever write. You don't need to come up with different syntax and a different parser for each kind of file. the only thing that changes is what you do with the data after it's parsed.
again, TinyXML is lightweight, easy to get going, and compiles directly into your program.
------------------
on your map problem, i'd just save any permanant map changes completely sperate (blowing up a secret passage wall for instance). Then i'd time-stamp each map for your last visit. Repopulate the monsters and whatnot when you re-enter based on the time you've been gone. You need not save everything, some random fudge should suffice.
[edited by - leiavoia on June 9, 2004 1:10:42 PM]
- easy to read
- verifiable contents (error checking)
- easy to get working right away
- existing libs for parsing and organizing the whole mess means you don't have to program your own config file parser
- works as a standard for all config/data files you'll ever write. You don't need to come up with different syntax and a different parser for each kind of file. the only thing that changes is what you do with the data after it's parsed.
again, TinyXML is lightweight, easy to get going, and compiles directly into your program.
------------------
on your map problem, i'd just save any permanant map changes completely sperate (blowing up a secret passage wall for instance). Then i'd time-stamp each map for your last visit. Repopulate the monsters and whatnot when you re-enter based on the time you've been gone. You need not save everything, some random fudge should suffice.
[edited by - leiavoia on June 9, 2004 1:10:42 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
