CthulhuMud - Events

An event is an encapsualtion of something that has happened within the mud. Events consists of a description of the occurance combined with the context that the event occured within.

Events are routed to all mobs in all involved rooms, all mobs monitoring those rooms and maybe some objects. Eventually the events wind up at mobs who view them and react to them. Players are shown the text within the event that is relevent to them (this is primarily how they receive all of their successful action notifications). Mobs pass the event through triggers, which may cause the mob to run a script in response to the event.

Information Contained in an Event

Each event contains the following:

event type (integer)

This indicates the general nature of the event.

event subtype (integer)

This is a more specific indication of the nature of the event.

event context (context)

This contains details of the mobs, objects directions, location and other things involved in the event.

actors message (string)

This is a text message, with substitution parameters, that should be sent to the actor. It will only be formatted and sent if the actor is a player.

victims message (string)

This is a text message, with substitution parameters, that should be sent to the victim. It will only be formatted and sent if the victim is a player.

observers message (string)

This is a text message, with substitution parameters that should be sent to everyone observing the event who is neither the victim nor the actor. It is only formatted and sent for observers who are players.

The master numbers for event types and subtypes are defined in the wev.h file.

Event Routing - Challanges and Reactions

Generating Events

Events are generated by things happening, generally mobs trying to do things.

When a mob attempts an action, its parms are processed and resolved. A context describing the involved parties and the parameters of the action is then created. An event is then created, based upon the context, but adding the event description and the messages. The event is then issued as a Challange Event.

Challange Events

At this point the action described has not happened and if any mob in the room (or monitoring the room) has a challange trigger which matches it, the action will be denied. That is to say that the action will not occur and the command processing will simply end.

It is up to the mob whose challange trigger matched the event to run a script and provide an explanation to the player of why their action was disallowed. The MPSTOP command can be useful here.

Action

If action was not denied it will now occur.

The event will then be issued again, this time as a Reaction Event.

Reaction Events

The reaction event describes the completed event and will be sent to all mobs in the room (and who are monitoring the room). Players will be sent the appropriate formatted message, while mobs get to run the events through their reaction triggers to see if they want to react to it.

Exceptions

There are, of couse a number of exceptions to the above flows.

• When a character arrives in a room, there is no challange event. A mob in a room cannot stop a mob in another room from entering their room. There is a challange event for the departure of the mob though.

  This arrival reaction event is in addition to the depart reaction event that was issued in the rom that the moving mob left.

• Time and pulse events are sent directly from the update() code to the mobs who wish to receive them. They are not routed through rooms.
• OOC communication events are sent directly to to the players concerned, without any routing through rooms or mobs. Mobs cannot react to OOC communications.
• Wide area IC communication events (Shout and Scream) are routed to all rooms (and all mobs within those rooms) where they can be heard. This allows mobs in those rooms (or monitoring those rooms) to hear and react to those events (but is fairly expensive CPU wise).
• In combat the attack event is only issued as a challange, mainly to reduce message clutter. It will always be followed by another combat event that describes the result of the attack.
• Death events are issued reaction only. It is not possible for a mob to deny someone permission to die.
• If one of the objects or actors would be destoryed by the action, the distruction is delayed until after the reaction event has been processed. This lets mobs and players examine the thing being destroyed.

Example Event Flows

In this example a character (Chen) walks into a room containg a mob (Orc) whom he then attacks. He injures the Orc, parries the Orcs blow and then kills the Orc before looting and sacrificing its corpse.

The events generated are:

1. Arrive, walking, Chen
2. Look, room, Chen
3. Look, mob, Chen, Orc
4. Combat, attack, Chen, Orc (challange only)
5. Combat, hit, Chen, Orc, 35
6. Damage, hurt, Orc, Chen, 35
7. Combat, attack, Orc, Chen (challange only)
8. Combat, parry, Chen, Orc
9. Combat, attack, Chen, Orc (challange only)
10. Combat, hit, Chen, Orc, 42
11. Damage, hurt, Orc, Chen, 42
12. Damage, injured, Orc, Chen, -12
13. Death, slain, Orc, Chen (reaction only)
14. Get, item_from_container, Chen, Sword, Corpse of Orc
15. Get, gold_from_container, Chen, Corpse of Orc, 25
16. Sacrifice, npc_corpse, Chen, Corpse of Orc

The damage, hurt events are issued when a mob takes damage greater than 25% of its hit points (the number is the ammount of damage the mob suffered). The Damage, injured events are issued when a mob has less than 25% of its hit points left (the number is the number of hit points the mob has left). Not that for these events 9and the death event), then actor and victim roles are switched from the attack that caused the wound. This is because the acts here are being seriously injured and dieing.

Performance Concerns

Yes, this is a lot of work. But it runs very efficiently, being mainly pointer manipulation and integer comparisons. The triggers and scripts are considerably more efficient than many other mobprog implementations (no interpreted progs to parse). Memory thrashing is avoided by reusing the same blocks of memory over and over. Typically the entire mud will have only ever allocate 2 or 3 event or context structures.

It gets expensive when:

• Wevs are sent to lots of rooms or a room contains lots of mobs. Shout and scream are (at the moment) the worse for this, although some of the wide area echo commands may be worse once they are converted.
• Mobs with triggers that check the text associated with the event which are placed in rooms where a lots of such events are generated. An example might be a mob which responses to a character saying something IC being in a room where players traditionally hang out and idly talk together. In general text based checks are much more expensive than integer or pointer based ones.
• People with bad language skills participating in IC conversations. This is because the text message formatting routine will run garble code on what they say for every recipient (with the amount of garbling depending upon the skills of both the speaker and the listener).