Event Handling about amethyst HOT 6 CLOSED

For an example, the style I use is a struct of {Atom64, VariantMap} where Atom64 is a unique identifier (64-bit integer of packed string, but can be whatever is needed, a flyweight string should world) and a VariantMap is just a Mapping of Atom64's to a Variant (which is an in-built list of useful base types, from booleans to integers, string, Vector2/3's, Quaternions, Another VectorMap, etc...), which is conveniently also a good mapping point for scripting layers.

from amethyst.

If systems run on their own threads shouldnt we use channels for events. My naive approach was to use Arc to put dynamically allocated arbitrary message structs on the channels.
We need to dev. a library that provides Request reply and pubsub patterns over channels. But any approach workout dynamic allocation per message will work.

from amethyst.

Channels are one (bruteforce) way to approach this. It's a question if we can put in something more efficient and convenient, perhaps even at the specs level.

from amethyst.

Quoted directly from Gitter on September 21, 2016 7:34 PM:

Hey everyone. I've been thinking very hard about event handling lately, and I must say, it's really hard to get right! 😄 After reading a lot and looking at what we currently have, I did arrive at a few conclusions:

1. I personally dislike the ergonomics of our current event system. The usage is too verbose for my tastes and doesn't allow for the polling of multiple event types at once. Something simpler and more data-driven is definitely needed.
2. I do not want Broadcaster to become a global switchboard for communicating throughout the entire engine. This is just asking for trouble! I believe we should stick to a small and fixed Event enum that allows higher-level code to react to low-level events (user input, window events, etc.) and nothing more.
3. Gameplay events are supposed to be extensible, while engine-level events don't need to be. By having separate systems for both, gameplay events can be data-driven at the expense of performance, while engine events can be hardcoded and very fast. Also, they can be processed independently of each other.
4. I believe that each processor should have its own internal event queue that outside code can poll/subscribe to, instead of every subsystem being tied to one massive global queue. The specifics of how this API should be written are up in the air, but here is a primitive example of what I mean: a Physics processor might have an on_collide() method that accepts a closure like | e1, e2 | { /* Do something... */ }. These closures could be written in Rust or in script, and could be executed in parallel for better performance.

I would like to hear your thoughts on this, especially since many of you probably have a deeper background in game development than I. Any better ideas?

from amethyst.

I'm might just be speaking gibberish here, as I've not really looked into it.

But you could allow system level events to be extendable to a point.

Somewhere along the line when setting up the engine, you can specify a type for system events. As long as this type implements std::convert::From<Event>.

This allows the custom event to be turned back into the system event via Into, as it has a blanket implementation in std.

impl<T, U> Into<U> for T 
where U: From<T>

Which of course this simply means, when handling normal system level events, you can call .from on the custom type to turn them into the custom type, or .into to convert them back to the system event when the engines code needs to work with them.

However, this wouldn't be data driven. But the lack of this being data driven could be seen as a way to discourage extending this, except for the cases where you really need something on the level of system level events to represent what you need.

I'm not really involved with the development here, and I fully expect this not to really align with anything, or there being two billion issues I've not thought about and thus it's fine to ignore this :) Just food for thought.

from amethyst.

This issue hasn't been updated in a while, and there isn't as much content to see here compared to #229. Therefore, I will close this issue. Feel free to reopen it if needed!

from amethyst.