Home

Going beyond fixed behavior.

Introduction

This article is about the general concept of an Entity-Component system, and how it applies inside Racer.

The idea behind it came into existence when it became apparent that for some elements of game design, Object Oriented Programming (OOP) is quite static in a long-term perspective. Meaning that class hierarchies (code/logic) have the tendency to become more rigid as time goes by. With components, you get the flexibility to chop logic up into smaller parts, and be able to re-use those parts on different types (called archetypes) in a mix & match type of scenario. If this all sounds very abstract, that's because it is; it can take a while to get into the flow, but the travel is worth it. Most game engines these days are built onto some kind of component system, instead of so-called Deep Hierarchies.

Refactoring is one of the main concepts in programming, which means restructuring large parts of the code into a better, perhaps more abstract, design. Component-Entity systems can help to reduce the work involved when trying out new things.

Components

The entities consist of one or more components. Each component represent an aspect, or capability, of your entity. Behaviors are then specified that work on one or more component.

You can find a list of basic components here; these are components that are pre-built into the C++ game engine.

Background information (useful to read)

• Building Object Systems - by Alex Duran, on the object system in Thief 3 and Deus Ex 2. It seems to be hard to get these days; I don't have the PPT itself.
• Entity Systems Are The Future of MMOG Development, part 1 - goes far into code & data separation, and storing entity (or rather component) data in SQL databases
• Jeff Plummer's thesis on Game Engine Architecture.

(last updated November 13, 2012 )