Quote:Original post by Jookia
But that'd require more memory wouldn't it? Why not an enum? Or some crap?
Those are speed vs flexibility tradeoffs that you have to decide for yourself. Both kinds of systems are being used out there.
State Event design.
Those are speed vs flexibility tradeoffs that you have to decide for yourself. Both kinds of systems are being used out there.
I still don't quite get what you're asking. You want a way to make a flexible event class that can be used to pass a wide variety of information to an event receiver, right? lightbringer already gave you a template for that.
As for casting, using RTTI (runtime type information) is not exactly cheap performance-wise. And an enum has a fixed number of elements in it, which doesn't help with extensibility.
As for casting, using RTTI (runtime type information) is not exactly cheap performance-wise. And an enum has a fixed number of elements in it, which doesn't help with extensibility.
Author
Yes, I don't get how to actually implement it though. Can you give me some psuedocode or something to push me in the direction?
I'm not sure if this meets all of your requirements, but have you seen the Effective Event Handling in C++ article?
Quote:Original post by Jookia
Yes, I don't get how to actually implement it though. Can you give me some psuedocode or something to push me in the direction?
Implement what?
Author
Here's the thing: I'm torn on what to do.
My events range from a bool being changed to a player being hit by a projectile with X damage.
The problem is, isn't an entire derived class from the event class just to signal that a bool is changed a bit.. overkill?
All I want is a unified way of sending messages and bits of data. I don't know what to do.
Should I just use functions like onX() and forget onEvent all together? Wouldn't that build up code? Ugh.
Maybe I should design a system then try and implement it based on the design, not the other way around.
My events range from a bool being changed to a player being hit by a projectile with X damage.
The problem is, isn't an entire derived class from the event class just to signal that a bool is changed a bit.. overkill?
All I want is a unified way of sending messages and bits of data. I don't know what to do.
Should I just use functions like onX() and forget onEvent all together? Wouldn't that build up code? Ugh.
Maybe I should design a system then try and implement it based on the design, not the other way around.
Quote:Original post by Jookia
The problem is, isn't an entire derived class from the event class just to signal that a bool is changed a bit.. overkill?
You probably don't want to use events for regular processing. Use events for situations such as taking damage or colliding with something. Talking about event systems, I found this presentation to be quite useful, although it's not very detailed. Make sure to view it as outline because there are also extensive notes below the slides.
Quote:Original post by Jookia
All I want is a unified way of sending messages and bits of data. I don't know what to do.
Should I just use functions like onX() and forget onEvent all together? Wouldn't that build up code? Ugh.
You can also do this, and then implement an event system once you actually feel that you need one. There is such a thing as over-engineering, or seeing nails everywhere once you find a hammer.
Quote:Original post by Jookia
Maybe I should design a system then try and implement it based on the design, not the other way around.
That's always a good idea!
I'd say be prepared to do both. If there are a few "events" that make more sense as functions, you can have those alongside onEvent. As you dig in to actually implementing it, you'll start to feel the factors involved, and it will be easier to decide what you should do with each new bit of info that needs to go to the class. Think of which events/functions it makes sense for every class to have.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
