Working on a gernic event system for Torque
by J. Donavan Stanley · in Torque Game Engine · 06/07/2003 (11:10 am) · 42 replies
I'm currently close to being finished with a generic event notification system for Torque objects that I'll be submitting as a resource. Here's a short rundown:
The major players are:
Publisher - A mix-in class that supports "publishing" and broadcasting subscriptions.
Subscriber - Another mix-in that knows how to subscribe and receive notifications.
Subscription - The actual notification object. Mantains a pointer to it's publisher and a list of subscribers.
SimVariant - A Variant object that can represent any Torque type.
An example usage might be:
We have a item that, when equiped increases the health regen of a player. So in when the item gets equipped it does something like this: "player.subscribe( ID_HEALTH_REGEN, this );". Then each time the player object starts a health regen all of the subscribers get notified and receive a SimVariant containing the amount of health that's being regened. The item can then modify that value and it will get passed along the chain. (Or it can return false and stop the publisher from notifing any other subscribers).
Another possible usage is for when an NPC gets attacked. It can broadcast an "I'm being attacked" event and pass the attacker, the attackers location and the type of attack in a linked list of SimVariants to all NPCs within a certain range.
The reason I'm bringing this up is that when I release the resource I planned on adding a handful of subscriptions "out of the box" and leaving the rest up to the individual developers. So I thought I'd ask here if there were any particular events people were interested in.
The major players are:
Publisher - A mix-in class that supports "publishing" and broadcasting subscriptions.
Subscriber - Another mix-in that knows how to subscribe and receive notifications.
Subscription - The actual notification object. Mantains a pointer to it's publisher and a list of subscribers.
SimVariant - A Variant object that can represent any Torque type.
An example usage might be:
We have a item that, when equiped increases the health regen of a player. So in when the item gets equipped it does something like this: "player.subscribe( ID_HEALTH_REGEN, this );". Then each time the player object starts a health regen all of the subscribers get notified and receive a SimVariant containing the amount of health that's being regened. The item can then modify that value and it will get passed along the chain. (Or it can return false and stop the publisher from notifing any other subscribers).
Another possible usage is for when an NPC gets attacked. It can broadcast an "I'm being attacked" event and pass the attacker, the attackers location and the type of attack in a linked list of SimVariants to all NPCs within a certain range.
The reason I'm bringing this up is that when I release the resource I planned on adding a handful of subscriptions "out of the box" and leaving the rest up to the individual developers. So I thought I'd ask here if there were any particular events people were interested in.
#2
06/08/2003 (7:20 am)
As allways. It sounds very good.
#3
The spatial idea is a must imho. E.g. you drop a bomb, and the bomb explodes at x,y,z. It sends you a "I exploded at x,y,z and anyone who is within range w of my explosion are annihilated"
Another wonderful thing you could add are timed events.
Example: fighter plane fires off a missile. Missile when created sends off a "Send me a explode event in 20 secs" to the event system. 20 secs later the event manager sends the "Explode now" message out to the missile and it is destroyed in the air.
The timer could also be used for time dependant damage. E.g. acid that every 5 seconds gives some damage to people in contact with it.
Without knowing any of the Torque system for this, doesnt most of this already exist?????
06/08/2003 (8:38 am)
Sound great. I did something similar in a small game engine prototype I made for fun.The spatial idea is a must imho. E.g. you drop a bomb, and the bomb explodes at x,y,z. It sends you a "I exploded at x,y,z and anyone who is within range w of my explosion are annihilated"
Another wonderful thing you could add are timed events.
Example: fighter plane fires off a missile. Missile when created sends off a "Send me a explode event in 20 secs" to the event system. 20 secs later the event manager sends the "Explode now" message out to the missile and it is destroyed in the air.
The timer could also be used for time dependant damage. E.g. acid that every 5 seconds gives some damage to people in contact with it.
Without knowing any of the Torque system for this, doesnt most of this already exist?????
#4
06/10/2003 (9:00 am)
MessageCallbacks sound very similar to this, and they're all totally implemented in script.
#5
06/10/2003 (12:01 pm)
Yeah... I dont see a reason for an event system like this when we have callbacks and schedule....
#6
I don't *think* I've reinvented the wheel but i'd like to make sure before I open my mouth.
06/10/2003 (12:29 pm)
Can someone point me to a reference on the script callback mechanism?I don't *think* I've reinvented the wheel but i'd like to make sure before I open my mouth.
#7
06/10/2003 (2:51 pm)
Well, the callbacks are just the things like Projectile::onCollide() They are called when a projectile hits something, ie, when that event happens. If you want to make something happen later in time, say 500ms after a projectile hits, then you can use the script function 'schedule' 
#8
JDS, let me know if you need assistance implementing this system.
06/10/2003 (6:12 pm)
I think JDS's code is still worthwhile. What he is implementing is the "Observer" pattern in a nutshell. I would use it because it minimizes dependencies and is a very efficient way to manage events.JDS, let me know if you need assistance implementing this system.
#9
I'd like to change that, so that they can be documented more easily, and so forth. But basically you call Con::executef and let 'er rip ;)
06/10/2003 (9:25 pm)
Right now there is no official way to do script callbacks.I'd like to change that, so that they can be documented more easily, and so forth. But basically you call Con::executef and let 'er rip ;)
#10
06/10/2003 (9:26 pm)
dup, ignore me.
#11
Having actual interfaces for Listener/Observer behavior and having the ability register, suspend and remove those listeners is critical to a flexible modular system.
In the case of Torque you could have a CollisionListener interface and a CollisionEvent that extended say a generic Listener and Event. Abstract and Support classes could implement the majority of the housekeeping work and you could then have specialized Events and Listeners for those Events.
This greatly decouples the implementations from the design and makes the code more readable and more self documenting.
Any event driven GUI system is a perfect example of how something like this works.
06/10/2003 (11:39 pm)
I think an Observer pattern based mechanism is more useful in the long run than just hapazardly using script callbacks.Having actual interfaces for Listener/Observer behavior and having the ability register, suspend and remove those listeners is critical to a flexible modular system.
In the case of Torque you could have a CollisionListener interface and a CollisionEvent that extended say a generic Listener and Event. Abstract and Support classes could implement the majority of the housekeeping work and you could then have specialized Events and Listeners for those Events.
This greatly decouples the implementations from the design and makes the code more readable and more self documenting.
Any event driven GUI system is a perfect example of how something like this works.
#12
The code is mostly done, I'm mucking around and tweaking it here and there. I took a short detour to upgrade TM to the latest HEAD again (now I've got to find a bug in the water blocks). Once I've got a new TM patch done, I'll apply this code to a fresh HEAD and build a patch for it.
06/11/2003 (2:28 am)
Ok so then I haven't reinvented the wheel. I wondered how I'd missed something so fundamental. The code is mostly done, I'm mucking around and tweaking it here and there. I took a short detour to upgrade TM to the latest HEAD again (now I've got to find a bug in the water blocks). Once I've got a new TM patch done, I'll apply this code to a fresh HEAD and build a patch for it.
#13
I'm going to write every one of the callbacks for my game, and no one is ever going to read this code our use it. So readability and decoupling it from the design arent advantages for me, and I imagine the case is much the same for anyone else making something with torque.
So anyways, thanks for the effort, but I'll pass on this resource because I dont see the benefits. :-/
06/12/2003 (6:32 pm)
I still dont see the advantage over just making the script callbacks the way we do now. It seems like this system is just unecessary overhead that would cause more problems than it would solve.I'm going to write every one of the callbacks for my game, and no one is ever going to read this code our use it. So readability and decoupling it from the design arent advantages for me, and I imagine the case is much the same for anyone else making something with torque.
So anyways, thanks for the effort, but I'll pass on this resource because I dont see the benefits. :-/
#14
:)
forgot the smiley at the end!
06/12/2003 (8:50 pm)
and another short sighted person said they could never see the need for more than 640kb of memory either Josh.:)
forgot the smiley at the end!
#15
I have to agree with Jarrod, though. Realize that the developers of Tribes and Tribes 2 could and probably did say that about everything that makes up Torque now.
06/12/2003 (10:15 pm)
Ouch :PI have to agree with Jarrod, though. Realize that the developers of Tribes and Tribes 2 could and probably did say that about everything that makes up Torque now.
#17
06/12/2003 (11:20 pm)
Design Patterns >>>>>> home made designs. So if the existing system is something home brew like, then replace it please. It might give overhead, but proven designs always pay off in the end.
#18
What JDS is talking about, is an event system. For the C++ code, this could then be used to call the script callbacks, or not.
I DO think its worthwhile in that I'm more at home with a message/event based system, right now the event system in torque is mainly for triggering updates.
One thing to watch out for though, is that any event system must be aware of the time of event and must maintain its network ordering (much like update events do in torque now).
If this system is only for server side stuff, then it seems worthwhile.
Phil.
06/13/2003 (12:12 am)
Hmm, isnt this a different thing anyway? Josh mentions script callbacks, that means some code somewhere has to have called the Exec function to actually call back the script.What JDS is talking about, is an event system. For the C++ code, this could then be used to call the script callbacks, or not.
I DO think its worthwhile in that I'm more at home with a message/event based system, right now the event system in torque is mainly for triggering updates.
One thing to watch out for though, is that any event system must be aware of the time of event and must maintain its network ordering (much like update events do in torque now).
If this system is only for server side stuff, then it seems worthwhile.
Phil.
#19
libsigc++ supports attaching/detaching, has been used for GUI stuff, is mature, etc.
I just compiled libsigc++ 1.2.5 under VS2003, and VC6. You need cygwin to configure the sources.
I actually looked at it some 3 years ago and have been thinking about generic events, generic callbacks, etc again lately. It's nice to see that they have continued to forge ahead. Gawd, I love open source development.
There is a tutorial and decent docs available. *Really* nice system. Check out Signals for instance. An interesting thing would be in combining this with a state machine that supported coroutines.
-J
06/13/2003 (12:42 am)
Generic events need a generic way of calling code for those events? Jarrod makes some great points above about attaching/detaching... and drawing a comparison to GUI code... Quote:Having actual interfaces for Listener/Observer behavior and having the ability register, suspend and remove those listeners is critical to a flexible modular system.
libsigc++ supports attaching/detaching, has been used for GUI stuff, is mature, etc.
I just compiled libsigc++ 1.2.5 under VS2003, and VC6. You need cygwin to configure the sources.
I actually looked at it some 3 years ago and have been thinking about generic events, generic callbacks, etc again lately. It's nice to see that they have continued to forge ahead. Gawd, I love open source development.
There is a tutorial and decent docs available. *Really* nice system. Check out Signals for instance. An interesting thing would be in combining this with a state machine that supported coroutines.
-J
#20
@Other Josh - Script callbacks and simple functions like "OnEnterWater" are not the same thing. As for the rest, I'm not sure what to say. Except "ummm wow... if you say so".
@Thomas - I still have a copy of the firt printing of the first edition of "Degin Patterns" on the bookshelf next to me. Been there done that.
@Phil - This whole thing was built around observing / mutatating other objects behaviors. I'm looking into adaptint it into a more complete event sytstem. I'm thinking that I can keep my existing "notify" system inplace and add an "send" interface that supports temporality. I've remember seeing a good implementation in one of my books (just gotta find the right one )
06/13/2003 (2:20 am)
@Josh - Thanks I'll check it out.@Other Josh - Script callbacks and simple functions like "OnEnterWater" are not the same thing. As for the rest, I'm not sure what to say. Except "ummm wow... if you say so".
@Thomas - I still have a copy of the firt printing of the first edition of "Degin Patterns" on the bookshelf next to me. Been there done that.
@Phil - This whole thing was built around observing / mutatating other objects behaviors. I'm looking into adaptint it into a more complete event sytstem. I'm thinking that I can keep my existing "notify" system inplace and add an "send" interface that supports temporality. I've remember seeing a good implementation in one of my books (just gotta find the right one )
Associate Kyle Carter
Sounds cool!