Eventing

[DavidRieman]

Here's a collection of edited forums discussions which helped form and refine the modern Eventing system used in WheelMUD, now documented formally here. This thread could serve as a good place to resurrect and continue discussions or ask for Eventing clarifications.

This thread contains restored content from prior forums; see #134 for details.

[May 2009]

In response to plans to remove the now-defunct EventReaction system...

The other EventReaction example is for the movement listening device: This also lends itself well to a Behavior... Subscribes to MovementEvents during Constructor, and the Receive method relays appropriate text messages to its current player owner, and destructor unsubscribes.

A Scrying spell Effect could place a ScryingEffect upon a target mob/player/room, whose constructor subscribes to sight-only SensoryEvents there (as well as some other stuff, probably), and relays information back to the Scrying player during the duration of the Effect (and at the end of the effect duration it unsubscribes).

Yes, that seems like a good example of how to take advantage of the strengths of the Eventing system.

(as an aside: we have to make sure we use weak references where appropriate in a subscription model or we'll inadvertantly cause all subscribing objects to never GC; a leak of still-event-receiving objects quickly hurt CPU in addition to RAM.)

Although weak references will be useful for a number of things (like caching a target for a while, like for a "follow" command), the "where appropriate" are the keywords there. Most eventing subscriptions will be from Behavior to the Thing it is immediately attached to. For example, consider an ImmobilizationEffect on a player: It only needs to subscribe to movement events on the player Thing itself. Whether the player tried to move by typing "east" or an "enter portal" command or was the target of a summoning spell, etc... There will be a request passing through the player's OnMovementRequest for the ImmobilizationEffect to consider cancelling. If the player logs out or is otherwise destroyed, the ImmobilizationEffect will likewise be removed with the player (and should be restored when the player logs back in, as it is properly part of the player).

Events are a Good Thing(tm).
We need Things to receive events, and we need Things to be able to generate them. If that is the goal, one of the big issues I foresee is keeping track of a Things subscriptions.
The best thing about this is that usually, an items events are highly localized... but the cool thing is that remote events are very possible. Think quantum events, one guy in one room throws events via remote control to another... that would be interesting...

Possibly. Would need more info to think through the "right" safe approach for such a thing, if either side is able to be removed from game without the other doing so as well. Something with MultipleParentsBehavior (like exits) might make for another option.

---

[May 2010]

I'd been thinking more about eventing as I go through code, trying to get back to a compiling codebase with a less-tangled web of interdependencies. I realize we never really discussed the topic of Cancellable events here, which IMO will be critical to moving towards appropriate code locality. Let's look at the Open command, pretending like it's a non-core extension to the system introduced externally. Here's an example of what I see happening, to minimize alteration of the core code, and thus minimize core-integration complications:

• The "Open door" command is issued by the player.
• The command system parses the command and finds that it seems to match the Open command object as found through an MEF catalog.
• The Guards is executed; they are passed and a single disambiguated target "door" object was found.
• A CancellableEventArgs object is made.
• An OpenRequestEvent (ed: just OpenRequest) is broadcast through the sender's parent's EventHandler, passing the cancellableEventArgs.
• The parent thing (being a room or vehicle or whatever is housing the player now) broadcasts the cancellable event to all it's SubThings (IE other players, mobs, et cetera) and all it's own Behaviors.
• Each SubThing repeats the above step.
• One of the mobiles in the room had a MobileBlocksDoorBehavior which receives and recognizes the OpenRequest.
• Said behavior's code checks to see if the targeted thing is a door in it's current location; it is, so it sets cancellableEventArgs.Cancel = true and sets its parent mobile to aggro against the player, et cetera.
• After the whole event broadcast is finished, the Open code checks the cancellableEventArgs.Cancel and sees 'true' so it avoids causing the target object to change its state to 'open'.

Had nothing set the cancellableEventArgs.Cancel = true then the OpenedEvent would be sent after the 'open' state was set to 'true'. So as a pattern, all CancellableEvents are pre-events and are followed by post-events if and only if the pre-event was not cancelled.

There are of course other possible reactions to an OpenRequest too. Probably most likely/notable may be the LocksUnlocksBehavior; upon receipt of the OpenRequest, it would check to see if the event pertains to it's parent thing, and if so, might cancel the event should the 'locked' state currently be 'true'. (One may want automatic-unlocking code for convenience in their codebase, where, if the sender of the event has the key on hand, this could happen immediately and influence the choice of whether to cancel the event. In turn, the UnlockRequestEvent would be sent immediately. Should nothing cancel THAT then the UnlockedEvent post-event would be sent. The OpenRequest wouldn't become finished until all things it fired and caused, including this interruption event, were resolved, causing the UnlockedEvent to be sent too first.) The LocksUnlocksBehavior too becomes more self-contained, such that the locking-related code all goes into the behavior itself and DLL boundaries/reference chain becomes less important.

