Component based game engine design [closed]

Question

I have been looking at game engine design (specifically focused on 2d game engines, but also applicable to 3d games), and am interested in some information on how to go about it. I have heard that many engines are moving to a component based design nowadays rather than the traditional deep-object hierarchy.

Do you know of any good links with information on how these sorts of designs are often implemented? I have seen evolve your hierarchy, but I can't really find many more with detailed information (most of them just seem to say "use components rather than a hierarchy" but I have found that it takes a bit of effort to switch my thinking between the two models).

Any good links or information on this would be appreciated, and even books, although links and detailed answers here would be preferred.

Accelerant

Answer 1

Update 2013-01-07: If you want to see a good mix of component-based game engine with the (in my opinion) superior approach of reactive programming take a look at the V-Play engine. It very well integrates QTs QML property binding functionality.

We did some research on CBSE in games at our university and I collected some material over the years:

CBSE in games literature:

• Game Engine Architecture
• Game Programming Gems 4: A System for Managin Game Entities Game
• Game Programming Gems 5: Component Based Object Management
• Game Programming Gems 5: A Generic Component Library
• Game Programming Gems 6: Game Object Component System
• Object-Oriented Game Development
• Architektur des Kerns einer Game-Engine und Implementierung mit Java (german)

A very good and clean example of a component-based game-engine in C# is the Elephant game framework.

If you really want to know what components are read: Component-based Software Engineering! They define a component as:

A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.

A component model defines specific interaction and composition standards. A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model.

A software component infrastructure is a set of interacting software components designed to ensure that a software system or subsystem constructed using those components and interfaces will satisfy clearly defined performance specifications.

My opinions after 2 years of experience with CBSE in games thought are that object-oriented programming is simply a dead-end. Remember my warning as you watch your components become smaller and smaller, and more like functions packed in components with a lot of useless overhead. Use functional-reactive programming instead. Also take a look at my fresh blog post (which lead me to this question while writing it :)) about Why I switched from component-based game engine architecture to FRP.

CBSE in games papers:

• Component Based Game Development – A Solution to Escalating Costs and Expanding Deadlines?
• A Flexible And Expandable Architecture For Computer Games (404)
• A Software Architecture for Games
• A Generic Framework For Game Development (WebArchive)
• Smart Composition Of Game Objects Using Dependency Injection

CBSE in games web-links (sorted by relevancy):

• Component based objects Wiki (Empty wiki)
• Evolve Your Hierachy
• Game Object Structure: Inheritance vs. Aggregation
• A Data-Driven Game Object System (PDF)
• A Data-Driven Game Object System (PPT)
• Component-based prototyping tool for flash
• Theory and Practice of Game Object Component Architecture (404)
• Entity Systems are the Future of MMOs
• ogre3d.org forum: Component Based Objects
• gamedev.net: Outboard component-based entity system architecture
• gamedev.net: Entity System question
• Brainfold entity-system blog (WebArchive)

Pretension

I have a hard time finding resources on FRP in relation to game engines. Can you provide some code or links? – Certainty

FRP is a small field in general, and especially in gaming. Been around for years, but still fairly bleeding edge. If you search Functional Reactive Programming in relation to the Haskell language, you'll find most of the research on it. Key projects are Fruit, Fran, and Yampa. Yampa Arcade is a paper describing use of the Yampa reactive library for gaming. I've not heard of any actual implementations though, beyond maybe some Silverlight stuff using the new .NET reactives. – August

This is a great answer, thank you for introducing me to FRP. However I would have said to newcomers, "Switch to functional programming or prototype-based programming.". Then I would have said, "And as an added bonus, use FRP if you choose FP." – Coley

"A very good and clean example of a component-based game-engine in C# is the Elephant game framework." It was never finished and it doesn't tackle any real-world issues like inter component/entity communication. – Prosperus

I'm the author of the Elephant-thingie, and, before anyone decides to use that old thing, I would like to point out that I have released an alternative called ComponentKit. Though it doesn't provide anything game related, it's at least a useful reference on how such a system can be implemented. – Brentwood

@JacobH.Hansen Funny, I looked at this post the other day, and came back today to go through some more links, and I see a new post! I'm going to take a look at your ComponentKit. How do you handle communication? Just with delegates? – Lyell

Good roundup of information and links, thanks! I have previously spent a lot of reading t-machine.org/index.php/2007/09/03/… (which you link above) and found it to be very helpful. – Melaniamelanic

Answer 2

There does seem to be a lack of information on the subject. I recently implemented this system, and I found a really good GDC Powerpoint that explained the details that are often left behind quite well. That document is here: Theory and Practice of Game Object Component Architecture

In addition to that Powerpoint, there are some good resources and various blogs. PurplePwny has a good discussion and links to some other resources. Ugly Baby Studios has a bit of a discussion around the idea of how components interact with each other. Good luck!

Denisse

+1 for that first powerpoint, very thought-provoking! – Crosscrosslet

@Noah: GDC ppt link is broken, do you have the ppt in stock anywhere else? :-) – Electrophone

Not at the moment, but when I get off work I'll dig and see if I placed a backup copy anywhere. – Denisse

Heh, downloaded the ppt (link worked), then realized I attended the talk 5 years ago, thanks for the reminder. In general, be careful of putting too much behaviour in your components, that way lies spaghetti code and eventual madness. Favour "dumb" components that hold data, and put your behaviour into entity processors. – Melaniamelanic

Answer 3

While not a complete tutorial on the subject of game engine design, I have found that this page has some good detail and examples on use of the component architecture for games.

Accelerant

Answer 4

It is open-source, and available at http://codeplex.com/elephant

Some one’s made a working example of the gpg6-code, you can find it here: http://www.unseen-academy.de/componentSystem.html

or here: http://www.mcshaffry.com/GameCode/thread.php?threadid=732

regards

Puttyroot

the first link has been moved to here: unseen-academy.de/snippet_component_system.html, apparently. – Calf

Answer 5

I am currently researching this exact topic in the many (MANY) threads at GameDev.net and found the following two solutions to be good candidates on what I will develop for my game:

• Critique my component-based entity system
• Outboard component-based entity system architecture -> Lord_Evil's proposal

Spoil

Answer 6

I researched and implemented this last semester for a game development course. Hopefully this sample code can point you in the right direction of how you might approach this.

class Entity {
public:
    Entity(const unsigned int id, const std::string& enttype);
    ~Entity();

    //Component Interface
    const Component* GetComponent(const std::string& family) const;
    void SetComponent(Component* newComp);
    void RemoveComponent(const std::string& family);
    void ClearComponents();

    //Property Interface
    bool HasProperty(const std::string& propName) const;
    template<class T> T& GetPropertyDataPtr(const std::string& propName);
    template<class T> const T& GetPropertyDataPtr(const std::string& propName) const;

    //Entity Interface
    const unsigned int GetID() const;
    void Update(float dt);

private:
    void RemoveProperty(const std::string& propName);
    void ClearProperties();
    template<class T> void AddProperty(const std::string& propName);
    template<class T> Property<T>* GetProperty(const std::string& propName);
    template<class T> const Property<T>* GetProperty(const std::string& propName) const;

    unsigned int m_Id;
    std::map<const string, IProperty*> m_Properties;
    std::map<const string, Component*> m_Components;
};

Components specify behavior and operate on properties. Properties are shared between all components by a reference and get updates for free. This means no large overhead for message passing. If there's any questions I'll try to answer as best I can.

Ice

So you use properties for components to talk each other? Doesn't this approach break encapsulation? Basically you are using properties as a bunch of global variables. – Microgroove

In addition to happy_emi's comments, you have just traded the "large overhead for message passing", by which I assume you mean string lookups and bad cache coherency, for a large overhead associated with properties. The component half of your implementation looks fine, but the property half makes no sense - either make those real fields on your Entity which components can set, or keep inter-component references. – Crassus

The properties are only looked up on creation of components and stored as a pointer. There is a one time cost to grab the "shared" data on the entity. The data is "global" only in the sense that all components have access to whatever data on their entity that they would like. I'm not talking about purely string lookups, but also the extra code that gets called. Remember that you could have a massive number of entities in your game. Passing a message for every entity to update their position every game loop is a lot of useless overhead when you can just have a component set the data. – Ice

Maybe an example will help. Say your entity has a Pathing component and a Rendering component, both need Vec3 location. Order is arbitrary, but let's say that the Render component is created first. Render asks the entity for the Vec3 location property, which is created on the entity, and the pointer is given to Render. Now Pathing gets created, it asks for the same Vec3 location, and the entity returns the pointer of the property (actually the raw data inside the property) it just created. At this point, when Pathing updates location, Render can draw without asking for new location data. – Ice

Answer 7

In this context components to me sound like isolated runtime portions of an engine that may execute concurrently with other components. If this is the motivation then you might want to look at the actor model and systems that make use of it.

Smothers

Answer 8

Interesting artcle...

I've had a quick hunt around on google and found nothing, but you might want to check some of the comments - plenty of people seem to have had a go at implementing a simple component demo, you might want to take a look at some of theirs for inspiration:

http://www.unseen-academy.de/componentSystem.html
http://www.mcshaffry.com/GameCode/thread.php?threadid=732
http://www.codeplex.com/Wikipage?ProjectName=elephant

Also, the comments themselves seem to have a fairly in-depth discussion on how you might code up such a system.

Barograph