7
\$\begingroup\$

I've created plenty of 2D games and now that I've gotten my hands dirty working with 3D in opengl I want to start a game. The issue is I don't know how I can store all the map data. Not only the terrain but the textures and objects in the world, lighting, what's intractable etc. it seems that it'll get way to big if I don't have an efficient system for storing and loading maps. So what methods or articles can you guys suggest on this?

\$\endgroup\$
1
  • 3
    \$\begingroup\$ Way too many answers for that =) Start by taking a look at existing 3D engines, thousands of open sourced ones, and research what they're doing with terrain. \$\endgroup\$ Commented Jan 18, 2012 at 2:05

2 Answers 2

5
\$\begingroup\$

Firstly look up basic spacial geometry formats like Octrees and BSPs.

As for your actual map level format, chances are you will want something very customized to your game. Are you using 1 giant mesh for your game world (Like a FPS), a bunch of modular meshes something like an indoor Skyrim area or for the outdoor areas they would also probably have a heightmap (Stored as a texture? maybe a bunch of floats? Maybe inputs for a procedurally generated algorithm). Do you want a massive open gameworld like GTA/Just Cause or a bunch of small detailed areas? Do you need to embed lighting maps or is that done on the fly? Custom meshes/objects or all build from components?

You might actually want to start with something like XML or ASCII and just convert it into something binary at a later point once you have your details hammered out. You might find the XML gives you good enough performance anyway.

idGames actually use plain ASCII for their stuff and in doom3 at least it compiles most of the stuff on load since lighting now doesn't need to be prebaked as it's done on the hardware. It's split over a few different files but I think they are all ASCII (even the 'compiled' stuff). So you don't really need any superefficant packing methods.

You can look at using formats that are outputted from 3D modelling software like 3D Max, Maya, Blender and so on. That way you don't have to make a level editor. But you will have to find a way to embed game information in your 3D scenes.

COLLADA is a very general purpose 3D XML format. But it might be a bit too general and feature rich and requires some parsing and cleaning up. You will also have to fidn a way to gameify it (Maybe 1 file for overall level layout while keeping your mesh stuff in another file or even different format).

Some other random advise would be to give every object a unique id (at least the non-static ones), that way you can easily save/load just the changed data. It would probably also help with network replication for multiplayer.

Other advice would be to split up everything. Don't try and embed textures in your level format. If you do want to pack everything together for redistribution just zip it.

\$\endgroup\$
1
\$\begingroup\$

I think looking up BSP's etc is too complicated for a first game.

In a 2D game you basically store everything as an image and access it when you want. spritesheets, tiled maps etc.

In a very basic 3D game, the geometry is more complicated than just one image and is usually embedded in a file just like any other peice of code. You have vertex data describing walls etc.

Just create a level class that is a container for a number of walls and the floor etc, each of which is a class that calls in the right textures.

\$\endgroup\$

You must log in to answer this question.