• 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.

Good-ish news on the parser front: Dave Kuhlman released a new version of generateDS, which now succesfully parses the Collada schema, but the generated parser still fails to parse more complex Collada files, specifically transformation elements such as translate. I hope it's "just" a bug and not a missing feature. If it is, I just might contribute the missing features myself if needed and it's not too complex. In any case, this is promising.

I also started writing the C header parser using Pyparsing. It's easy enough to work with, though I wish its documentation was more decent and its interface cleaner and more Pythonic. Anyway, from the humble start it looks like it won't be too difficult a project for the small subset of C grammar I need it to understand. I already got it to recognize some preprocessor directives, now I just need it to do something with them, and then it's on to actual C grammar.

And I'm still waiting for Trac 0.11 to be released, and hoping it will be easier to install than 0.10, which I never could get to work on shared webhosting.