1.1 Name: Defining VR Space with Events
1.2 Author: J. Brewer (heartwood@members.limitless.org)
1.3 Purpose: describe how events can work to generate various descriptions, messages and the simulation of different environments (formerly the concept of roomtypes).
1.4 Creation: April 23, 2004
1.5 CVS $Id:
1.6 Change history:
1.6.1 4/28/04 - Brian Jones changed <> signs to their proper < and > in the object example below (the page caused an attempt to load an object, which failed, and mangled the interpretation of what was below). This was purely a mechanical change and involved no content modifications.
2.1 see Core Concepts
2.2 see Places Explained and Events Explained
2.3 MUCK discussion between Otter and Rosella, 4/23/04, and various e-mails
This document puts together some of the concepts already discussed to explain how events work within places to give them their VR "shape". Specific instances include the viewing of place descriptions, "external" events such as weather and the simulation of environments such as indoors vs. outdoors, water, sky, outer space, etc.
In NMC1 rooms, the only visible part of a room was its inside. NMC2 uses objects as places and both the inside and the outside are visible to the character. This is explained in more detail within Places Explained.
Roomtypes were an NMC1 concept that never quite got off the ground. FB MUCKs had indoor and outdoor "parents" long before NMC had regions which was the closest thing to roomtypes there ever was. NMC1 region parenting had IC and OOC by default and could have theoretically been extended to include things like the sky, but the plan was to implement roomtypes as its own system in the DB core.
Roomtypes were a proposed way of distinguishing between different types of IC environments such as sky, water, underground, indoors, outdoors, etc. Having any particular type set on the room (as a property) would control certain events within that room. For example: Birds could enter the sky and fly in it but land dwellers would be locked out. Weather (another NMC1 plan that never got off the ground) would be perceived differently in an outdoor room than an indoor one. The ability to do this properly is a much desired feature in NMC2.
But in NMC2, taking this system as it is would create a problem. Refer to the tavern example in Places Explained. If the tavern were built in NMC1, the roomtype would definitely be "indoors". But now our tavern (the part that contains the common room and the booths, definitely "inside" places--but the tavern could also have been built as a single place) has an interior on the inside and an exterior on the outside.
Therefore, setting the tavern object with the property "inside" would be rather paradoxical.
Properties are no longer limited to the interior like they were in NMC1. The outside matters too. A section of outdoor place in NMC2 would be "outdoors" internally and "outdoors" externally. One wouldn't think the exterior of an outdoor place would be visable...except it is, if you can view it from a distance. It's external description might be "that clearing in the distance" or "that pond in the distance".
Making sets of properties for both the interior and exterior of an object, in the case of something like roomtypes, would be a major pain. So setting a "type" on a place makes for a very poor model. This is where event handlers come in.
For an explanation of what event handlers are, see Events Explained.
Let's start with the sky. You want a sky where only characters and vehicles with the ability of flight (birds, airplanes, etc) can enter it.
You create an event handler--for the sake of humor, we'll call it "gravity". When a character issues a command or commands a vehicle to enter the sky, gravity checks to see if they can fly. (As of this writing, the manner in which character abilities are established has not yet been determined). If yes, the command triggers a move event, which triggers a series of message events (appropriate success message events and a look event so the character "sees" the new place they're in). If the character or vehicle can not fly, the appropriate "fail" message events are triggered and gravity keeps them firmly planted on the ground.
Weather events are generated in the sky and broadcast to any players down below. Let's say a good thunderstorm is brewing up; it gets windy and rainy and there's thunder and lightning.
Anyone standing outside in an open area sees all weather message-events that the storm has to offer. You get wet, you feel the wind, see the lightning and then hear the thunder. (Getting thunder to follow lightning properly would involve setting the "thunder" event be triggered by a "lightning" event; also, have that event broadcast "travel" through the surrounding places for the proper delay effect.) How they see them will depend on what the builder of that place wants you to see; weather messages would therefore be tailored to be appropriate for the place.
If you're inside, the event handlers with you indoors will give you a different set of messages, again, tailored to the place. You won't feel the rain or the wind, but you may hear them, or see them out a window if one exists. If you're deeply entrenched in an inner room with no sights and sounds coming in from the outside, the event handler there would not deal with any weather events.
What if you're in an in-between place, like standing under an awning? You might see the rain and not feel it. But you would definitely feel the wind and hear the thunder. In this case, the builder enacts the event handlers for wind and thunder but uses a filter for the rain.
"look" in its most basic form (a player giving the command "look (object) to its character) simply sends a description as a message event to the player. Look events also occur when a player moves into a new place.
Want to see where you're going? Easy. "look <object you're moving toward> will give you the external description of that place.
Want to look out a window? That's more complicated, but doable. The builder sets an event handler that tells the window which places it ought to receive events from, and might set another handler to receive only visual events (descriptions and the poses of players...assuming that the system has a good way of separating visual and auditory message-events from players, which is currently a requirement.)
A quick "look" out the window would cause the message events (description), (things_in_place), etc, to be broadcast to the player.
But why not be able to "watch" out the window? Now we have an event handler that can be set on a character, that the character can turn on and off. Turning "watch window" on would first send the same events as a "look" out the window would, then continue allowing the player to receive events as they happen until they issue the command to stop watching.
With an Event Policy.
An event policy is just a list of event handlers, in the same way a security policy is a list of what can and can't pass a system.
Builders can make an event policy, save it, then use it across their area. Admins can provide desired policies for players to use as available defaults depending on the genre/system, or restrict the use of policies they don't want (but by default, anything goes). The NMC development site would probably spawn an area for players and admins to upload event policies they've created so those who are less willing to deal with making their own can choose from pre-built stock. Take an event policy someone has made for "sky", tweak as necessary, apply it to all your sky rooms, and you have instant gravity.
These will likely be added over time.