Traditionally, game objects were created and extended using class inheritance. For example: A class GameObject serves as the base class for all game objects. A class Moveable is derived from GameObject and represents all game objects that can move. The class Enemy derives from Moveable. EnemyTank and EnemySoldier derive from Enemy. And so on. Inheritance-based game object structures can be used for simple games but quickly get unwieldy for non-trivial games with complex inheritance trees or multiple inheritance.

Component-based game object systems have been developed to fight the inherent problems of inheritance-based game object systems. A component-based game object is generic container of components, e.g. a PhysicsComponent, a GraphicsComponent, etc. Game objects communicate using message-passing.

The game object system in the DigitalRune Game library was designed to support both, inheritance-based and component-based systems. The component-based approach is usually used in 2D and 3D games to manage scene objects (players, enemies, level objects, etc.). The inheritance-based approach is, for example, used by the GUI controls in the DigitalRune Game UI library.

To compare with other literature and designs:

• Game objects systems are also called game entity systems.
• Game objects are also called game entities, controllers, or actors.
• Game object properties/events are also called ports, signals, or attributes.
• Templates are also called prefabs, prototypes, or archetypes.

The DigitalRune game objects system was built to support the following features:

• Support for inheritance-based and component-based game object structures.
• Properties can be added to or removed from a game object at runtime.
• Properties of a game object can be enumerated.
• Properties can be accessed via C# properties, via handle (integer ID) or via name (string).
• Properties can have default values and metadata (such as ID, name, description, category).
• Properties can be animated.
• Properties have Changed events.
• Properties have a coercion mechanism for value changes.
• Game objects can act as a template for other game objects.
• Memory efficiency
  • Properties do only use memory if the values differ from the default values.
  • Game objects that are built from a template do only store the minimum amount of data and do not duplicate the data of the template in memory.
• Game objects are scriptable.
• Game objects are configurable in XML or graphical editors (adding properties, setting property values and connecting properties of game objects with properties of other game objects).