If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource
Most games need to track the state of many models simultaneously. Collecting the models into one list simplifies several important systems.
The creation and maintenance of indices which speed searching. (See Spatial Index.)
The inter-object references and the "death problem". (See Controller.)
Serialization, i.e. load and save.
Some games may have more than one kind of Model Database simultaneously because of fundamental differences in data or index type. For example, a game might have a TerrainModelDatabase which is independent of the MobileModelDatabase. These are both Model Databases, but have radically different optimization needs.
Some games may implement the Model Database as a simple array of Model instance pointers. This is probably the simplest solution and often very practical.
Other games may choose to implement sophisticated memory management or caching solutions to optimize or solve any of the following problems:
World is too large to fit in memory.
World fits in memory but too many objects slows down AI, physics, rendering, etc.
Synchronization of client and server.
Improve speed of load / save by "linearizing" world state.
The world database is almost always indexed to increase search speeds. (See Spatial Index.) The synchronization of these indices is usually part of the Model Database''s responsibility in methods like: removeFromWorld() and insertIntoWorld(). (See Gateway.)
Most games use hierarchical Model Databases over relational ones. In general, hierarchical databases are faster, but more cumbersome to change schema. Relational are slower but robust to schema changes. Since games almost always prefer speed to maintainability, they are thus typically hierarchical.