In combination of both scenarios, there is a minor side-effect: depending on whether the unlock occurs first or the mobile goes aggro first may impact the success of the player seeing "You unlock the door with the iron key" before or after the mob goes aggro on them. The solution in this case would be to have MobileBlocksDoorBehavior also react to UnlockRequestEvent too, if the coder desires the mob to prevent that too; it would end up cancelling both events in rapid succession. One might discover other side-effects with other complicated scenarios, but that would happen anyway, and the good news is that the 'fixes' for such problems are generally implemented local to the subject of the problem itself.

On event GC: I've read that when using the 'event' keyword that the registrants aren't prevented from GC but I've also read otherwise. I don't have time to research that ATM, but if it is a problem, a simple solution may be to make base Things and Behaviors be IDisposable and cleanup after any destroyed Things/Behaviors subscribed events.

---

Ok so weak references are only used in eventing if one rolls their own eventing which explicitly uses weak references. So indeed, we should automatically unsubscribe any Thing (or Behavior) from any events they subscribed to at destruction/disposal times.

The CancellableEvent stuff looks well thought out. Now implementing the thing is what going to make you pull your hair. LOL.

I agree.. cancelable events seems like a good idea.
Maybe we should have all events return true if they where not cancelled? Actually I cant help but sort of envision that they would return an enumerated state. You can have a event attention to happen and work, attempt to happen but not work, attempt to happen and not work directly but still interact with another event... or do we want to go Yoda and be all about there is no try?
/me envisions a butterfly attempting to flap its wings hard enough to start a big thunderstorm, and creating a light sprinkle instead.

---

[June 2010]

Here's an example of where I'm at with making things more behavior driven and event driven. Things which are allowed to move have a MovableBehavior. MovableBehavior has the following Move method:

public bool Move(Thing destination, Thing goingVia, SensoryMessage leavingMessage, SensoryMessage arrivingMessage)
{
  Thing actor = this.Parent;
  Thing goingFrom = actor.Parent;

  // Prepare events to request and send (if not cancelled).
  var leaveEvent = new LeaveEventArgs(actor, goingFrom, destination, goingVia, leavingMessage);
  var arriveEvent = new ArriveEventArgs(actor, goingFrom, destination, goingVia, arrivingMessage);

  // Broadcast the Leave and Arrive Requests at the appropriate respective locations.
  actor.Parent.OnMovementRequest(leaveEvent);
  this.Parent.OnMovementRequest(arriveEvent);
  // If neither the leaving nor arriving request are cancelled, move the actor and broadcast the events.
  if (!leaveEvent.Cancel && !arriveEvent.Cancel)
  {
    actor.Parent.OnMovementEvent(leaveEvent);
    actor.Parent.Remove(actor);
    destination.Add(actor);
    this.Parent.OnMovementEvent(arriveEvent);
  }
  return false;
}

All in all, I bounced between having a single MoveEventArgs and the dual events and settled on the latter which inherit from a MoveEventArgs; if something wants to react to a thing leaving, or a thing arriving, independently, that should be easy to do IMO. (ed. 2021: yup, we do that now with LeaveEvent and ArriveEvent which are both MovementEvent.)

So the cardinal movement commands ('move east' or 'east' etc) look for a MovableBehavior on the sender.Entity for performing the Move itself. I haven't done it yet, but exits will just be Things with an ExitBehavior and get targeted by the 'move' command; 'east' would be its ID so the targeting mechanism would find it, would find ExitBehavior, and from that get its linked place (generally being a room). (ed. 2021: actually exits use Contextual Commands now.)

