I’ve stumbled upon an issue and I’m not sure if it’s a natural consequence of the way entity components are meant to be or a fail in my design.

I have saved the comments from my code in this pastebin: http://pastebin.com/m70485ed5

If you had the time to have a look at those comments and let me know what you think, I’d be very grateful.

I’m looking forward to your next articles, that perhaps will clear up things a bit, especially implementation-wise.

Kind regards,
Raine

One option is to turn C++ into a declarative version of C++, but that is not much better than just using Prolog in the first place – in fact, in most ways, it’s worse.

So what *do* you do where you simultaneously need BOTH a declarative language AND a non-declarative one?

One option is to perform your declarative work at the system level instead of at the main language level. If your application can have its declarative parts split off like that, then this might be a valid direction to take. The entity systems described here offer an architectural split that fits with the problem domain of game development, allowing declarative and non-declarative styles to be used together only for the parts of the problem domain where they are each actually needed.

At least, that’s the aim. And hopefully I can explain it a bit better than that over time :).

I don’t quite agree with your definition of AOP being fundamentally dependent. I’ll just point to an example of the current Java middleware where concerns such as security or transactions can be developed without prior knowledge of what kind of components are deployed. Logging is a very poor example for AOP since it *IS* very much dependent on the component being used (nothing to stop developers from building functionally dependent aspects of course).

As for the rest, I’d be wary of advocating the approach too far (developers tend to take one hammer and use it everywhere) although if used in a clearly constrained subsystem, it certainly works around the inherent language limitations of Java, C++ et al (static compile time inheritance hierarchy). In that sense the relational model is indeed more suitable than the object-oriented model.

Ideally though you’d have a language with richer meta model. However, going outside mainstream languages you will hit the hiring/training issue and potentially also the additional cost of framework and library development.

No perfect solutions, it seems.

Without knowing how you have arranged your components, there’s not much specific alternative ideas I can offer, but if you find the data is frequently proving an annoyance to access then you should probably rethink either how you’ve split functionality between components, OR how you are actually invoking systems each game-tick. If you read between the lines on the SQL side of things, one option is of course to merge multiple components into a single component before passing them to the system for processing – something like that might help you?

1. Query the component which has the transformation data.
2. Cache the component that has transformation data inside Entity.

Hardly ideal. Also if you implement physics system as a component which is updated in another system, you need to update the transformation of it’s visual component, causing unnecessary dependencies.

It can be solved by having the transformation data in Entity. All systems update since components are linked to an entity..

Regarding archtype, a better name is to use is Palette.

NB: I only found Mick’s blog post very recently. It’s a good introduction to the ideas and approaches in entity systems – but again, it only covers basics.