• Entities contain arbitrary data in attributes. These compose the Model.
• Entities can contain any amount of features; these are the controllers.
• Subsystems (for lack of a better name) link entity attributes to lower-level systems - such as the renderer, audio mixer and physics simulation - and thus represent views into the scene.

Features are normal tasks in the engine, based on cooperative multitasking. They can read from and write to attributes and create, trigger and listen to signals (an implementation of the observer pattern), which is how they communicate with each other. Subsystems also listen to signals to get notified of attribute changes. Attributes can be shared between features; for example transform is a common attribute probably used by almost all features and subsystems. Sharing of attributes is based purely on their names, there's no actual cooperation between features and subsystems except for signals and of course documentation.

I think a rough example is in order again:

1. A ship gets hit, triggering the hit signal.
2. The damage controller feature is listening to this signal and gets notified.
3. Damage controller decreases ship health accordingly and notices it's below zero: it adds a destruction sequence feature to the ship entity and stops listening to hit events.
4. Destruction sequence adds an audio source attribute to the ship entity (if it doesn't already exist), spawns particle effects for a while and finally marks the ship entity for removal.
5. The audio subsystem notices the new audio source and adds it to the low level audio mixer.

What do you think? Input is still welcome, I haven't actually started implementing this yet. And I still have at least a couple of open questions:

1. How should signals be triggered externally, for example by features in other entities? Should they just trigger the signals directly, or should there be an "external API" consisting of callable attributes?
2. Should features occupy named slots like attributes, or should they just reside in a generic list? I'm currently leaning towards the latter approach and reserving names just for attributes, since feature don't have to directly know about each other.

I still have to design the rendering pipeline; I already have a general idea of what I want, but details are kind of blurry. But that's the topic of another post.

1. Data container entities with single-instance subsystems handling all the logic

2. Feature (aka component) container entities, with all the logic and data contained in the features

Which do you like more? In my opinion, the first option has the advantage of being perhaps more intuitive and clearer to use: you just assign features to attributes, whose name tells what they are for. On the other hand, the second interface depends less on magic and is perhaps easier to extend with new feature types, as there are no predetermined names for feature "slots" (in the first option, the names are defined by the subsystems that handle the logic of entities). Of course you could also use subsystems in the second option and "intelligent components" in the first option, but these two interfaces seem to fit those two underlying designs best, at least in my opinion.

If you have any questions or general comments about either of the designs, feel free to post them, all input is welcome.

This thread on Gamedev.net has been really helpful for getting them brain juices flowing, and as I wrote there, I've got a couple of alternatives I want to think about further:

1. Very similar to the misguided attempt of creating a unified scene graph for Spineless, but on a higher level, based on game entities, not low-level scene graph nodes. Entities contain just data, while subsystems (or workers as I called them) contain all the logic of how to deal with the data. There are no components per se.
2. Components define only behaviour, while entities contain components and their (possibly shared) data.
3. Entities are solely containers for components, while components contain both behaviour and data.

At the moment I'm mostly leaning towards the first alternative, though the other two have their advantages too, and all of them seem quite elegant to me. I'll have to think more about this first, and input is of course always welcome.

Brainstorming for Red Nebula has piqued my interest in reading sci-fi again, so I started reading Iain M. Banks' Use of Weapons. I really like his stories and writing style; they're definitely "high sci-fi" in the sense that technology is really advanced - space battles generally last only fractions of a second - and there are actions sequences and such, but they're not corny adventure stories or anything. I think the genre is called "hard sci-fi". The other sci-fi writer I really like is Philip K. Dick, though his style is completely different and not that much centered on technology.

I've also done some coding, but not much. Mostly just stubs for the new scene package and small fixes here and there. I should get resource management out of the way at some point, before starting to really work on scene management.