This project is read-only.

Understanding Components

For the sake of brevity, we will assume that those reading this documentation are already vaguely familiar with game engines and game engine design, or at least the principles of object-oriented programming that guide their construction. One of the primary tenets of object-oriented design is the concept of inheritance.

Inheritance is a feature that allows classes to derive their attributes and mechanics from another class. This will be familiar to anyone with experience in an OOP language and is best exemplified by the ubiquitous Shape-Circle-Sphere scenario [related]. Inheritance in game development poses several issues, however. [If you are interested in a full history of component-object software and game design, check out the infamous Evolve Your Hierarchy article.] 

  1. Game object hierarchies tend to be very deep meaning a single change to a class at the top of the hierarchy can have a profound impact on the behavior of the rest.
  2. Game object hierarchies make testing difficult and refactoring a chore. Any change made to a class in the hierarchy necessitates a recompile. 
  3. Game object hierarchies are largely esoteric. Game engines based on deeply rooted class hierarchies rarely find applications outside of the particular title or series they were created for. 

The Component-Object Design (also, Component-Aggregate Objects or Component-Entity System, etc) method frees us from these restrictions. With component-based game objects we create a robust framework that facilitates the use of compact, encapsulated classes which we refer to as "components." The framework is largely ignorant to the purpose of any given component and exists only to "wire" the components together to form our game objects. Consider the process for creating a new game objectLongbow. We already have a base class, Weapon, that describes all the various attributes that a weapon might have: damage, swing speed, damage type, etc. We then set about writing code with the sole purpose of filling in the gaps between what a "weapon" is and what a "longbow" is and in the process we invariably deepen our class hierarchy. 

This is one of the biggest problems with game object hierarchies: you spend the majority of your time defining all of the ways in which your new object is not like the object it is derived from instead of defining what the object is. 

Last edited Feb 8, 2012 at 8:07 PM by heliondevelopment, version 1


No comments yet.