The 'enter' command is similar. Find the sender.Entity MovableBehavior first to see if it can move, finds the targeted Thing and its ExitBehavior, then reuses the same Move method with its own sensory messaging like "You enter a portal" rather than "You leave to the east".

Going back to the cancellable events, one issue I had when thinking about this a while ago was that the order events are processed by entities is important if entities can start to modify the event such as making it cancellable. ie something might want to cancel a close door event but something that might keep it open has already been processed. Should the already processed "reactor" get another go at reacting?, which wins?

There is also a context issue, should things reacting to events also know about other things reacting to the event so that they can alter their behavior dependent upon what else is in context?

As long as we don't try to support the idea of 'uncancelling' an event, and keep a fine enough grain of individual events, I think this can work well. We want to keep this simple; no 'reactor' to cancelled events, no fighting to uncancel a cancelled event, etc...

Perhaps a cancellable request should probably be sent to all registered receivers at time of broadcast, whether the request has had Cancel=true or not; it is up to the receivers to decide if they behave differently based on whether it has been cancelled or not. An example.

1. Let's say the player is trying to 'move east' via a Thing which has both an ExitBehavior and an OpensClosesBehavior (IE behaves like a door).
2. There is also a mobile here with an AttacksMoverBehavior with properties which specify the east exit as the only exit it is blocking.
3. The leaveEvent above is being broadcast as a request via the OnMovementRequest(leaveEvent) due to the player's movement command.
4. The AttacksMoverBehavior receives and interprets the event, sets Cancel=true, and sends its own StartCombatRequest event. (After that resolves without cancellation, it will send its own StartCombatEvent too.)
5. The OpensClosesBehavior receives and interprets the move event, and sets Cancel=true (it already was, that is ok) because IsOpen is false.

So it doesn't matter whether OpensClosesBehavior knows if the event has already been cancelled, it just ensures the event does get cancelled while closed.

But the AttacksMoverBehavior probably cares; if the order of 4 and 5 were reversed such that the movement was cancelled by the door instead of the mob, perhaps the AttacksMoverBehavior shouldn't cause the combat. (The player tried the door handle, but didn't actually try to move through it?) Given the player intent, chances are the player sees "You can't go through it since it's closed right now" and then open the door and try to go there, THEN get attacked. So which order these behaviors got interpreted still doesn't necessarily particularly matter, even though sometimes the attack happens right away when the player clearly tries to move and sometimes it happens when the player would actually have an open pathway in front of them.

Minor detail and IMO both would feel correct to the user here. Maybe there are better breaking examples where order matters more.

but something that might keep it open has already been processed

As long as the events aren't trying to each represent a lot of different things in one go, this sort of problem shouldn't be possible. (Requests either get cancelled or not, they should never get uncancelled. E.G. something that wants to "keep it open" should Cancel the Request to Close it.)

There is also a context issue, should things reacting to events also know about other things reacting to the event so that they can alter their behavior dependent upon what else is in context?

I think with correct event design, a thing shouldn't need to know what cancelled an event, just that it was cancelled.

---

Actually I can see cases where one might be tempted to have events modify the non-Cancel parameters of the Request (NOT the Event). However I think those should be the exception rather than the rule, if employed at all, and known to be dangerous when employed; One example would be like soaking some damage from a combat damage event with a DamageReductionBehavior or whatnot subscribing to CombatDamageEventArgs-based requests. This heads into dangerous ground though since if anything else modifies the damage, the (unpredictable) order becomes very important for math reasons (subtracts vs percentage multipliers etc); thus IMO such a thing should not occur through the requests/events, if it can be avoided, and such a CombatDamageEventArgs should only be broadcast with the final calculations.

