alecmce / xember

A riff on the Ember entity system
MIT License
48 stars 7 forks source link

Responding to "events" #18

Open pkra8 opened 12 years ago

pkra8 commented 12 years ago

Hi, first of all I was thinking about that problem for a few days and tried different approaches but none was really satisfying.

Real life example. Im having systems that are responsible for: -collision -calculating velocity/gravity -animating object -rendering object -logic (searching for enemies, regenerating hp etc)

For example, player is falling down from a platform so he gains velocity, because of time and gravity variables that are responsible for calculating it. Then he suddenly hits bottom platform, and polygons are separated but this is the point where im having a problem - right now velocity components MUST be informed that time of fall should be set to 0 and forces should be set to 0 as well. Also animation component must be requested to discontinue animating current display object and instead to show "hit" or "fell" animation. Last but not least - logic component must know that player hit ground so it will be possible once again for him to use "jump" action.

How can I achieve all of that without sensless coupling and injecting components into nodes/systems that should not ever have access to it. I thought about some "state" component but how should it work? how should i notify about continous state for example "falling" and about one-shot type of state "just fell."

Thats only really big architecture problem so far for me with xember.

Best Regards, Pawel.

alecmce commented 12 years ago

Hi Pawel,

Thanks for your question. It's a tricky issue, for sure. There are several approaches that you can take.

Firstly, you could inject a signal or event dispatcher into your system, then when an event occurs dispatch that, and bind the event to a Command. I don't believe that a fundamental division between entity systems and MVCS(RobotLegs) exists, so I'm an advocate of using the best of both approaches, depending upon the circumstances. Clearly, since you think you have an "event" use case, it feels like it could be best-served being handled in a Command.

The downside to this approach is that your command gets instantiated, executed and destroyed. That's pretty costly if you have a high-performance game (please note though that this is rarely an issue unless you're contemplating 100s of collisions per frame, and there are probably other performance bottle-necks that should concern you well before this one). If though it is a problem, then you could add a CollisionComponent to the entity that would then handle all collisions through a CollisionSystem. Those components could be object-pooled...

The real answer though Pawel is that there are as many choices as you can think of. There is no One Pattern To Rule Them All unfortunately. I would need to play with your project, understand the way you like to wire things up and how you think, as well as understand the project requirements, before I could say "in this situation I would do X". Hope this helps.

Alec