Quote:Original post by Ubik

Quote:Original post by virus-
Have subsystems register with other subsystem for messages, that way we can send messages to those subsystems that care about them but this requires knowledge of those subsystems so adding a new system might require changes to others.

An alternative to this is that you have a messaging module, and the other modules register themselves only with it, telling what kind of messages they want to send and receive. This way a module need knowledge of only one other module, and I think that in a messaging based system a dependency to messaging system is acceptable.

Though now that I think about it, messaging could be arranged so that the messaging system is the one that asks the modules what kind of messages they want to send and receive, this way only the messaging system needs to know anything about other modules. And if the modules have generic enough messaging interface, even the messaging module could be pretty ignorant about whose messages it is delivering.

Quote:You can probably draw rest of the system out and it'd fall perfectly to number 5. on Adam's list, excessive use of observer pattern

Quote:Original post by redmilamber

Quote:Original post by Trefall
I've learned that there's a lot of debating on what exactly a component should be though, and what exactly a system should be. In adam's approach, referred to in the OP, I get the impression that a component is just a container of data, but that each type of component also comes with a complimentary system that can process that data in some logical form.

Yes, it's about the separation of logic and data. i.e. the antithesis of Object Oriented Programming - and this is a large contributory factor to why so many game devs switched to doing it (at least for mainstream games dev): OOP has turned out to be almost pathologically bad for modelling game-logic systems as they've grown to the complexity they are at these days.

I think there's a certain amount of guilt that no-one wants to slag-off OOP, because it's not so very long ago (maybe a decade) that many games industry teams were refusing to use OOP at all. There are even some (I know of at least one) well-known large game development studios that only code in C still - for all aspects of the game (the vast majority of modern game programmers consider such behaviour ... odd).

You, of course, are free to do whatever you want. With simple logic (e.g. to power a basic FPS like Doom or Quake) I'm sure you'll be fine. Those of us who have first-hand experience with the nightmare of intertwined logic/data game-object systems and never want to go there again will happily go on our way with a cleanly separated system. But if you want to build the complex logic that underpins a modern FPS, with all the world-simulation stuff, then I'd advise you join us. If you want to work on an MMO, god help you if you decide to persist with mixing up logic and data - that way (at least on any MMO that survives more than a couple of years) lies madness. IME. YMMV.

Quote:
In my approach I have the logic handled in the components themselves, but since it's the components that get instanced, and not the component systems, I'm sure there's quite a lot to save doing the logic system side if one can generalize enough to do it that way.

I'm afraid I cannot see any way in which what you write here differs from standard OOP. That's fine, I've nothing against that. Am I missing something? You have instanced "things" which contain code and data - that's a standard Object, no?

But if I'm not being dumb, and that is the case, why you don't just use the standard game-industry terminology, call your components "GameObjects", and have done with it?

Quote:Original post by wild_pointer
Most definitions of OOP are tied closely to polymorphism and inheritance, of which don't factor heavily in component based systems.

class CEntityNumber12 : public CEntity{private:   CTransformationComponent m_trans;   CSceneGraphComponent m_scene;public:   virtual void GetComponentListing( vector<CComponent*>& out )   {      out.push_back( &m_trans );      out.push_back( &m_scene );   }};World->Insert( 12, new CEntityNumber12 );

Quote:Original post by Trefall

Quote:Original post by virus-
You can probably draw rest of the system out and it'd fall perfectly to number 5. on Adam's list, excessive use of observer pattern .

I've been looking for this part in his blog, but haven't been able to find it. As I'm using the observer pattern for component communication, I'd be interested in reading about it. For me it works really well, though it does create some soft dependencies which can be hard to debug if one doesn't keep a good orientation with what's happening. It won't crash though, since if the event published has no subscribers, the event simply won't be distributed to anyone and the program will move on. I'm sure there's more issues with the observer pattern when you throw multiplayer into the mix though, and surely it's not as optimized as direct references and C style messages, but to me it's been a trade for what I've experienced as a cleaner approach.

Quote:

That’s not an Entity System!

Well … at least, that’s what *most* people I’ve worked with consider to be an Entity System. But even within a single project, I’ve found multiple different ideas of what an ES is, some of which are compatible, others of which are incompatible. Here are some of the other ideas I’ve come across that people thought were ES’s.

Alternative definitions of entity systems:

1. An ES provides a different model of class-inheritance to OOP, especially w.r.t inheritance of fields. For any given entity-class you declare which aspects that class possesses, and the actual class is looked-up at runtime by piecing together all the different aspects.

2. The same as 1., but taken literally for methods as well as fields, i.e. this provides an interesting way to mix-n-match inheritance of functions/methods. So long as methods are attached to the fields upon which they operate, and/or a “pre-requisite” system is implemented such that “having aspect X automatically causes you to also have aspect Y”, then this works quite smoothly. NB: this is implementing “modular objects”: the “aspects” are complete objects from the standard theory of OOP.

3. A variant on 1. or 2. where the aspect data is pre-compiled into a large number of OOP classes at compile time, so that at runtime you are just running “normal” classes, without any lookup cost of the dynamic “I’ve got an entity E which claims to have aspect X; just hold on a sec while I build a function table to find out what the heck to do now someone just tried to invoke function Z…”

4. A way of compiling standard OOP classes into runtime-data (note: disassociating them from their OOP-ness) specifically so that you can treat them as streamed data instead of chunked binary + data. The main value of this is to play nicely with hardware that has tiny tiny amounts of memory available in the code cache and/or very very slow access to fetch extra code, but has vast bandwidth to stream SEQUENTIAL data through the CPU. PlayStation consoles especially like this approach, as opposed to the typical PC approaches. Note that in this case, the idea is that the game-programmers and game-designers are UNAWARE that there’s an entity system - it’s a runtime/compile time performance optimization, not a design-feature.

5. A system design that revolves around excessive use of the Observer pattern, but does so using standard OOP techniques. I mention this because it’s a common (ab)use of the concepts of ES’s, but lacks much of the advantages. For what it’s worth … that’s the situation I was in when I first discovered ES’s. So, personally, I really don’t count these as ES’s. These are not an ES, but an: “OMG, I need an ES!”, but many people persist in thinking (and claiming) they’re a true ES.