(ed 2021: Alternatively, if we want combat damage modifiers to occur in response to combat damage events, the CombatDamageRequest could provide a collection that listeners would "add" their modifiers to. Then the combat system would see the CombatDamageRequest wasn't cancelled, but does have a list of multipliers and additions/subtraction effects to order as appropriate for the game system before applying them to the final result to be sent with the final CombatDamageEvent.)

Isn't order of event execution dependent on when they are added? Delegates are basically singly linked lists of function pointers, after all, or at least that was what I was lead to believe.
Maybe we should go to an EventCollection model...?

Relying on the order of processing would be error-prone. For example, take a mob and item which register to the same event. Let's say the mob is spawned, and soon after the item is spawned (and each registers upon creation of course). So the event is processed by the mob and then by the item. Then a player kills that mob (causing the mob to dispose, unregistering that mob instance from the event) and later a new version of the mob spawns, registering to the event. So now our order of processing is item then mob.

Order of registration is something we shouldn't have to manage carefully. Things ought to just work in a reasonable way, in either order. In most reasonable cases, I think this will come naturally.

---

So we have:

• Dead references
• References to an item that has been replaced.
• Re-entrant threading issues

One thing: Should we be reference counting/locking/semaphoring items we act on in events? If the KillItNowWithFireEvent event hits a mob and it has already been killed by the CrazyExGirlfriendEvent event, but they both hold the same reference to the same object and they both try to kill it, one of them may end up doing something "bad". How do we protect our event from doing something naughty to the memory space?

You've lost me. Where are the dead references? What do you mean by a "replaced" item? What do you mean by re-entrant threading issues?
There should not be multiple places implementing the same code. For instance, if a Thing can be killed, it should have a MortalBehavior or KillableBehavior or HasHealthBehavior or whatnot, which in turn has a method called Kill; this method raises the kill Request (which can be cancelled, IE if the thing also has a temporary ImmortalityEffect going on or whatnot), followed by the kill Event if it's not cancelled, after it applies the property changes which imply the base thing is dead. There should not be events such as "KillItNowWithFireEvent" or "CrazyExGirlfriendEvent" but if there is some effect or spell or whatnot which intends to kill the victim outright, the that code would check the target for MortalBehavior and call its Kill method.

To expand on that a little, having only one place where Kill is actually implemented is a good thing for reasons you raise; it is up to the Kill method to make sure it doesn't "do bad things" if the Thing is already dead, for instance. Nice, isolated, testable little package of code. :)

This spring, I wrote some code for the ROM codebase. It uses the same isolated "checks" inside its kill-command, that you suggest. In my opinion, this is a very intuitive way to handle things. :)

Good, this is exactly what I wanted to hear.

---

I like your example about the mob with BlocksMover behavior which cancels out the move east command. But how do you handle a player who has the sneak behavior? Shouldn't that cancel the cancel? What if events were pushed onto a stack in a certain order so that when they are popped off they have the ability to cancel or not the effect below/above them.

Sort of. Sneak shouldn't "cancel the cancel" directly. Yes, I agree there can essentially be a stack of events which inherently resolve in a deterministic order; we need no special priority logic nor extra information in the events themselves. Simple events, here's how it could work:

• (Player enters the 'e' command which goes into the command queue.)
• ProcessCommandsThread: Command processor processes the 'e' command for the player. It finds that there is a registered context command for 'e', being the ExitBehavior of an exit Thing in the room. Calls:
• ExitBehavior.ProcessCommand: Raises the MoveEventArgs-based request. Among the event (request) handlers is:
• BlocksMoverBehavior.MoveEventHandler:
  (on a mobile in the room) Sees that the request is indeed for a Thing in the same room as it, so it raises a new BlockMoverArgs-based request. Among the event (request) handlers is:
• SneakingBehavior.BlocksMoverHandler: (on the player who is in sneak mode) Sees that the BlocksMoverArgs-based request is indeed targeting the behavior's parent, so some sneak-detection logic is run here: Maybe the BlocksMover request's sender does indeed have a SensesBehavior so a sneak-detection-chance is rolled against the blocker's relevant senses or whatnot; the result indicates that the blocker did not perceive the sneaker, so the BlocksMoverArgs-based request is cancelled.
• After that, the event stack starts resolving; the sneaking successfully cancelled the BlocksMover Request, so no BlocksMover Event is sent, so the MoveEvent Request is not cancelled, and the player successfully moves (sneaks) through.

