Component entity systems
|Home||Going beyond fixed behavior.|
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.
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)
(last updated November 13, 2012 )