- Prototype state; e.g. max hit points, strength, range, cost, etc.
- Size, extents, initial orientations.
- Type categorization. (e.g. offense, defense, mobile, fixed, human, alien, etc.)
- Execution scripts. (See Usecode.)
- Artwork; e.g. meshes, texture-map, sprites. (These are frequently stored by reference to yet another database.)
- Sound effect handles or references.
- Appearance maps. (See Appearance Map.)
Alternately, type lookups may be delegated to an object. For example: modelBeingSorted->getSize(). The delegated method allows a sub-class to override in strange cases. For example:
int Spaceship::getSize()Type databases often contain tweaky constants which are adjusted for game play reasons near the end of a project. Also, these constants may be editable by the players or mission builders. Consequently, type data is often loaded dynamically from text files or similar human readable input.
int size = getType()->size;
if (shieldsUp) size *= 2;
Art importation is often closely associated with the type importation. It is common to see a compile-time tool(s) which handles both.
A type database is usually read-only after game initialization, but may be read-write in editor mode.
Type Databases occasionally implement Factories (See Design Patterns) to generate specific Model or Controller objects on demand by either type number or type name. This is especially common in edit modes.[/bquote]
Type Database may store global data for Appearance Map.
Type Database may act as a Factory for Model or Controller objects.[/bquote]