Note that each piece is self-contained; since we resisted the 'quick fix' of adding sneaking logic into the BlocksMoverBehavior and instead ensured that it is also using proper eventing to indicate what it is trying to do, we've successfully added sneaking behavior exactly where it belong: only in the SneakingBehavior. As an added benefit, other things could now listen to the BlocksMover requests/events should they want/need to going forward.

With the above, we could also implement sneak as a command rather than (or in addition to) a toggle, IE 'sneak east' would add the SneakingBehavior, attempt to process the 'east' command, and then remove the SneakingBehavior.

---

[May 2009]

Here are some snippets from related direct conversations that were migrated to forums for future reference:

I can make a sensory message, how do I pass that onto an entity?

The sensory message is broadcast to the room, then each entity in the room either sees it or not.

To the room?! yay... that's the best solution I could think up.

Yes, sender's entity's location == room ... so room.EventBroadcaster.Broadcast

okay...cool...
I used entity.Controller.Write before...which is direct text to their screen
...a entity.Senses is exactly what I needed.

Yes, broadcaster is clearly better.

So, i'm probably going to make a sensory event to be able to be fired off
or, should there be a YellEvent?

GameEventBase by default has an associated sensory message, but... actually, lets make a YellEvent. This way, if we want to expand things to say, react to yelling, it is simple. Maybe a mobile has a reaction to yell events but not other sensory messages.

What about...combat? Gives off sounds, could have it leave a persistent sensoryevent in surrounding rooms. New entities are told "you hear combat coming from east".

That's a cool idea. Would we want that to still be an 'event' at that point?
Or maybe another object that contains the event/sensory info? Don't know yet.

Seems like rooms are where the eventbroadcasters are located

There is a world broadcaster too, probably an area broadcaster. PlayerManager.world.EventBroadcaster.Broadcast.

Right - sorry, that locations are the eventbroadcasters. Should an item be one too?

Yes. Actually every Thing is now going to have an EventBroadcaster which relays to its SubThings and Behaviors.

...ok i just saw area broadcaster, that's there. so an area reset event or area-wide events or whatnot could send to the whole area.

I was thinking of using that for adminyells. erm, admin yells - no need for all the doors to know that an admin is telling people stuff

Yea, the world broadcaster would be good for that, or a flag to yell the current area.

Okie... so, you think a yell event is better than using the baseEvent?

Yes, because it is more prepared for future OO uses.
Let's say we want a mob to attack someone who yells from their room.
They just check if (receivedEvent is YellEvent) attack player
etc... so ya, even if it gains no additional functionality i think it can make sense.

Instead of digging through the string...check.
Just afraid we'll have a smell event, hear event, see event, touch event, see in dark event, etc.

Well, that's what the SensoryMessage part is to abstract away the type of sense needed from the event?
So if we have a SocialEvent is a good example, the SensoryMessage part of it is highly sense-dependent, but the event is not.

Right, but if we're abstracting away just a yell, someone might abstract combatSound and waterFall sound

I dont quite follow; CombatSoundEvent?

On my previous example...
If combat is in one room, attached rooms might have a 'you hear the sound of combat'.
Powerful magic explosions, quite loud, if we want a mob to react to that, do we make an event for that - just like yell? Or, try to shoehorn everything like this into a solitary SensoryEvent.

I'd say err on the side of too many shallow events, since they're more OO.
(By shallow here I mean classes that do little more than inherit.)

Okay, that's potentially more code upkeep, but I can dig it

Ya, true, but at least they're likely to be seen by anyone making sweeping changes.

What if we have a guard that responds to yell, but, not to combat explosions? or normal says? Because he's only listening for YellEvents instead of SensoryEvents, type Sound

Ya but if we had SensoryEvent that was 'praising the mobile' why would we have him attack the player?
So if we added string parsing, the coder is still just as likely to scan for 'yell' formatting and forget 'say' formatting.
Plus things can then be spoofed; what if a clever player formats an emote or say that fools the AI into attacking a differnet player?
String parsing would be down-right ugly.

Right, I'm not talking about string formatting anymore... but, more of a general SenseEvent.

Are you thinking that maybe some Events should not have SensoryMessage part?

No...an Event that is only a SensoryMessage part, essentially.

