Hello I'm a web developer and recently I started reading about game development. I followed some tutorials regarding c++ and openGL (whatever I could find online because as you know not many up to date openGL tutorials exist.)

I keep wondering in a case of a rpg game with a huge real world(map) and entities(enemies what so ever) how could it be implemented. Meaning you cant load a huge map and the entities all at once obviously... I was thinking of subdividing the map into blocks and each block to even smaller ones so that each block contains (5x5) 25 sub-blocks.

A map could be consisted of many blocks such as the following one which has 25 sub-blocks:

P = Players current sub-block O = sarounding sub-blocks X = sub-blocks not yet loaded

Entities will be loaded only for the players current sub-block. Keep in mind that P is not just the player is a mesh a piece of map not very big and not as small as the player is.

X X X X X
X O O O X
X O P O X
X O O O X
X X X X X


And I'm wondering is this a good approach? I suppose each sub-block has to be a different mesh apparently and then stitch them up together?

CASE 2:

What if I stored the map into 1 big height map or a set of height maps and generate the mesh from that. According to the player's position copy the required image height and width where player is always at the center of it and rearrange the data in the vbo?

I'm sorry if this is a silly question but I simply don't now how to approach this and I can't find any references.Also keep in mind that on such a map animations will also happen.

I would really appreciate it if someone could give some references or explain the architecture for a game such as this.

• Are you looking to generate the world procedurally? Do you want an infinite world?
– user24821
Jan 21, 2013 at 12:35
• Yes an infinite world that will be consisted of smaller chunks Jan 21, 2013 at 16:07

Scott Bilas of Gas Powered Games wrote a good document about how they implemented a continuous world in dungeon siege.

Paper: The Continuous World of Dungeon Siege

Slides: The Continuous World of Dungeon Siege

• This is an excellent paper. If use Minecraft-like chunks (square and uniform), the math gets a lot easier, by the way. It also helps if you partition your coordinates into a grid with the size of a chunk. I have created a structure called WorldPosition which more or less automagically converts to display coordinates and can interoperate with Vector3: github.com/htmlcoderexe/3DGame/blob/Entity/Player/3DGame/… You can find a terrain implementation there, too, with a loader/worldgen. Contains some fossil code but should give you the general idea. Needs comments. Dec 5, 2017 at 22:36

Minecraft is a 3D game with a game world that is extremely large in size (practically infinite). Instead of 3D terrain derived from meshes, the terrain is represented by 3D Cubes. The world is procedurally generated and stored in small chunks, similar to what you described in your first potential solution.

While playing Minecraft, chunks near the player are rendered and updated (including any entities in these chunks), while chunks farther away from the player are saved to the disk and not in memory. While the player travels through the world, saved chunks near the player are loaded into memory from the disk and loaded chunks far from the player are saved to the disk and no longer used. When the player quits the game, all loaded chunks are saved to the disk.

Since individual chunks are relatively small, groups of them are saved to the disk as a single file, labeled "regions". In earlier versions of Minecraft, chunks were saved to the disk as individual files, which were loaded about seven times slower than the region files.

The technical section on the Minecraft wiki has some more information regarding Minecraft's chunks and regions.