Level Design

It really depends on your project.

Is your game 2D or 3D? If 2D, is it tile-based or plain pictures with a walk mesh?

It really depends on your project.

Is your game 2D or 3D? If 2D, is it tile-based or plain pictures with a walk mesh?

Ahh Sorry for not being specific. I was planning to build a 3D world where a hero can go walking around exploring. I was thinking of using separate models in addition to a heightmap to construct my scene but it doesnt really answer how to make 2nd floors. Imagine walking in a canyon and above you are rock bridges where enemies are waiting to jump and ambush you. How do I make those rock bridges?

Thanks,
Ted

Typically that type of level geometry would be created in a modeling program or a dedicated level editor.

[font=arial, verdana, tahoma, sans-serif][size=2]I'm also working on a simple heightmap based level renderer. For a given level map, its split into rooms (sectors). Each sector has a heightmap for the floor, ceiling, and each wall. Additional geometry can be specified by arbitrary meshes, but for many rooms and corridors the heightmaps suffice. I know many would probably advocate against using heightmaps for this, and would rather specify explicit geometry in a modeling program, but for a one-man project like what I'm working on, its very handy to be able to specify the majority of the geometry using a paint program! Heightmaps are also very easy to do collision detection against, and are very easy to render at different LOD.

There are two ways I could represent your particular case:[/font]

Single room: The bridge is represented by mesh. The mesh is included in the list of objects the player code checks for collisions: If you're above the bridge, you can't fall through it.

Two rooms: The room is split vertically into two rooms. The area above the bridge is one room, but the floor heightmap is incomplete; it contains only the walkable surface of the top of the bridge. Likewise, the bottom room has an incomplete ceiling heightmap, only representing the bottom of the bridge. Other details to the bridge, like railing, etc, is added with just a mesh.

The second option above, splitting into two rooms, is very common. In fact, in many early game engines, a sector had to be concave, so any structure like a bridge had to be split into different sectors. I'm not sure to what extend this is done in modern games; everything uses hardware Z-buffers so it doesn't matter much.

For a first game, I would go with whatever is easier to understand to get the job done.

Hmm, wouldn't that raise an accuracy problem if you tried to match the ceiling of the first room to the floor of the second room?

Ive never done ceiling or wall heightmaps before, just floor heightmaps. I know its pretty ambitious for a first game, in fact, its VERY ambitious. For these kinds of heightmap, I assume that I need to structure them in a cube formation? Do I need 6 seperate heightmaps for the whole cube or would it be entirely possible to take the into from just 1 heightmap?

Hmm, wouldn't that raise an accuracy problem if you tried to match the ceiling of the first room to the floor of the second room?

Ive never done ceiling or wall heightmaps before, just floor heightmaps. I know its pretty ambitious for a first game, in fact, its VERY ambitious. For these kinds of heightmap, I assume that I need to structure them in a cube formation? Do I need 6 seperate heightmaps for the whole cube or would it be entirely possible to take the into from just 1 heightmap?

You can match the floor of one room to the ceiling of another just by keeping track of how big each room is. I use axis aligned bounding boxes. So I know if the ceiling of one room is at 3.0, then to put the floor of the room above it at 3.0. You might want to make it simple, and just have every 'story' of the structure the same height.

You might want to scale it down a bit for your first game. Instead of jumping in with the heightfields, why not try an environment made of rectangular rooms? Start off with using rooms specified by axis-aligned bounding boxes. Just draw a textured quad for each wall or floor. Experiment with linking rooms together. Try a simple portal-based visibility algorithm. Get a working environment. Then try rendering a height field in place of the floor quad. Then try a fancy heightfield ceiling. Put a few mesh objects in there.

You're just doing this project for fun, right?

[quote name='tedted' timestamp='1299547745' post='4783063']
Hmm, wouldn't that raise an accuracy problem if you tried to match the ceiling of the first room to the floor of the second room?

Ive never done ceiling or wall heightmaps before, just floor heightmaps. I know its pretty ambitious for a first game, in fact, its VERY ambitious. For these kinds of heightmap, I assume that I need to structure them in a cube formation? Do I need 6 seperate heightmaps for the whole cube or would it be entirely possible to take the into from just 1 heightmap?

You can match the floor of one room to the ceiling of another just by keeping track of how big each room is. I use axis aligned bounding boxes. So I know if the ceiling of one room is at 3.0, then to put the floor of the room above it at 3.0. You might want to make it simple, and just have every 'story' of the structure the same height.

You might want to scale it down a bit for your first game. Instead of jumping in with the heightfields, why not try an environment made of rectangular rooms? Start off with using rooms specified by axis-aligned bounding boxes. Just draw a textured quad for each wall or floor. Experiment with linking rooms together. Try a simple portal-based visibility algorithm. Get a working environment. Then try rendering a height field in place of the floor quad. Then try a fancy heightfield ceiling. Put a few mesh objects in there.

You're just doing this project for fun, right?
[/quote]

Yes I'm doing this project for fun, though, I hope to be a professional someday and I dream of making games that everyone loves to play. When you say rectangular rooms, its a giant rectangle textured on the inside, right? And by axis-aligned, it is rendered along the basic axis instead of rotated or translated in any direction, right? Please pardon the noobness, I'm still trying to find my way around game development. I imagine this type of approach would suit designing interiors of fortresses but would it be entirely possible to use this approach to design outdoor terrain?

Thanks and Regards,
Ted

For simplicity, I'm using rectangular axis-aligned rooms, but they don't have to be that way. The room could be any arbitrary polyhedron. I'm sort of new to game programming as well; I've used OpenGL for a few years to render simple models and environments, and at my day job I'm a software engineer, but this is my first time applying my graphics and programming knowledge towards making a finished 3D game. Writing a game is a bit more complex then just writing a simple renderer!

Yes, you are right, this works well only for INDOOR environments. For outdoor environments, you need something else. Once upon a time I would have suggested ROAM, but the way graphics cards work today, the amount of dynamic data that generates isn't a good idea. Look up chunked LOD or geomipmapping.

For simplicity, I'm using rectangular axis-aligned rooms, but they don't have to be that way. The room could be any arbitrary polyhedron. I'm sort of new to game programming as well; I've used OpenGL for a few years to render simple models and environments, and at my day job I'm a software engineer, but this is my first time applying my graphics and programming knowledge towards making a finished 3D game. Writing a game is a bit more complex then just writing a simple renderer!

Yes, you are right, this works well only for INDOOR environments. For outdoor environments, you need something else. Once upon a time I would have suggested ROAM, but the way graphics cards work today, the amount of dynamic data that generates isn't a good idea. Look up chunked LOD or geomipmapping.

I see. I was thinking using this same technique in making outdoor terrain. Using a volumetric approach if you will. But it looks like that will take a lot of power from the CPU and the graphics card. I was hoping there could be a single and simple method which can be used to render these things. I am a Business programmer, I still haven't taken the exam to be a software engineer, I was going to but I decided not too because its too expensive for me being halfway across the world. This is way more fun than business programming though.

I looked into LOD. Am I right in my understanding that LOD isn't an approach of how to render terrain but rather a technique on improving performance?