The base event is little more than a sensory component, plus some context.

Right now we have move, attack, openclose, etc... I'm recommending a SensoryEvent.

I can see maybe a CommunicationEvent that yell and say would all either use or inherit from. Build a nice tree. Then the reactions could be to all communication events or all environment events or all combat events etc?

So, CommunicationEvent : BaseEvent. Yell : CommunicationEvent.

Im just thinking 'sensoryevent' is either fairly redundant with 'baseevent', else it is not explicit when to use it or when not to use it.

GuardMOB.... if(event is CommunicationEvent)

Ya that would sit well with me.

SensoryEvent is redundant, but prevents extra code by figuring out if the ambiguous baseEvent is intended to only be sensory or not.

[ed 2021: I'm not sure how many events won't have any sensory component - perhaps if something like "game ticks" wanted to be a broadcast event... ATM all of our events, even the base GameEvent, has SensoryMessage as a constructor arg... Filed #142 to investigate.]

[DavidRieman]

[May 2009 continued]

You guys are making it a lot more complex than what it was intended. Eventing is a generic mechanism to send messages to the various objects in the MUD.

I totally agree with the current setup, now that I know the way it's laid out in code... I had some ignorance-based frustration early on. :)
Perhaps you can recommend how I would redo the Yell Action?
Currently, it's a string passed to entity.controller.Write.
I'd like to make a SensoryMessage so anyone who can 'hear' will hear the Yell.

I'd like things like... a rotting corpse gives off a strong death smell. Some MOBs might go towards that.

• Combat sounds to be heard from the room(s) over.
• Large magical explosions to be heard far away.
• MOB cries for help to be heard by nearby MOBs that care, etc.

Would you not recommend using the current system for this?

I also think some events should be able to be placed into a room and stay either indefinitely or for a TimeSpan.

• Waterfall in a room, the immediate rooms should have a permanent event that triggers to new entities that enter the room = you hear a waterfall in the next room.
• Desk is on fire, the immediate rooms should have a Smokey view and a fire smell event for say, 20 minutes.

For the TimeSpan things, what you're probably looking for is code that creates an Effect, like an OnFireEffect. But propagating some aspects of that Effect into adjacent room descriptions rather than periodically broadcast messages and such (which could get repetative if you're parked near by) - may need further discussion / ideation.

... didn't get to the persistent sensory messages. So the chain would be Event --> Sensory Message --> Persist Sensory Message.

Ah, attaching a "persisted" sensory message to adjacent rooms with "you hear a waterfall..." or whatnot, and have PerceivedRoomRenderer process those for the player? (Then force removal from that list when the water is done rushing, or the fire extinguished? In addition to one-time sensory messages detailing the change? Seems a feasible route.)

[ed 2021: Seems more evidence we may want some sensory events to have a reusable system to cascade some details across adjacent rooms with dampening, and maybe a similar reusable system for Effects to temporarily cascade room description details as well.]

What I want is to steer people away creating a giant family of events. I have been in RL life projects that had an enormous amount of typed events. I'm talking north of 300 system events. That was for a CRM type app for the Airline industry. Gosh, that was ugly! I'm not opposed to more events. I just want us to think about how they will fit in the overall picture. The best rule of thumb that I can come up with, is to try to reuse an event, before creating a new one. But who knows? Until we experiment some more, we won't know what works where.

The situations you described are exactly what this system was created for. I'm taking my cue from biological systems. Mother nature has a lot more experience than I with those, so I thought I take her lead.

[The SensoryMessage is a good way to do Yell, and the current system is a good way to do those 3 bulleted examples.]

Sure, if we want to limit the number of shallow classes, it might make sense to have a BasicSensoryEvent which nothing more to the BaseGameEvent other than an enum which gives additional info. Thus Yell could make a new BasicSensoryEvent(BasicSensoryEventType.Yell, ...) and then any reactions to the event added in the future that really do care if the BasicSensoryEvent was a yell can check the assigned enumeration. :)

(Ideally the BasicSensoryEventType could be easily extended with more values from future extension libraries that are unlikely to be duplicates with other extensions.)

This is actually a MUCH better solution. I like, I really like it! Make it so.

