Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

This is a conglomeration question when answering please specify which part you are addressing. I am looking at creating a maze type game that utilizes elevation. I have a few features I would like to have, but am unsure as to some of the implementation.

I have done work doing fileIO maze generation (using a key to read the file, and then generate the level based on that file), but I am unsure how to think about this with elevation in the mix. I think height maps might be a good approach, but don't know how to represent them effectively. for a height map which is more beneficial XML(containing h[u,v] data and key definition), CSV (item1 is key reference, item2 is elevation), or another approach that I have not thought of yet?

When it comes to placing the elevation values themselves what kind of deltah values are appropriate to have it noticeable at about a 60degree angle while not really effecting gravity driven physics (assuming some effect while moving up/down hill)?

I am thinking of maybe going to procedural generation at some point, but am wondering if it is practical to have a procedurally generated grid (wall squares possibly same dimensions as the open space squares), or if designing to a thin wall open spaces is better? this decision will effect the amount of work need on the graphics end for uniform vs. irregular walls.

EDIT: Game will be a elevation maze shooter. Levels/maps will be mazes with elevation the player has to negotiate. Elevations will have effects on "combat" vision, and movement.

share|improve this question
    
Use an image file for the heightmap? –  Pubby Mar 21 '12 at 18:01
    
I think you need to read your question, then try re-writing it. –  Byte56 Mar 21 '12 at 18:02
    
I am a bit of confused as to what kind of level/map you want, exactly. It would help if you specified desired output clearly and separately from the rest of the post. –  Superbest Mar 21 '12 at 18:06
    
@byte56 is there any section specifically that you are having trouble understanding –  gardian06 Mar 21 '12 at 18:16
5  
Well, it's just my opinion, but I think this is a poor question. You're asking a lot of questions, and they are pretty vague questions. –  Byte56 Mar 21 '12 at 18:31
show 1 more comment

1 Answer

up vote 1 down vote accepted

I am thinking of maybe going to procedural generation at some point, but am wondering if it is practical to have a procedurally generated grid (wall squares possibly same dimensions as the open space squares), or if designing to a thin wall open spaces is better?

Depending on how you go about things, I'd say it doesn't matter - either is good. Nethack and many roguelikes are a great example of how "fat walls" look when generating mazes/dungeons at a single height. I think it might possibly make your job easier, since all you need to store the level data is one array (as opposed to essentially two different arrays with thin walls: One for "inside-grid-cells" and one for "between-grid-cells") although Nethack is only one height.

I think you should start with whichever one is less work (probably fat walls), because honestly to a gamer what matters more is that the games logic is consistent and well-implemented rather than realistic; so it doesn't matter that fat-walls seem weird so long as they work and are bug-free.

I think height maps might be a good approach

They aren't. If your maze is a bunch of rectangular (or polygonal) prismatic rooms connected by hallways, a heightmap is quite unsuitable. This is because you give up some huge things: Rooms cannot ever be above each other for instance, because for every z-level there is only one value. The heightmap, in other words, is a function, which can have only one output for a given input, this is quite an illogical constraint (why should it be the case?).

I say this especially because if you accept that assumption, your question becomes trivial. Just generate a 2D flat map as usual, generate (randomly?) a height for each room, flood fill, paint gradients in connecting hallways, done. Then, yes, perhaps a "heightmap" is appropriate as you say.

An alternative way of representing is to simply keep a list of tiles which have walls. The coordinates are 3D, because you'd need a 3D grid for storing a 3D level.

share|improve this answer
    
on your statement of holding the list of tiles. wouldn't it be more advantageous to hold a list of walls, and floors then the adjacent tiles there of, and wouldn't that also allow for holding blocks of different dimensions. though slopes might still be interesting –  gardian06 Mar 21 '12 at 19:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.