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
There is often a great deal of common information concerning types of objects. Artwork, basic statistics, etc. To avoid duplication, and to simplify editing, these are separated into a database.
A Type Database is conceptually static data associated with a model sub-class. However, the type database is rarely implemented this way; instead, it is often an independent relational database indexed by "type number" and referenced by such in a model instance.
Not available at this time.
Examples of fields which might exist in a type record:
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.)
Type lookup may be done directly to the a type database. For example, a view object might reference getType (typeBeingSorted)->getSize() to find an extent in a sort loop.
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 size = getType()->size;
if (shieldsUp) size *= 2;
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.
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.
Issues and Risks
None at this time.
Type Database is read-only by Model, View, and Controller.
Type Database may store global data for Appearance Map.
Type Database may act as a Factory for Model or Controller objects.