You mention a complex example.

You could just have a WalkComponent, and then have it contain all sorts of leg combination and movement of those legs. You can contain all this behaviour within one component.


E.g., my WeaponsComponent has Targeters, WeaponControllers, and Weapons.

Each targeter has a list of weaponControllers, and each weaponController has a list of weapons. Each weapon fires a projectile of a certain type.

Once upon a time in a kingdom far, far away there was a King who was fed up of having his toast burnt every morning by the cook. So he sent far and wide across his land for subjects who might be able to provide him with decent toast. After months of searching, finally two people turned up in his court - a software engineer and a hardware engineer.

"Tell me your solutions!" spake the King. And the hardware engineer said, "My lord, we could have a toasting device rigged to the mains, which has a dial on the side of it. You wind the clockwork dial which unwinds slowly, and that determines the length of time the bread remains in the toasting device, for when the dial stops, the toast pops up. After a couple of goes we'll figure out the perfect point to set the dial for you and draw a mark on the dial face."

"And what of you?" enquired the King of the software engineer. The software engineer replied, "My lord, instead of a simple clockwork timer, we employ a 4-bit microcontroller, which is programmed by tapping two buttons on the side of the toaster to increase or decrease the shade of toast required between 16 shades. The microcontroller uses a lookup table of millisecond times to determine how long to keep the toast in the toaster. We can program the millisecond timer using a simple Bluetooth interface using TCP/IP to send an XML document containing the millisecond values. Just think, my lord! A different shade of toast for any occasion!"

The king wisely had the software engineer executed, and the land lived happily ever after.

Cas

It'd largely depend how complex your game is I guess, I think I'm *just* this side of it being overengineering - but were I to start adding in network play or game replays then it'd probably be worth it. On the other hand something like <a href="http://www.bay12games.com/dwarves/">Dwarf Fortress</a> would probably be impossible with a traditional Big Entity Hierarchy.

I have no  idea what actually drives DF internally, but it'd be interesting to find out.

You can see what I'm doing already with Galactic Commander:
http://private.is/arni/gcom/

The XML file is getting bigger and objects are more complex:
http://private.is/arni/gcom/gocs.xml

Overall this is going very well.


edit: I'll try to add more complex and different game objects for demonstration purposes.

I've been lightly following this line.
Using your walk component. Putting all possible leg movement seems a bit excessive. I would think that you need to have an abstract leg movement class, then have classes that extend that for specific leg movement. Being that a given unit would only have a specific leg movement and you would add the leg movement that you need.
  The abstract class would have the common methods, like walk(), which would be used throughout the game. The only object that should care (per say) the specific movement is the unit.
  Yes you would have a lot of classes for each type of movement, but if you come up with a new movement you just add a new class, not change the existing one.
  I hope I explained that well.

That wasn't OO thinking, that's attempting to model physical objects in what amounts to a program model - probably where most people fall down with OOP.

OOP is perfectly fine for all of these problems so far described; if you find you need some domain-specific problem solving and you're a Java programmer, consider modelling the ES implementation problem in OOP rather than the direct solution. In other words, use OOP to write an ES, then implement your game using the ES.

Of course if it's that complicated you're probably also using more than three levels of indents, and need spanking.

Cas

Well, that's exactly how my games work.

Cas

Question is: why would you convert a completely simple and intuitive system like that into some newfangled and probably slower and harder to understand system?

Cas

I code my games for learning, I've never yet finished one, but I hope I understand something about technology or software engineering each time. Playing with entity systems might be fun, and that's reason enough for me YMMV

Endolf

It looks absolutely horrible compared to my XML configurations More Spring hate from me.

Cas

Just compare it with Java sourcecode.
If your whole game is in one class, you're making a (beginners) mistake.
Same thing for XML. Split it, and make references to other XML files.

In the end it's all about managebility.

I dig this idea but I'm confused about a few things.  The post linked to here from T=Machine mentions that the Flyweight pattern should be used for components (he said this in the context of adding functions to components but since functions are not relevant to Flyweight I assume that he meant the statement to be general).  Right below that it says "all data lives in Components; ALL data"...

So I've got a component for "Position".  It holds my Entities' 3D position.  For it to be flyweight wouldn't make sense since it updates its data to what is basically a random value constantly (creating a bunch of instances!).  Maybe he was mentioning Flyweight as only for cases where its useful?  I would not expect it to be normally useful but I might have confused the whole thing.

I'm also not sure how I could have, say, a Physics component/system, an Animation component/system and a Collision handling component/system and have them coexist safely.  I assume that individual systems need to synchronize with one another but aren't they supposed to be completely distinct?  Or is this an "as distinct as possible -- suffer through the synchronization" kind of deal.  How can three systems (potentially with order dependencies) update/utilize the same entity's position value?

( Is this similar to categories in Objective-C?  Or mix-ins in other languages?  Also see Groovy DOM-Categories : http://groovy.codehaus.org/Groovy+Categories )

Finally, the analogy to RDBMS is spot-on.  I see the entity idea less as declarative-programming than procedural-programming (which undeservedly got a bad name after its popularity faded).  Of course, an OODBMS isn't usually a bad thing either.  If they work for your games needs then switching to db4o or something is smart.  I find it hard to use because of its object activation policy and I don't have serialization bottlenecks so I haven't bothered but if I did I'd switch DBMS in a heartbeat.

- Handyman