Does Cafu Engine have everything I need for my idea?

[midix]

Hi all, I'm new here.

I'm a programmer, doing mostly some boring business software stuff. I've always been interested in game development but I do not feel smart enough to do it seriously for business. So I just read game development books, articles and I try to follow the tendencies and try some engines just for fun.

For some years already, I have an idea on my mind but I hesitate to get coding because I foresee the vast amount of work required. At first I thought it would be the best to collect my own engine myself using available libraries like Ogre3D, enet, OpenAL and Bullet physics but then I still need various tools to import files, create maps and game objects etc.

So I tried to find some game engine which is free and does not limit me. There are really just a few free engines and even less engines that provide full source code.

And today I found Cafu. The feature list is pretty impressive - almost everything that any modern game would need, and with various development tools and source code. I guess, Cafu is the best I can get for now.

But still there are some doubts about how my own "game ideas" could be integrated with the Cafu Engine.

Here is my idea of my personal "game".

It is something like SIMS game in a networked sandbox. I intend to have a city with traffic and NPC people wandering around. At first, there will be not much action going on. The game is mostly centered around interaction with NFC and the environment, so there is no need for much action. Just a large collection with various parameters which control how NPCs interact with each other and with my own avatar, when I log on to the server with a 3D client.

So far I guess, Cafu has everything to support my idea (and much more).

