I'm having trouble following this. Where does the scope object exist? How do filters find it in order to subscribe to specific events? How do events find it to notify subscribers? Aren't these scope objects redundant given the existing room/zone/world objects?

In any case, I'm not concerned about the scalability at this time. In thinking it over, an event is going to run through the filter chain of the object that caused the event, its peers, its parent, and possibly children and grandparent. As mentioned earlier, this is roughly the same number of object iterations involved in the "look" command, and objects will typically have empty filter chains. I'm comfortable with implementing the brute force approach for now.

It's a generalization that would let you do things like have a scope for all outdoor rooms in a zone. Basically it decouples the notion of event scope from physical location. You might have a scope for all characters in a clan, etc.


How will you implement zone-based event filtering?

Let me re-phrase… The source of an event/trigger (discussed so far) is a mob/player. Its parent is the room, its peers are mobs/players/items in the room, its children are equipped items, and its grandparent is the zone. A filter attached to the zone can process events/triggers generated by mobs/players in the zone.

I'll give scoped subscriptions a bit more thought, but don't have a clear enough view of the solution details at this time to tell whether it would be worth the effort.

So when you talk of zone event filtering, you mean that the zone itself is doing the filtering, and not some object in the zone. For example, you would never want to have characters that care about all events in the zone they're currently in. (Such a thing would be very expensive under this scheme because of having to do the full broadcast etc.)

If the total universe of interested potentially parties is exactly limited to entities in the same room, the room and the zone, then I would agree that the iteration is more or less the same as a 'look'. I would still worry about how "verbose" your events are, especially if things have pre-/post-processing, but your universe of recipients is not terribly big. What I would argue in this case is that the event system is limiting itself – you cannot (efficiently) have entities in other rooms or even areas respond to events.

Yes, that's the current set of entities for the given triggers/events discussed. While I agree one could expand the pool of entities into adjacent/nearby rooms and potentially across zones, I can live with the limitations and don't think it will be much of a constraint on developing content.

So having gotten the mechanics out of the way, the original question was whether the two types of events (attribute updates and command actions) pretty much cover things. I did happen to run across this…

http://www.valhalla.com/vmeinf/index1.ht... <- click on "Dil explained, then dil.html, then Messages:"

…which has pre/post command, death, timer, and combat triggers. The death and combat triggers can be covered by an attribute update to health. The timer trigger seems a little out of place in the context of this discussion. It's more of a mechanism used by a stateful behavior rather than a filter.

Death isn't really an update to health: it is the result of an update to health. I still think that your system should be fairly agnostic about the details of events, and simply be a system that manages events, in addition to modification and potential interruption of said events.

I'm not sure why you don't think a timer is appropriate, but perhaps it's because you're thinking very closely of modifying events as opposed to the events themselves. First you talk about events (attribute changes, commands happening) but then you reject timers because they're not filters. Not sure what distinction you're drawing here.

If you have a nifty event system, why not use it for timers?

I personally can't think of even a single reason to have entities in other zones respond to events. The model I use it pretty simple:

Events are broadcast to a room. They are thus broadcast to every actor (player/mob) and object in the room, which broadcast to their children (actors' equipment, objects' contained items). The event is also broadcast to the room object itself and to the parent zone (so zones can have interesting behavior for events).

If I ever bother to fully implement the link/portal system I want, then events would be broadcast across portals (based on event details and the portal event filter – e.g, if the portal represents sound-proof glass, then events with a VISIBLE flag would be broadcast across the portal, but not events that had AUDIBLE without VISIBLE.

You need a sane and useful scope for events. Broadcasting to any interested entity in the system is essentially useless. In a MUD, you have very clearly defined boundaries for events in the way of rooms. MMOs likewise don't deal heavily with complicated subscription/filter system but instead worry about determing which entities are close enough to the broadcaster to be able to receive them.

In the rare cases where an entity's events must be reacted to independently of where the entity is, just attach an event responder to the entity itself. e.g., instead of saying "Guard A responds to anybody who chimes the Bell of Save My Ass" by attaching an event handler to the guard that reacts to any Bell in any zone, instead attach an event handler to the Bell that sends a message to the Guard via MNUM/MTAG/whatever lookup. It's not as academically "correct," but academia doesn't matter in the least compared to practicality and actually making things work in an easy to manage system.

So having gotten the mechanics out of the way, the original question was whether the two types of events (attribute updates and command actions) pretty much cover things. I did happen to run across this…

http://www.valhalla.com/vmeinf/index1.ht... <- click on "Dil explained, then dil.html, then Messages:"

…which has pre/post command, death, timer, and combat triggers. The death and combat triggers can be covered by an attribute update to health. The timer trigger seems a little out of place in the context of this discussion. It's more of a mechanism used by a stateful behavior rather than a filter.

If you consider zones to be completely self-sufficient, and consider that removing a zone has no effect on other zones, then sure, I can see why you'd never have inter-zone event handling. We use zones more as organizational tools than as self-sufficient entities, so we have plenty of inter-zone effects, and therefore plenty of reason for events to be processed across zones.

Factions are another good example: a faction might react to something happening to a member of the faction, so you would need those events to reach other members of the faction somehow. Pretty soon you end up potentially talking to the whole world again.


This is "good" only if you disregard the fact that it brings back all the various evils of hard-coding. While it makes it easy to handle one guard, it makes it difficult to have several such guards in several places, because you have to set up new event handlers by hand every time.

—

BTW, I think you forgot to quote/reply to one of Grimble's paragraphs you included in your post. :smile:

trigger == event
filter == event handler

I would add time or agents to triggers/events.

But to generalize it, a trigger/event may be generated from a state change, which encompasses
attribute updates, commands, passage of time and autonomous agents.

Not to be confused with the terminology of MobProgs/DGScripts which is I believe the opposite.
Triggers are event handlers. And these triggers filter out events they aren't interested in.

I'd just add that TeensyMud implements this with pre/post filters. What it does is simplify the
event model, because a pre-filter is not really an event handler, it is a true subroutine that can prevent
the event from occurring. In a pure event-based system, event-handlers are always called "post"
event by a dispatcher that does not handle or care about the return.