• Create Account

Banner advertising on our site currently available from just \$5!

Like
0Likes
Dislike

# Type Database

By Zachary Booth Simpson | Published Jun 19 2001 05:34 PM in General Programming

type database model size common controller appearance objects see
 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

© 2000 - Zachary Booth Simpson. Copied with permission from http://www.mine-control.com/zack. If you find any of this work useful, please sign Zack's guest book: http://www.mine-cont...i/gbook-zbs.cgi.

Intent

Store information which is common to Model types.

Problem

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.

Solution

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.

Structure

Not available at this time.

Examples

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 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.

Issues and Risks

None at this time.

Related Patterns

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.