Nodes
So I want to create a two-dimensional array full of nodes as a map to be navigated through. I'm new to nodes and unsure of how to do this, although I have the general idea. Can someone tell me if i'm on the right track, and if not, point me in a better direction? Thanks.
Also, How would I link the directions to another place in the array?
Also, How would I link the directions to another place in the array?
|
|
If you have access to the whole map, your nodes do not need to know about the existence of their neighbors.
Well, my goal is to have a large two dimensional array for the map, but of course you won't be able to traverse in every direction in every tile. Perhaps instead of a two-dimensional array of nodes, just have the nodes, and connect them as needed, this will avoid large unused portions of a map array. I'm just unsure how to implement what is in my head, any tips?
closed account (D80DSL3A)
I've been giving this some thought, but haven't wanted to post just yet. I'm doing so due to your continued bumps.
Maybe offer more than just bump:) when bumping? Any further or clarifying thoughts?
A couple of difficulties I see right away if your intent is to dynamically allocate areas as the map is expanded during play.
1) Keeping track of ownership for the purpose of proper cleanup (deletion) of areas.
Up to 4 areas would possess a pointer to any given area. Shared pointers may work well here, though I'm not yet practiced in using them, so I couldn't advise on implementation. I'd either learn to use them or use a "master" vector<Area*> to store one copy of a pointer to each allocated Area. This would permit easy cleanup, but there wouldn't be any info re. relative positions of the allocated Areas.
2) How to judge whether to allocate a new Area? Just because one Area.East = NULL doesn't mean there is no Area to the east. They may just be unconnected. It could be that 2 steps south + 1 step east + 2 steps north brings you to a valid (allocated ) Area. This would be the Area east of the starting point. Perhaps it is an element of strategy that one must find one area from another before they can be connected? You could then be holding pointers to both areas and be able to connect them.
Are connections between adjacent areas always 2 way? Or, might A1.East point to A2, but A2.West = NULL? ie, it's a one way street?
One could know they've found an adjacent area by keeping track of the steps taken. If West +-1 or North +-1, then the areas are adjacent.
3) Others I haven't thought of yet.
These features could be implemented more simply with a 2D array of areas. Each area could have 4 bool variables for direction (instead of 4 Area*'s) +1 other bool for doesExist?. Finding (or verifying) existence of adjacent areas would be very simple.
Please elucidate further on how you plan to use/manage the areas.
Maybe offer more than just bump:) when bumping? Any further or clarifying thoughts?
A couple of difficulties I see right away if your intent is to dynamically allocate areas as the map is expanded during play.
1) Keeping track of ownership for the purpose of proper cleanup (deletion) of areas.
Up to 4 areas would possess a pointer to any given area. Shared pointers may work well here, though I'm not yet practiced in using them, so I couldn't advise on implementation. I'd either learn to use them or use a "master" vector<Area*> to store one copy of a pointer to each allocated Area. This would permit easy cleanup, but there wouldn't be any info re. relative positions of the allocated Areas.
2) How to judge whether to allocate a new Area? Just because one Area.East = NULL doesn't mean there is no Area to the east. They may just be unconnected. It could be that 2 steps south + 1 step east + 2 steps north brings you to a valid (allocated ) Area. This would be the Area east of the starting point. Perhaps it is an element of strategy that one must find one area from another before they can be connected? You could then be holding pointers to both areas and be able to connect them.
Are connections between adjacent areas always 2 way? Or, might A1.East point to A2, but A2.West = NULL? ie, it's a one way street?
One could know they've found an adjacent area by keeping track of the steps taken. If West +-1 or North +-1, then the areas are adjacent.
3) Others I haven't thought of yet.
These features could be implemented more simply with a 2D array of areas. Each area could have 4 bool variables for direction (instead of 4 Area*'s) +1 other bool for doesExist?. Finding (or verifying) existence of adjacent areas would be very simple.
Please elucidate further on how you plan to use/manage the areas.
Last edited on
I'm here. My friends kid thought it would be funny to mess around on my account and got it banned. Anyway, a simple two-dimensional array of x/y coordinates seems like it would a great alternative. I'm thinking in my a struct of bools for the exits, a string for the area description, strings for the entry descriptions, IE "You come upon a wooden house!". Eventually, once the map is in place, I'll add enemies and weapons, but that's getting ahead of myself. What do you think of the XY two-dimensional coordinate system? Would be simple to move, simply increase or decrease the x and y values to move your character, then display the area info.
I was thinking instead of having one enormous map, break it into chunks, such as 10x10 arrays, and ONLY once the user has entered a area that leads into another chunk, delete the old chunk, load the new chunk into memory. This way it's easy to add more to the map and saves on memory. Again.. this all sounds gravy in theory, but I'm not sure if this is able to be implemented.
Last edited on
closed account (D80DSL3A)
I have done one game in which I wanted to have an effectively unlimited map space with each area being unique. I wanted to be able to fly missions over all of Los Angeles county and use Thomas Guide map page images for my map. This consisted of 379 full page images.
The approach I used was to scale things so that the screen was a bit smaller than a 2x2 area of map pages. I kept a 3x3 array of map images loaded at all times. When moving, the player would always leave a row of 3 behind before moving into the next row of 3. I could load the next 3 images needed into the row of 3 just left behind, then cycle them to the front (perform a cyclic permutation on the cell order). This worked. I had to keep a 2D array of strings for looking up the image file names for loading these images on the fly.
If you simply "delete" an area when leaving then all data for that area would be lost, unless you write the data to a file, in case the player backtracks.
Just some ideas. It's probably a good idea to put lots of thought into this before trying to implement something.
The approach I used was to scale things so that the screen was a bit smaller than a 2x2 area of map pages. I kept a 3x3 array of map images loaded at all times. When moving, the player would always leave a row of 3 behind before moving into the next row of 3. I could load the next 3 images needed into the row of 3 just left behind, then cycle them to the front (perform a cyclic permutation on the cell order). This worked. I had to keep a 2D array of strings for looking up the image file names for loading these images on the fly.
If you simply "delete" an area when leaving then all data for that area would be lost, unless you write the data to a file, in case the player backtracks.
Just some ideas. It's probably a good idea to put lots of thought into this before trying to implement something.
That was actually what I was going to do. Just have it all saved in text files, so it's not hardcoded and don't have to recompile everytime I change some trivial strings such as descriptions. What you did sounds exactly what I am looking to do! I have no idea what cyclic permutation is though lol.
Topic archived. No new replies allowed.