I was trying to lead you to something like this during our conversation.

---

I think there are some fundamental issues with our current event model, the primary one being how chatty it is. The default event broadcaster is the room which is fine, but if you need things outside of your location to respond to an event you are stuck with using the Area or World broadcasters which could send your event to thousands of different items which is going to get very laggy very quickly.
I would like to see some form of Publisher/Subscriber model (as well as our current broadcast model) to help cut down on chattiness as not every item is interested in every event.
A couple of ideas that I feel we should support so far are:
System should be able to deal with:

• Specific events such as Item1234 respawn
• Generic way to subsrube to a group of things events ie when any player logs in.
• Need to deal with the fact that a specific object that is being subscribed to might not actually be in memory at the time.
• Generic way to subscribe to a all events from a specific thing ie I want to know about all events coming from something

What if we make the managers publishers, as well as their current job? The ItemManager, could broadcast 'item1234 respawn' - so, things that care can subscribe and unsubscribe to a specific manager? Each manager could have several things to subscribe to... respawn event, destruction event, sell/buy event, etc.

This can all be hooked up in the base-class level, and just be overridden if a derived class actually cares.

It could be a responsibility of the Managers yes, that could be a good solution. I cant think of something that you would want to subscribe to that doesnt have a manager.
The managers would have to maintain a lists of each subscriber and what type of event they are subscribing to.
Im thinking about API now, something like:

ItemManager.SubscribeTo("item1234", { ItemEvents.Respawn, ItemEvents.Destroy })
ItemManager.SubscribeTo(Items.All, { ItemEvents.Respawn, ItemEvents.Destroy })

---

[May 2009]

Event Pub/Sub Model

Problem
Our current event broadcast system is quite limited, you can send events to the current room you are in, the area you are in or the world and furthermore every single Thing within scope will process the event, so if you send to the world that could be thousands and thousands of things processing an event.

It would be good to have a system where a thing ie a player can subscribe and unsubscribe to events that they want to see and not receive all of the irrelevent events.

Solution

The EventBroadcaster functionality is to be moved out of the location classes and into an EventManager class available through the CoreManager. A thing will be able to subscribe to events in a number of ways:

• To a specific event on a specific Thing ie item1234 respawns
• To any type of event raised by a specific Thing ie all events raised by item1234
• To a type of event raised by anything ie All death events
• To any type of event raise by a type of Thing ie All events generated by a player
• To a type of event raised by a type of Thing ie All player death events

One of the responsibilities of the EventManager will be to make sure that subscriptions of out of scope Things are reactivated when a Thing comes back into scope ie when Item1234 respawns then all subscriptions for this item need to be reactivated.

I feel that it is still valid to keep the room broadcast functionality but make it the responsibility of the EventManager class to pass the event to the objects in the originators current room rather than the room itself. Area and World events will no longer be required.

Functionality to propogate an event to other local rooms should also be supported ie move this functionality out of yell. A developer should be able to set how far they want to send the event and maybe even supply a custom "deterioration" implementation.

Subscriptions need to be able to persist across World resets.
A thing should not receive the same event more than once.

From a game-design standpoint, this'll rock.

There's a few things I still don't quite understand about the intents here.
Any time an event that is appropriate to broadcast just to the current room happens... Does the EventManager have to iterate the thousands of subscribed things to figure out which subscribers are in the originator's room? Would a heirarchy approach work here, IE if a mob in a room cares about a certain event, they subscribe to that event with their immediate parent (the room), which then (if it doesn't already subscribe the event), subscribes to the event from the area, and so on? The chain would have to be adjusted whenever an entity moves, dies, etc, but since each maintains a list of its subscribers, it's a simple matter to know if any sub-subscribers remain for an event, and if not, unsubscribe from the parent? Meh, maybe that's too complicated.

At the very least we can dictionary the Event type to a list of subscribers of that specific event type, and thus eliminate most redundant searching. For a moment I thought we might want to special case BasicSensoryEvent to have a dictionary of each of it's subtypes, but I think those are generally the kinds of things that only broadcast to one (or a couple) rooms. IMO the vast majority of our events (CombatDamageEvents / PlayerEnteredRoomEvents / SkillEvents / SpellEvents / SocialEvents / etc) are going to be broadcast to just the current room.

