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.

thanks, that was also my first thought, maybe easier to maintain

EDIT:just though that maybe the answer can be found in the data, like if I handle same data (let say speed) than == same component but if I handle each legs states as they have not both the same number => then == different components ?

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.

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.

I dont really like stuff as XHTML/W3C/Collada/etc... basically all those new standards that claim they handle about everythings and works better, give a lot of promess, and finally make that your website is only viewable by browser fully CSS12 compliant and not by the most popular browser... and make you wensite missed by 80% users... , but about those ES/components system it seems for me to better match the reality (as far as I understand it )

Has anyone looked at LINQ in .NET? It seems to be a way to do SQL like queries on datasets that is in memory.

I've rewritten the simulation editor I'm working on to using a component system. I've found that many components are just wrappers for other objects. An example: I have a Text3DComponent that just a wrapper for a Java3D Text3D. The actual data is stored in the Text3D object. The component exposes the data (font, text, size etc) as a list of properties. This list is used for serialisation and in the editor ui. It also has methods to set and get all properties to make it easer to use the component from scripts and other components. But here comes the "dirty" part that I'm uncertain about. Text3DComponent extends a SimulationComponent. It has an attachedToWorld and detachedFromWorld method that are invoked when the component is attached or detached. Text3DComponent uses those callbacks to attaches its Java3D node to the scenegraph. Is this wrong? Should the Text3D scenegraph object be stored in the component or the system. Shoulde the attaching be done in the system instead?

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.

If I'm getting ES right, the 'old' procedural or OO approach is to think;

'a game is code controlling a set of data'

but the new ES approach is to think;

'a game is a set of data which uses code to change itself'.

The advantages of thinking in this new way are enormous! Everything (including logic code) just becomes a set of UIDs - change 1 int and you can change the behaviour of anything. Better still you can easily and quickly find things that were hard to find before (How many trees are near me?, Which players are running away?). With ES these are just easily optimised database queries.Game state persistence is built right in! Perfect for distributed apps...I like this idea! I think we'll see more of ES, especially in more complex games.

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.

At the risk of inserting a noob question, can anyone show how (if at all) it could be incorporated in a "game" loop like the following:

while (running) { // tick something over something.tick();

// display something to the user render(something); }

Would what be the "something" that ticks over here? Would it be a single Entity Container, containing everything that has been set up? This would presumably imply that every entity would have a "tick()" method, or some other similar way of updating itself.

Also on a completely unrelated thought process, would other non game world objects like user interface objects be entities too?

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

...or something like that. Typed off the top of my head, and trying to convert into java, didnt bother firing up eclipse, so where there are stupid mistakes try to ignore them

Quote

Also on a completely unrelated thought process, would other non game world objects like user interface objects be entities too?

If you want them to be part of the game, yes.

I would advise start off with them as "not", but you may decide to add them in later. Many games decide to merge UI and game sooner or later.

For instance, lots of games run the renderer in the background of the main menu, showing a simulated bit of game (AI battling it out on one of the game maps, for instance).

For instance, lots of games like to have the UI context-sensitive based on what's happening in-game: if the UI needs to read the state of game objects, and needs possibly to alter the state of game objects directly (e.g. "set the "selected" game unit"), then it's generally going to make life easier if the UI can "speak" directly to the entities.

But ... for the first time, this is hard enough already, I'd probably aim to keep them separate as long as possible, just to keep yourself as un-confused as possible.

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?

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org