But now my implementation ideas:
- the city is simulated on a central game server which runs the simulation, no matter if any client is connected or not (it does renderless simulation if nobody is connected)
- the game state is flushed to a database (most probably I'll go for mysql - I have a good experience with it and I know that even some successful MMORPGs are using SQL databases to store game state. To avoid stalling the game, the state will be saved to the database in a background thread periodically or when the changes in the state reach some certain RAM limit, and also on demand when stopping the server)

- to make game state management, networking and persistence easier, I intend to implement game entities as simple property bags. No behavior at all. The game behavior will be implemented as subsystems where each subsystem subscribes to certain events and also generates certain events. I've heard some people have very positive experience with such architecture and I have some experience with it in browser based PHP/HTML/Javascript games, so I hope it will work fine in a real-time 3D virtual world simulator

- I would like to have a in-game avatar editor, something similar to SIMS, so I could adjust some facial and body features, choose textures and then hit Apply, and then my tweaked mesh parameters get baked into a new avatar mesh, which is stored in a file.

Basically, that's all.

I have two general questions:

- are there any Cafu implementation specific details which could stop me from implementing something the way I need (my pub/sub systems idea and behaviorless game entities)?

- what does Cafu provide for game state storage in SQL databases and editing avatars?

Also a little question about animations: what kind of animations are supported - skeletal or vertex/morph animations or both?

And one confusing thing: Cafu feature list says:

In addition, the integration of a physics engine is planned for one of the next releases.

I have already seen somewhere that Cafu has Bullet Engine integrated, so then why is this text in the feature list?

[Carsten]

Hi midix,
welcome to the Cafu forum!

For some years already, I have an idea on my mind but I hesitate to get coding because I foresee the vast amount of work required.

Well, some say that the coding is the whole fun of it!

- the game state is flushed to a database

Why?
You could also just keep things in RAM. How big do you expect your city to get?

- to make game state management, networking and persistence easier, I intend to implement game entities as simple property bags. No behavior at all. The game behavior will be implemented as subsystems where each subsystem subscribes to certain events and also generates certain events.

Well, I don't quite see what the advantage is over entities that have both state and behavior.
That's how entities are implemented in Cafu, but you could forward all events to and from the scripting system to easily abstract that into a "subsystem", if you really want to.

- I would like to have a in-game avatar editor, something similar to SIMS, so I could adjust some facial and body features, choose textures and then hit Apply, and then my tweaked mesh parameters get baked into a new avatar mesh, which is stored in a file.

That would certainly need some amount of customization, no such functionality is built-in at this time.

- are there any Cafu implementation specific details which could stop me from implementing something the way I need (my pub/sub systems idea and behaviorless game entities)?

Please have a look at Is Cafu right for our game of genre "..."?

- what does Cafu provide for game state storage in SQL databases and editing avatars?

At this time, none. (I also don't quite understand how exactly you want this to work, because during normal online-connected operation, the state is clearly in RAM?)

Also a little question about animations: what kind of animations are supported - skeletal or vertex/morph animations or both?

Skeletal.
See The Model Editor for some related documentation.

And one confusing thing: Cafu feature list says:

In addition, the integration of a physics engine is planned for one of the next releases.

I have already seen somewhere that Cafu has Bullet Engine integrated, so then why is this text in the feature list?

Well, the feature list is not entirely up to date. Thanks for reporting this, I've just fixed it!

[midix]

The main reason why I want to store my game state somewhere is because I want to keep the world state between restarts. It could get a bit tricky to save entities which have both state and behavior, so that's why I wanted to separate the behavior completely out of entities.

I am not good at explaining so I better post a link which inspired me and made me think about behaviorless entities and behavior systems:

http://t-machine.org/index.php/2007/09/ ... nt-part-1/

It is a bit old article, but it is great. I have seen people on various game dev forums to intuitively come to the same concept, and I myself have used something similar in simple web browser games before I found that blog. So I guess, if it seems so intuitively good solution, it should be good

Anyway, I'll give Cafu a try and see how it goes. It has a really good base and toolset. Even if something won't fit my needs, I guess, it will be much easier to adjust it than to build my own engine from scratch. Thank you for your work!

[Carsten]

The main reason why I want to store my game state somewhere is because I want to keep the world state between restarts.

No need for a database, why not simply save it to disk, like the classic "save game" button?
"save game" is not yet implemented in Cafu, but the recently implemented improvements in entity serialization / deserialization should make an implementation reasonably easy.

It could get a bit tricky to save entities which have both state and behavior, so that's why I wanted to separate the behavior completely out of entities.

I don't see the problem: Serialization is about state, behavior is about changing the state, so only state is serialized.

I am not good at explaining so I better post a link which inspired me and made me think about behaviorless entities and behavior systems:

http://t-machine.org/index.php/2007/09/ ... nt-part-1/

Sorry, but I disagree. The authors seems not to understand OOP, code design, compilers or scripting languages. For example, from page 2:

In tradtional OOP, if you have 100 units on a battlefield, and each is represented by an object, then you theoretically have 100 copies of each method that can be invoked on a unit. In practice, most OOP languages use runtime and compiler optimizations to share those methods behind the scenes and avoid wasting memory – although scripting languages for instance often don’t do any sharing, allowing all the methods to be independently changed on each and every instance.

which is just plain wrong, except for the last part after the last comma.

Another example, from page 1:

As the network programmer, discovering that an entity system was going to be the interconnect for all other subsystems was a huge relief: the entity system meant I could implement the complex latency hiding and prediction techniques with minimal interference with the coding of all the rest of the game systems. When you’ve got 20+ programmers on a team, you really don’t want to be placing yourself in a position where you’re going to have to redesign code for all of them just to make it “network friendly”.

Well, if he needs an "entity system" in order to be able to separate his networking implementation from the game logic (which we do since almost from the very start), then, sorry, this guy is not worth listening to.

He describes "entity systems" as the incredibly elegant solution to a number of significant problems, but I've not been able to identify a single one (except possibly details about the PS3, which I know nothing about) that could not be solved, usually better, by what he calls "classic OOP". (That term alone, compared to "entity system", is inadequate.)

Anyway, I'll give Cafu a try and see how it goes. It has a really good base and toolset. Even if something won't fit my needs, I guess, it will be much easier to adjust it than to build my own engine from scratch.

Yes, that's the idea! And the things that are there, are, of course, open to improvement and change.

[midix]

I agree that some of the OOP issues described in the T-Machines article could be solved without using entity system architecture. That article is long and very detailed (and sometimes gets off the track), so it is a bit difficult to immediately see the benefits of entity system. So I found another article, which highlights most important moments and also describes real-life experience with entity system in Tony Hawk series of games:
http://cowboyprogramming.com/2007/01/05 ... -heirachy/

One of the major benefits is that you can create new game characters or objects combining all the needed features and behavior without actually changing your object hierarchy. Entity systems allow to implement changes without coding, so even designers (or modders) could create new unique characters easily. Of course, you could achieve the same with scripting, but that would be a bit tricky - you would need filters or something like that to see if some game object (which extends some root class) is of some certain class and should be acted upon or should be ignored.

Regarding SQL database for storing game state - SQL database is great for gathering statistics and analyzing data. Just a single query, and I get count of all game objects which have, let's say, "reputation > 100". If serializing to files, I would have to load all the serialized data in RAM or create some utility which loads data from those files to analyze all the needed properties. But SQL has some drawbacks, too, e.g. it's not as efficient as binary serialization.

So I guess it's just a matter of choice. It just seems to me that entity systems could help people who tend to drive themselves into a corner with overcomplicated OOP hierarchies, although entity systems themselves also can get tricky if done wrong.

[Carsten]

Hi midix,

So I found another article, which highlights most important moments and also describes real-life experience with entity system in Tony Hawk series of games:
http://cowboyprogramming.com/2007/01/05 ... -heirachy/

Oh. Wow! This text is indeed much better than the first (and conceptually somewhat different from it), thank you very much for posting it!

The author clearly describes the problem, and I see and agree that our current entity design in Cafu is the one that he explains in "Traditional Deep Hierarchies". I would love to claim that we however are not affected by the related problems, but indeed, one can imagine that we sooner or later run into the same issues as well (if I tried, I might even list a few minor ones right now).

Thus, I'm generally open to the proposed solution, a "plug-able component/aggregate approach", it indeed sounds very good! (Note however that it's not entirely new either: it's another OOP technique that replaces inheritance with composition, as described e.g. by Gamma et al.)
The next steps would be (for me) to read more about it, in order to get a better picture, specifically about the applicability to Cafu. I still have to read the other material that is referenced in this text, and in fact have the Game Programming Gems 6 and the Design Patterns book already lying on my table.

At the moment, I'm ready to explore if and how the proposed solution can concretely be implemented in Cafu. I'm confident that it can, but I'd prefer to better understand the pros, cons, and ramifications first before really forming a decision about it.
(I am enthusiastic enough about it to implement this, if it turns out as worthwhile as hoped and survives our internal review / debates / scrutiny tests, even if you eventually decide not to use Cafu for your project. Hope that's ok with you. )

If we become convinced that that is the right direction, another good aspect is that switching to plug-able components can be done in transitional, small steps, so trying out a minimal implementation should be easy.

One of the major benefits is that you can create new game characters or objects combining all the needed features and behavior without actually changing your object hierarchy. Entity systems allow to implement changes without coding, so even designers (or modders) could create new unique characters easily.

This seems to be a separate, independent step from what is described in the text by Mick West: He "just" describes how functionality can be mixed and matched with plug-able components rather than with inheritance.
If this system is further extended so that "new things can be made without coding", it seems to be a consideration on top of all that. (But then I still have to catch up some reading on the topic. )

It just seems to me that entity systems could help people who tend to drive themselves into a corner with overcomplicated OOP hierarchies, although entity systems themselves also can get tricky if done wrong.

Yes, sure -- just note how different the descriptions in the two text that you linked are.

In summary, we don't have this at this time, but I'm very open and positive about it.

Now doing more reading...

[midix]

I'm glad that this idea has inspired you.

I don't have practical experience in game engine programming yet, but while I was reading tutorials and looking for practical implementation options, the component/entity systems somehow got my attention immediately and I got pretty excited (maybe a bit over-excited ) about the concept.

[Carsten]

Yes, the concept definitively is very exciting!

A big "pro" of a component/entity system is that its components (their C++ implementation) are more part of the core engine rather than the individual game. Thus, component approach has a tendency, when implemented to the fullest extend, to eventually "liberate" games from individual C++ code! This is a concept that still feels somewhat (at least a little bit) alien to me, but seems to be the right direction, I can clearly imagine the advantages, and I think that this is what we want.
It may also help with (or in fact, lead to) using the very same code directly in the map editor, another aspect that seems to be highly worthwhile as well.

A big "contra" - at this time - seems to be the largely open question: How do components communicate with each other?
This seems to be an inherent, fundamental problem of component systems, but I believe that I have found part of the answer (not "systems"). Actually, if we allow each component to examine its host entity during initialization, to "search" the entity for components it depends on and needs a pointer to, the questions is - as far as I can see at this very early stage - almost resolved. In the same spirit, it should be possible to resolve any dependencies regarding the order among the components in each update cycle.

And a "neutral" point is that we will have to implement this gradually, in a manner similarly as described in the cowboyprogramming.com post. This will lead to a very thorough result, which is good, but it will take longer than a more radical approach "from scratch". The implied permanent change may also turn out to be more inconvenient for developers who regularly update/sync their project with the current Cafu sources, though I hope we can constrain these inconveniences to a minimum.


We should eventually open a ticket for it, but for the moment, let me summarize some related links here. (A purely subjective and certainly incomplete list mostly for future reference, also repeating those you initially posted above.)

As posted above, a short and well written intro:
http://cowboyprogramming.com/2007/01/05 ... -heirachy/

Directly or indirectly linked from the above:

• Scott Bilas: GDC 2002 Presentation: A Data-Driven Game Object System;
  referenced from several other pages, although the slides alone are not overly helpful:
  http://scottbilas.com/files/2002/gdc_sa ... slides.pdf
• Bjarne Rene: Component Based Object Management. Game Programming Gems 5, 2005, page 25.
  (I don't have this book unfortunately.)
• Game Programming Gems 6, chapter 4.6, Game Object Component System:
  (I have this book.) In the same spirit as the above, with example code.
• Kyle Wilson: Game Object Structure: Inheritence vs Aggregation, 2002, http://gamearchitect.net/Articles/GameObjects1.html
• http://t-machine.org/index.php/2007/09/ ... nt-part-1/

Google search for "game entity component system":

• Considerations and comparison of variants of component systems:
  http://gamedev.stackexchange.com/a/4966/1101
• mentions Unity3d as an example for component systems:
  http://gamasutra.com/blogs/MeganFox/201 ... _Model.php
• a claim for how "systems" solve the communication-among-component problem:
  http://piemaster.net/2011/07/entity-component-primer/
  http://piemaster.net/2011/07/entity-component-artemis/
  (With regards to contents, I disagree, this is not what I indent to do!)
• Plenty of additional resources and links:
  http://stackoverflow.com/questions/1901 ... ine-design

Some of the above texts are unfortunately a bit one-sided: (potential) problems and shortcomings of the component-based approach are rarely discussed.


In summary, I clearly see the positive aspects of component systems, and now I can even see how we can take the next concrete steps, try things out, grow into it, examine and learn more about things as we go, and eventually progress towards all the good things that one expects.

This also combines well with my current mission to improve the game and entity code, that has the goal to make the game development experience for new (and existing) users better. As always, anyone who wants to help with the implementation is heartily welcome!

[midix]

About communication between components - I've seen on some forums somebody talked about pub/sub systems but such approach might slow everything down, so people tend to go for compomises - store related component pointers in components themselves.
With pub/sub it might go like this:
HitSystem
HealthSystem

HitSystem does something and publishes a Hit event "Entity with ID=10 has been hit".
HealthSystem has subscribed to Hit events, so when its turn comes, HealthSystem grabs the pending event and recalculates character's health (and maybe publishes a new HealthChange event).

Such pub/sub system seems pretty flexible solution, but it also creates many problems to solve, like event list management to avoid situations when events are being generated much faster than the engine is able to consume; avoiding event recursions (maybe quotas - how many events can be processed by each system during one game loop iteration) etc.

[Carsten]

Thanks for that overview!

My own rough plan in this regard is (an entirely preliminary and very early draft, never double-checked):

On game init, first instantiate all the entities that are in the map.
Each entity is considered a "component container", and its list of components is initially empty.
(As is the essence of the component-system, in this description there is only one common entity class from which each entity instance is created.)

Next, we "somehow" create the components that are relevant for each entity, and thus fill the entities component list. For example, the textual description of each entity in the map file is parsed, and components of the proper type added to the entity.
(The components have a class hierarchy. Each component also has a pointer to its parent entity, i.e. the entity that holds/owns it. This pointer will be needed in the next step.)

Now, each entity is constructed, and each entity has its components, but we're still in "initialization phase".
Now I would allow each component to "search" its parent entity (using the pointer mentioned above) for sibling components that it needs to fulfil its purpose. If the sibling component is found, the component keeps a direct pointer to it, possibly casted to the proper (concrete, derived) type.
If the sibling is not found, the entity is dysfunctional, and we somehow have to deal with the error.
Metaphorically spoken, you could consider this as a linker step, where unresolved references are dynamically found and resolved.

At this point, initialization is complete, and every component knows everything it needs for e.g. updating itself once per game frame.
Of course, the above alone is likely not sufficient for a real implementation. Extra mechanisms for propagating events across entities, or for making sure that one component is not accidentally updated multiple times per game frame, etc. are still needed.
But - afaics, at this early stage - it seems to "solve" the communication problem.
It also keep things "object-oriented". Components are OOP objects, with data and code. (I still cannot get why some folks are so keen on "systems", which seem to give this up for no good reason.)

[Carsten]

I thought a bit more about this, and some related aspects:

Entities and Windows

The concept seems to work not only well with game entities, but with the windows of our GUI system as well!

In fact, our window class hierarchy is a lot smaller and simpler than our entity hierarchy, and would be ideal for first tests with actually implementing components.


Hierarchies

What we have with GUI windows already, namely that a window (the parent) can "have" several other windows (the children) seems to make a lot of sense in the game entity context as well, e.g.:

• wheels that are attached to a vehicle,
• entities that move on or with a moving platform,
• cameras that are attached to human players,
• etc.

(The concept of hierarchies is somewhat orthogonal to the concept of components, and we should probably implement it for game entities, too.)


Unclear feature transition

As long as components are "additive", e.g. each component adds a new feature, everything is good. For example, with GUI windows, having components like "Background image", "window border", "display 3D model", "edit text", there are no conflicts and no interference.

But how would we use this to implement a "choice box", a "combo box", or similar windows with non-trivial, advanced functionality?
This I still don't see a good solution for.

With game entities, the situation is similar:
For example, the "Company Bot" could have components "3D model", "Bot AI", and "human-like physics". But where goes the intermediate "glue" code that animates the 3D model according to the results of the AI and physics?


Scripting

It seems that scripting is at least a partial solution to the above questions.
As such, scripting would no longer be an optional add-on that both C++ programmers and map designers can avoid, but becomes a central, core part.

Scripting would provide for all the glue code, whenever no component is responsible.


Requires Prefabs

Compositing windows or entities with components, and tweaking them as desired, can be a large amount of work. The typical concept of a "monster" or a "car" with fixed functionality no longer exists.

Saving pre-composed entities or windows as "prefabs", so that they are easily available for later reuse, seems to be an important user feature.

[midix]

When reading that long T-Machines blog, I got the following ideas.

It is great to resolve component dependencies on initialization but the problem is that we know only rules for component definition interactions but we don't know which runtime instances of the components will need to know about each other.

For example, we have a MissileTarget component and a Missile component (of course, in a real game nobody would create such specific components...)
When initializing the MissileTarget component instances we know that they should receive data from Missile components. So each time we create a new Missile component instance, we need somehow to create links between all the instances of Missiles and MissileTargets because we have no idea, which MissileTarget might be hit by some certain Missile during the game. So we'll have multiple lists for dependency solving, and memory usage goes up. But when one Missile is being launched it will be pretty easy to find and shoot some certain MissileTarget.

If we go other way (high level without any compromises), we would have some ComponentManager, which manages lists of current runtime components and their dependencies, thus avoiding the components themselves from containing any redundant or game-engine specific data. But the CowboyProgramming article said:

Initially we had all component references going through the component manager, however when this started using up over 5% of our CPU time, we allowed the components to store pointers to one another, and call member functions in other components directly.

So I guess it's a compromise - decoupling components vs CPU usage. It's not bad idea to sacrifice some bits of decoupling as long as we still can create all the components in a data-driven way (+some scripts).

About glue code. Ideally, each (sub)system should match one single component but in practice there shouldn't be any problems to allow one system to process multiple components thus gluing together game state and behavior for separate components. Crucial game engine functionality should be implemented in subsystems which sequentially process each component (RenderSystem, AnimationSystem etc.) and some systems might process multiple components.
For example, SoundSystem needs Position component to know where to position the sound in the 3D space, and also it needs SoundResource component to know ID of the sound to play.

The game logic itself could be processed by some common ScriptingSystem which essentially is just a host for a chain of scripted game logic systems (like Health, Points etc.). It is important that the systems themselves stay as stateless and decoupled as possible. The components are the state and the glue between various systems, and the systems are the behavior of the game engine and game logic.

About nested components - I guess, there's nothing wrong to implement some components which contain other components as long as everything stays as decoupled and data driven as possible. From the other hand, nested components will be more difficult to find from (sub)systems - we need to know the parent to find its children, even if the current system itself doesn't do anything useful with the parent. So nested components might create unnecessary coupling between systems. For example, "wheels that are attached to a vehicle". Some imaginary WheelRotationSystem doesn't need to know anything about the vehicle to be able to rotate the wheels. But if those wheels are nested inside of the vehicle component, the WheelRotationSystem will have to find the Vehicle component first and then find the Wheels component to rotate the wheels. And what if suddenly someone decides to create a vehicle with wings instead of wheels? WheelRotationSystem accesses Vehicle component and suddenly finds that there are no wheels, so now WheelRotationSystem has just made one completely unnecessary operation.

I guess, this means that generally component hierarchies should be avoided. For example, instead of:

Entity1
VehicleComponent->WheelsComponent

it is better to implement
Entity1
VehicleComponent
WheelsComponent

But we could organize the game editor tools to allow nested components and then flatten the component structure in-game when creating entities, thus getting the best from both approaches - intuitive workflow for game editors and efficient direct access to components from game engine systems.

About the window example.
If we have a dropdown list with choices, we could have an entity with "window", "background image", "window border", "display 3D model", "edit text" components and also a "choice list" component. As it is allowed a single system to process multiple components, some GuiChoiceListSystem could use the "choice list" component (which might also contain current selected choice) and also the "window" component to know where to render the choice list.

And the same way AnimationSystem cares only about entities which have Animation component (or maybe also Position to run animations on entity's position/rotation).

It seems, each entity upon creation should register itself with all the systems which have corresponding components. This also could be implemented to work data-driven way, so we can use game editor tools to specify which component should register with which systems.

About prefabs - T-Machines article talks about it and shows how to implement it SQL RDBMS way:
http://t-machine.org/index.php/2009/10/ ... os-part-5/

Adam calls them "assemblages":

A neater way to handle this is to extend the ES to not only define “the components in each entity” but also “templates for creating new entities of a given human-readable type”.

[Carsten]

Hi midix,

wow, very long and thoughtful post of yours!
I'll do my best to summarize, to keep things clear:


About components knowing each other, and your Missile / MissileTarget example:

I think we must discriminate between Entities and Components:

• Entities are the objects that exist in the game world, and they're essentially made up of a list of components.
• Components are "features" of an entity, and added to entities to build them.

With "components knowing each other" and "resolving dependencies during initialization" I was only referring to components within the same entity.
"Cross-entity" relationships are probably only resolved at run-time. For example, if the player fires a missile, the missile is instantiated and only then(!) is the world searched for suitable targets. (After which a pointer to the resulting target may be stored in some component (of the missile) that is responsible for controlling the course the missile.)


About glue code:

I've read and thought more about this, and later in your post you explained it with "GuiChoiceListSystem", and now I believe that most "glue code" should just be another component. Such "behavioral" components could either be written in C++, or entirely in script, it doesn't matter (except that script is fully accessible to the map designer, too).


About nested components:

I don't think we should have them. It should be possible to nest entities, but not components.

(The only possible exception that I can see is if an entity has a "GUI" component, and the GUI component itself is implemented as a hierarchy of windows, that in turn have their own window components...)


What others do:

In my research, I happened to come across "Unity 3D". They have a component system, too, where "Entities" == "Game objects".
I like their approach, because their components are OO classes and objects, there are no "systems" involved.
If you want to have a look, here is a good intro:
http://docs.unity3d.com/Documentation/M ... jects.html

Oh, and they've plans to rewrite their GUI system with components, too, and I found that the related talk serves as a very nice introduction to "component systems" as well:
http://video.unity3d.com/video/6943180/ ... he-new-gui


Code:

Let me make a suggestion: I'll come up with some concrete code during this week (in fact I couldn't wait, and have already worked a bit on it... but it's not ready to be shown yet ). It's only a minimum, and I'll polish it a little during the course of the week, then post it.
Then - if you're still interested, of course - we'll have something concrete to discuss.

[midix]

Yes, it would be much more productive to have some code to play with.

As I've been programming business software solutions lately, I'm thinking more business programming & datadriven way, and that's why I imagine Entities being like ID fields in a table and components being some properties collection in another table (like "business entities"), and Systems being the "business logic". Similar to the idea when that cowboy programming article says:
"There is no "game entity object" as such. Each column in the diagram represents a list of identical components, each row can be though of as representing an objects. The components themselves can be treated as being independent of the objects they make up."
And also Adam in his T-Machine article says that ideally Entity is just an ID which attaches all the needed component instances. But I understand that this might be too abstract model for a real-time game engine, that's why Unity3D decided to mix it with OO.

[Carsten]

And also Adam in his T-Machine article says that ideally Entity is just an ID which attaches all the needed component instances. But I understand that this might be too abstract model for a real-time game engine, that's why Unity3D decided to mix it with OO.

As a side note, in another business project, I do some database programming too, using Python as the main language and http://www.djangoproject.com as the framework, and I like it a lot!
In Django, they've managed to bridge the gap between database "tables" and OO "classes", or database "rows" and OO "instances" very beautifully, so that even there, you're not forced to "artificially" separate the "business logic" from the data -- it's full OO development, "even though" you're writing a database-based application.

Back to our case, component systems, I don't think that Adam in his T-Machine article has achieved a better or more advanced abstraction of entity or component systems. To me, it still feels like he is a step back (like a C programmer who is not yet used to the concepts of OO), and his next step of abstraction would be the insight that applying OO-concepts to entity/component systems will in fact help the matter.

Anyways, I started writing some code, with the intention, as mentioned before, to try to migrate the relatively small window hierarchy of the Cafu GUI system to a component-system.

Maybe a question beforehand: What is your favorite way of accessing the source code?
Browse online, compressed archive, Subversion, or Git?
At the moment my changes are in Subversion and thus can be browsed online, but not yet in Git or in a compressed archive.

The first related change is in r683, progressing upwards: You can see the full log at
http://trac.cafu.de/log?verbose=on

In the log, click links like r683 or [683] to see the changes for revision 683, or links like @683 to see whole files or directories at that revision.

Please let me know if you'd rather have Git and/or archives (I'm working on getting things into them, too), and of course first impression, comments and questions on the code!