[size="5"]Intent
[bquote]Store information which is common to Model types.[/bquote]
[size="5"]Problem
[bquote]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.[/bquote]
[size="5"]Solution
[bquote]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.[/bquote]
[size="5"]Structure
[bquote]Not available at this time.[/bquote]
[size="5"]Examples
[bquote]Examples of fields which might exist in a type record: 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:
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]
[size="5"] Issues and Risks- 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()
{
int size = getType()->size;
if (shieldsUp) size *= 2;
return size;
}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.[/bquote]
[bquote]None at this time.[/bquote]
[size="5"]Related Patterns
[bquote]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.[/bquote]
Type Database may store global data for Appearance Map.
Type Database may act as a Factory for Model or Controller objects.[/bquote]