Next, would this be tying into the proposed "broadcast a request" paradigm? I think an example of intent there is that a player broadcasts a "RequestMoveRoom" event to go from one room to another, but the door in the way is subscribed and decides to mark the request as denied somehow since the door knows it is closed. Similarly, a "guard mob" could react to a player's attempted movement by marking the request as denied and saying "Nuh uh, you're not gettin' near the boss while I have anything to say about it!"

Oh, what do you mean by suggesting we persist events subscriptions? If a mobile has a need of subscribing the event in the first place, they already need to do that whenever they spawn the first time, including when the MUD comes back online? Maybe you mean we should be able to attach a list of reaction scripts/behaviors to a mobile, which should be persisted the same way an item's Behaviors would be persisted. If a specific Behavior (like BlockPlayerMovement with a property that has a room ID, to implement the guard mob above) is attached by an in-game builder to a mobile they are designing, then that base mobile's Behaviors list gains a new Behavior which persists with it; it would be the construction of the Behavior that would subscribe to the necessary events, and the builder wouldn't have to do with such internals; the coder of the Behavior would put the appropriate Event subscription in the constructor, and rig it to a method. For the BlockPlayerMovement example, the coder would subscribe to RequestMoveRoom events, and upon their callback method getting called, would check the Event's intended target room (that the player is trying to go to) against the Behavior's target room (being the room the mobile is blocking entry to), and if they match, deny the request and maybe say something or attack the player, etc, according to other properties of that BlockPlayerMovement Behavior instance.

I completely agree that iterating over a list of subscriptions to find those interested in the event would be nuts. I was thinking about a number of dictionaries to lump interested parties together would do the trick. I began implementing this in EventManager if you want to take a look.

I have thought about the pre event event thing before and I like the concept, the only issue I have with it, is if something stops the event from happening by setting a flag on it or whatever what picks this up and is responsible for stopping the action from occuring or conversely is responsible for the action happening? I'm not saying that it is not possible, just that it requires some design.

Having thought more about this during my commute home, I think you are right, there should be no need to persist subscriptions, so long as the things that generate the subscriptions are persistable. ie if a player drinks a potion that allows them to suddenly find out when items respawn into the world then so long as the effect that the potion creates (that in turn creates the subscription) is persistable then there is no need for the subscription itself to be.

Yeah, we should discuss Effects and Behaviors themselves in another thread.

I have checked in an update to this today. The code is a bit messy at the moment, but it is pretty functional, most of the subscribe functionality is now working, the unsubscribe isnt yet.

You can subscribe to event types on a type of object ie player.loggedOut. You can subscribe to event types on specific objects ie bob.loggedIn. You can subscribe to all event types on a type of object ie all events generated by player

It automatically handles room events.
You can't yet subscribe to all event types on a specific object or to a specific event type generated by any object.
It broadcasts events down through a heirarchy, moving from more specific functions to general and finally broadcasting to the room.

The old room broadcast functionality has been turned off however not removed from the code base yet.

I created a sloppy command called friends that allows you to add friends. When you do, it subscribes you to their specific PlayerLoggedOn and PlayerLoggedOff event, giving you a different message from the standard. The callback used here is an anonymous method which is not ideal and I think we need to have a discussion about how we are going to manage the specific call backs.

[ed 2021: Subscribing to the specific Player didn't really work well versus persistence. It could be made to work but would be awkward reconstruction edge cases that aren't worth it: In the end, the only "listeners" need to be "players" who are allowed to designate a list of "friends" and so a case like this really had a good balance of low complexity to minor perf impact to just broadcast a player login to all listeners of a global event - which would just be the current players. For a couple hundred players to check if that login player is on their friends list, is not worth trying to micro-optimize with risky complexity. It seems like anything we think of that might feel like "broadcast to the world" issues are actually similar - things like admin echoes to the world actually mean broadcasting echos to players via something like Player Manager instead of cascading an event down from the root world Thing. So yeah, in short, today we have both "specific global events" and "broadcast room down" as the most common eventing patterns to be used.]