2
\$\begingroup\$

To give you a bit of context, I often try and imagine how big games are working, especially networked and multiplayer games. This is how I came to this question: how do big 3D multiplayer games load their 3D, predefined maps? (I am not talking of generated ones, such as in Minecraft, but defined maps that represent, for example, a kitchen).

The most viable hypothesis to me are:

  • Some basic map terrain is loaded in a .obj file (with just variations of height and of ground material), and then more data (like trees) is added according to another file, stored in a format like xml, which also contains paths to other obj files. This techniques therefore allows modifications of terrain, as well as something like serialization to send data to a new client joining (but it's really heavyweight and hard to implement). Finally, you can base player position on which tile they are, and make easier collision & al (for RTSs for example).

  • A map containing all data in a single .obj file is loaded by all clients, and they are just allowed to move inside it (is this the case in FPSs like Quake?)

But I think both of these techniques aren't optimized enough for commercial or public use. Do you have any idea of how can these games load their map data?

\$\endgroup\$
3
  • \$\begingroup\$ They don't use .obj which is a horrible format; they use their own custom, and typically binary, formats instead. \$\endgroup\$ Commented Mar 19, 2017 at 7:30
  • \$\begingroup\$ All of the older ID Software engines are open source: github.com/id-Software - opinion-based questions are inappropriate for this site. \$\endgroup\$ Commented Mar 19, 2017 at 11:50
  • \$\begingroup\$ Thanks for the link :) Sorry for the second question, I'll remove it :/ \$\endgroup\$
    – cocosushi
    Commented Mar 19, 2017 at 12:00

1 Answer 1

1
\$\begingroup\$

Generally, large maps are stored, loaded and rendered in pieces. This way, only the parts of the world immediately surrounding the player or players needs to be fully loaded and simulated, and the game doesn't waste time or resources on map data that cannot be seen.

If appropriate for the game, level-of-detail techniques can be used -- so, for example a very low-resolution version of a map piece can be loaded up for when that terrain is visible from a large distance (if the player is on top of a mountain, for example). That low-resolution chunk will eventually be replaced by streaming in a high-resolution chunk as the player moves closer to it.

These techniques can be applied to game simulations that occur in these map pieces as well. For example, AI for characters far away may not run as often or may fall back to doing "low resolution" AI processing.

The .obj format is very simple, and works well for small games or for developers getting started with model formats. Its simplicity gives it a number of disadvantages in both performance, size, and functionality, however. In practice many games will use a proprietary format for mesh data that more-directly mirror the game's actual runtime requirements for format. This may involve using a different format for terrain meshes than for character meshes as well.

.obj may work fine as in interchange format for getting data out of a modelling program, but it's often desirable to convert (offline) the .obj data to something more bespoke before using it at runtime.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .