# Are there existing FOSS component-based frameworks? [closed]

The component based game programming paradigm is becoming much more popular. I was wondering, are there any projects out there that offer a reusable component framework? In any language, I guess I don't care about that. It's not for my own project, I'm just curious.

Specifically I mean are there projects that include a base Entity class, a base Component class, and maybe some standard components? It would then be much easier starting a game if you didn't want to reinvent the wheel, or maybe you want a GraphicsComponent that does sprites with Direct3D, but you figure it's already been done a dozen times.

A quick Googling turns up Rusher. Has anyone heard of this / does anyone use it? If there are no popular ones, then why not? Is it too difficult to make something like this reusable, and they need heavy customization? In my own implementation I found a lot of boilerplate that could be shoved into a framework.

• You should be the first to write one! :) – Ricket Oct 27 '10 at 22:07
• Well, I wrote one in C# for my own project. Maybe we could all contribute? – Tesserex Oct 28 '10 at 4:34
• I would totally be up for working on that C# project. Yeah, there isn't a huge consensus on how a standard one should work, but maybe we could focus on XNA (whatever floats your boat). Just because a bunch of giants haven't declared the best way to do it doesn't mean we can't try/experiment. – Michael Coleman Jan 15 '11 at 18:58
• Maybe because component based design attracts project managers more than programmers – M. Utku ALTINKAYA Oct 17 '12 at 19:34

If there are no popular ones, then why not?

Because there is nothing resembling a consensus on how such a framework would operate.

On a thread on Gamedev.net I determined that when people talk about component-based game systems there are actually at least 8 possible permutations of how they expect them to work, based on 3 different factors:

Inboard vs. outboard - should components be aggregated into an entity, or should they be part of a subsystem and only associated by an entity ID?

Static vs. dynamic composition - should entities consist of a known set of components (eg. 1 Physics, 1 Animation, 1 AI, etc) that can communicate in code via well-known interfaces, or can entities have arbitrary quantities of components added to them (with associated strategies for locating other components of interest)

Data on component vs data on entity - Should data be held by the component that primarily operates upon it? Or should data be stored on the entity in a shared space, accessible by all components?

Beyond that there are further questions over how the components should communicate (via the shared data? Via function pointers? Via signals/slots? Or not at all?), how they should update (in a fixed order based on component type? a per-entity order defined at creation time? based on a topological sort of component interdependencies?), etc.

Each of these choices are completely arbitrary, and anything you can do with one system can be done with the other. But the way in which you have to code it is quite different in each case. And people seem to have strong opinions over which way works best for them.

Right now people are still too caught up in the idea that components are somehow a replacement for object orientation (which they're not) and also imagining that they're a massive change from how games were traditionally made (which again, they were not - people have factored out the various subsystems in their entities for ages), so there's a lot of hyperbole and not much agreement. Maybe in a few years things will have settled down and people will settle on one or two fairly standard approaches.

• I appreciate this answer is old, but it's now wrong: there ARE popular frameworks, and there's very little debate left on the topic. When writing games, most of the questions above don't matter: either they have no effect on the design of the code, or one approach is fast and reusable where the others are not. In practice, there are a bunch of popular Frameworks - the wiki linked to in one of the other answers is a good starting point (a bunch of us maintain it to make it easier to find actual shipped games + frameworks) – Adam Jun 1 '13 at 18:58
• @Adam: I'd like a link on the details about the approach that won the darwin evolution match then. when I say details, I don't want to hear about inboard and outboard, I want to hear about hash maps, vectors, allocators, private, public, loops, const... LOW level details. – v.oddou Jul 25 '14 at 2:41
• @v.oddou someone posted a link to the wiki as answer already (see below). You want details? It is full of source code. – Adam Jul 25 '14 at 21:25

There's a wiki that's gathering examples of all these:

http://entity-systems.wikidot.com/

...along with explanations of the differences between the different approaches.

• Ash and Artemis (both on the wiki) have proved popular indeed, both of them in use for commercial game development, along with hobby game dev. – Adam Jun 1 '13 at 18:54

Check these frameworks I found out related to this architecture...

www.burgerengine.com

PushButtonEngine

Arthemis Framework - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

Having a look at Unity Api. You can find a lot of stuff regarding the Component based architecture. (Will update the list as soon as I find somemore...)

Update:

      https://code.google.com/p/spartanframework/


This explains about entity systems in a good way... http://piemaster.net/2011/07/entity-component-primer/

There is Push Button Engine for Flash: http://pushbuttonengine.com/

And there is Panda3D for c++/python: panda3d dot com (sorry I'm only allowed 1 url per post as a n00b)

I'm sure there are tons more out there :)