1.1 Name: Places Explained
1.2 Author: Brian Jones brianj@otterspace.com
1.3 Purpose: describe the concept of places in detail.
1.4 Creation: April 21, 2004
1.5 CVS $Id: places_explained.html,v 1.1 2004/06/24 21:22:47 brianj Exp $
1.6 Change history
1.6.1 4/22/04 - Brian Jones adding the concept of place as being externally a visible object so places may be position within others and have an outside appearance. Prior to this, only the internal issues of places were addressed in this document.
1.6.2 4/25/04 - Jonathan Smith updating to newer terminology and concepts. Also, added the example "Hotel Nameless"".
1.6.3 4/27/04 - Brian Jones added engineering abstraction link.
1.1 email message on April 20th, 2004 from brianj@otterspace.com subject "Places and Relationships"
1.2 log from discussion on April 20th, 2004
1.3 See the Core Concepts document for definition of terms used.
1.4 See Engineering Abstraction for a discussion on how using more abstract ideas for places affects us.
Rosella and I had a long meandering discussion on 4/20/2004 in the lounge about places versus rooms.
Imagine a small tavern described thus:
+------------------| |-------------------------+ | | | | | | | Common | | | | | |----| |---+ +----| |------| | | | | | | | | | B1 | | B2 | | | | | | | | | +-------------------------------------------------+
The tavern is a place in its own right. From outside, you could point and say, "Look, there's a tavern." The external view of the tavern would be provided by the object as well. This is covered in much more detail later in the document.
Within it are two booths (B1 and B2). They, too, are places in their own right. From the outside, you could point and say, "Look, there is a booth."
Now, for some basic relationships:
So it seems like, at least for the purposes of description, the tavern really has three distinct places within it.
Now, this is a single room tavern (where the term "room" is the real-world concept of a building structure with walls). We can talk of things being "inside" the tavern or "outside" the tavern. Thus, there is some form of "distinction" between what is within and what is without. That distinction is what gives us the idea of place.
In fact, any time you take an area (imagine the infamous X-Y plane of mathematics for a second) and put any sort of marking within it, you can now talk about either SIDE of the barrier.
Places then are names given to distinguish one area separated from another. Places are only sensible when there's something MORE than a single place.
In a chat service, the "method of separation" is typically the channel. The channels "cleave apart" a single place into "different places."
Now, back to the tavern. There is clearly an "inside the tavern" and "outside the tavern." The tavern walls _make a mark_ that separates the inside and outside.
Within the tavern, the booths provide distinct boundaries. They don't happen to provide walls, but they provide an "inside the booth" versus an "outside the booth." The common area is "within the tavern" but "not within either booth."
I believe there are four places under discussion: the tavern, within the Tavern, inside booth one, and inside booth two.
To describe the places directly, it's convenient to draw a "node map" or what we'd call a State Transition Diagram or Statechart in the software business.
Node-map:
Tavern contains ( INSIDE, B1, B2 )
OUTSIDE <-> INSIDE
^ ^
| |
B1 <--+ +--> B2
One could argue that the tavern and inside the Tavern could be merged, but I don't think that's wise. Because there is a FIFTH SPACE I didn't mention: the outside of the tavern.
Inside the Tavern contains the booths, but it is still within the tavern, as are the booths.
The trick for our MU isn't to say "Thus, any building will have inner places so that the union of these places are totally contained in the outer structure." The trick for our MU is to let our PLAYERS build the tavern of their dreams.
These areas would have a profound impact on how the tavern is used in play.
Anything happening outside the tavern would be "filtered" or "intercepted" and the tavern object would have rules that determine which events from outside were passed through to the inside. The rule might allow weather updates to propagate, but block people talking outside from bothering those inside.
In the same manner, anything happening inside the Tavern, also known as outside the booths, would be "filtered" or "intercepted"
Anything happening inside the tavern would be filtered before going out. Very likely, no event messages from inside the tavern would make it out to the outside.
Within the tavern, the event filtering rules become much more complex. Characters are "together" when they share a space. Thus, if there's a few characters talking in the common area, they would receive events generated within that common area. That's like a channel on a chat service.
The people in Booth One should receive "some" of the events from the common area. Which ones? It could be random. Or, it could be all the motion events (poses) but not the audible (perhaps the booth is science-fiction and has sound filtering?). Or it could receive "15%" (or some other creator-chosen setting) of what comes from the common. Or anything else decided upon. And the same rule could apply going the other way.
This is the same mechanism as events outside the Tavern reaching the Inside; however, different rules may be specified for the booths.
Notice that an event "passed through" from outside the tavern to inside the tavern would have to be, in turn, passed to both booths, because they are "in" the tavern. And events from booth one to within the tavern flow through a different boundary...because their relationship is "within" the Tavern.
If you'd like to try to carry the booth out of the Tavern, it might just work. It depends on the permissions, of course.
Since there's no traversal between booth one and booth two we might choose to have no message flow between them. Or we might say that message flow occurs between _siblings_, in which case the nature of the traversal doesn't matter. This is, again, the decision of the person who creates the tavern, not one we make in defining the game itself. Whatever they choose, however, we enforce it.
The illusion I sought to maintain (the "VR reason" for all of this) is that people in the tavern in booths are "part of" the general events, but only peripherally. They are clearly "within" the tavern, but they aren't necessarily subjected to the chatter of the people milling about in the common area other than as a "background drone" with an occasional loud remark intruding.
Meanwhile, the people entering the tavern from outside would see the people in the common, and would see that there are booths...but would have to look _into the booths_ to see who was there. The people in the booths might, on the other hand, see people who enter from the outside right away.
To summarize: The notions of place are used to control which events are propagated, filtered, or changed, as they pace through boundaries. They define the "loci" or centers of interest that enable characters to congregate and "be together." They are used as a means of organization.
The idea of the tavern object being externally visible also has a huge impact. Traditionally, in NMC1, there were two common ways of building a place like a tavern and having it linked into the VR map.
The first way was to build a "thing" object called "Tavern" and describe it with something like "You see a small tavern. Type '[E]nter [T]avern' to enter." Then the room the thing was in would have an exit named 'et' that was marked as invisible, and that link would go to the "room object" that was the tavern's interior.
The other approach was to skip the "thing" object and just build a "yard" or a "clearing" or some other external "room" object and include in the description the fact that a tavern is visible. Then have a visible exit in the room that went into the tavern's internal room.
In the case with the "thing object" for the tavern, the object had no real impact on anything inside the tavern. Looking at the object didn't let you 'peek in' the windows (though it could have if the object had sufficiently intense MPI). In fact, the only purpose for the object was to make a visible entry in the 'contents' list of the room. The approach that skipped the object didn't even go that far!
However, in NMC2, we have only objects (not 'thing objects' or 'room objects'). And a place is an object which allows VR within it. So, the tavern (as per all the above sections) was a place with three places 'nested' within it. But the outer tavern object is still an object. If it were dropped into a clearing (such as the one described in the section below) wouldn't it seem reasonable that it had a description of its own? Not of the inside, which is the domain of the inside, and its contents, the booths, but of the outside that people can see?
Buildings are objects which are visible from outside as well as inside. Look at an object (even a place) from outside it's boundaries, and you see it from the outside. Within the object, you'd see it from the inside. So, oddly enough, the NMC1/FB concept of "inner description" and "outer description" for "thing objects" seems to make incredible sense. But now, with the ability to nest places, we know which places expect to be seen from which side.
It seems reasonable then that we'd have the descriptive text take into account the viewer's location. So objects can have many descriptions, based on the perspective of the view. And this can scale up and down as needed.
For instance, Mt. St. Helens in Washington State looks like a normal mountain when seen from parts of the nearby land. But it looks like (and in fact is) a volcano with its peak torn badly from other sides. Both views of the mountain are correct! The only distinction is the location (the place) of the viewer!
Another aspect of this: sometimes, the objects are viewed by non-VR viewers, such as a web-page providing external reviews of the rooms. In those cases, there could be a different description. Or, the descriptions could be organized such that there's a default if the location of the view is unknown. Or it might respond with "No description visible from your location." Again, this would be up to the creator of the content.
The same principle applies when building in the large.
I want to build a section of the Big Dark Woods. So, I create a Clearing. Now, a clearing might have the northern part, the southern part, the eastern part, and the western part. It might also have a central part. Thus, to cross the clearing from east to west you'd have to step from the eastern part to the central part, and from the central part to the western part, and then from the western part out of the clearing entirely.
That means there's five places (n/s/e/w/c) within the clearing, or six places described. And of course, the "unmentioned" places outside the clearing that it is "separated from" to be CALLED the clearing.
A node map would look like this of the places:
+---------North--------+
| | |
West-------Central------East
| | |
+---------South--------+
And of course, they are ALL in the clearing. So, five places "within" the sixth.
This provides the benefit of letting 'intermediate places' define distance for travel. For instance, it's longer to go straight across the clearing than go from the west to the north. How do I know? I counted the lines. One line connects west and north, two steps connect west to east. Which two steps? WNE, WCE, WSE. It happens that there are three paths. The paths are each two steps long.
People talking in the west wouldn't necessarily be heard by people in the east. Again, it depends on what rules were established to determine flow of events between the places.
And yet, if the clearing had a description "A large clearing in the woods" this description would be visible to anyone who typed look. Because they are all in the same clearing. Each place might add a bit, but they don't have to write from scratch. For instance, the northern place might add "You're at the north of the clearing." This reduces the number of descriptions that have to be made. One need only describe the over-all place and all the inner places are automatically described too.
The effects described here with places could be done in NMC1 with separate rooms for each place, and careful use of +nearby, and of re-writing say and pose and spoof and every other command that emits text, and by ignoring the errors in things like the hard-coded _listen/* events that cause entry/exit messages to reflect wrong, and so on.
With this notion of places, my goal is to enable a content creator to establish a VR effect with enormously more power and flexibility, while making it easy to ignore all these things for simple places.
For instance, even though one could make a huge forest where each major place had a whole cluster of interactive sub-places, one could still just do the equivalent of "@dig Clearing" " @desc clearing=A clearing."
We allow the easy as always...but we empower (and enable automation and tools to support) the people who want to do the complex.
We've seen what it meant to be a Booth in a Tavern. This was a very simple build. Hypothetically, we might create this using the following commands:
create TavernTavern contains ( create Booth )Tavern contains ( create Booth )Of course, I just created an object Tavern containing two Booths. That isn't quite a tavern. What I forgot to mention was that these were all "Places".
What does it mean to be "A Place?" Well, it means that an object is properly configured as "A Place." How do we do that? We tell the object to use a definition of a place. So, lets try the hypothetical commands again:
create Tavern as-a PlaceTavern contains ( create Booth as-a Place )Tavern contains ( create Booth as-a Place )The hypothetical commands do the following:
But, what does that mean, "Relationships between Places?"
A relationship is a connection or binding between two objects. In the above examples, we used two relationships
We started with "contains". This meant an object was "within" another or "listed as a content" of another. This is an association whereby each object knows of the existence of another.
Then, we added "is-a." This relationship meant that "Whatever is defined for a "Place," define it also for me. This is similar to taking an oath to uphold an office. You've accepted the job, now you wear the uniform.
The booths were not integral parts of the Tavern. When we build something that is made of other objects, we are using a composition relationship. A house is composed of rooms. The term we use for this is "consists-of." For example, a House consists-of Floors.
Beyond entering and exiting places, how do we get around from places within a larger place? For example, rooms in a house, or floors of a building? We add two more relationships.
We say places are "adjoining" when one may, in one navigation command, traverse from an place to another. For example, any two rooms which have an open space or doorway between them are adjoining. The following diagram represents adjoining places. All four places, A, B, C and D can be reached with one navigation command. Hypothetically, we might express this as "(adjoined A, B, C, D)."
+--------------+----+ | A | | | +----+----+ | | | B | | | | | | C | | | +----+----+ | | | D | +----+--------------+
We say a place is a "hub" if it provides access to many other places. The "hub" may reach any place within its list by one navigation command. Any place in the list may reach the hub by one navigation command, or may reach any other place in the list by two navigation commands. The following is an example. From the Hub, H, one may reach A, B, C, or D in one navigation command. From A, B, C, or D, one may reach H in one command, or any of the other Places A, B, C, or D in two commands. Hypothetically, we might express this as "(hub H A, B, C, D)." There is no comma after H as H is specifically the Hub and the order of the list A, B, C, D is immaterial.
+--+--+--+ |A | |B | +--+ +--+ | H | +--+ +--+ |C | |D | +--+--+--+
It should be noted that the degenerate cases of (adjoins X Y) and (hub X Y) are equivalent. They represent a bidirectional path from X to Y and back again. Either would adequately express the NMC1 concepts of an "@door" or creating an exit in X linked to Y and an exit in Y linked to X. That was a mouthful."
Finally, we must describe something like a slide on a playground. With a slide, you can go down, but you can't (necessarily) go back up. I will call this a "exit." This is just like the NMC1 object known as an exit. Hypothetically, we can express it as "(exits A B)." This means that there is a one-way exit out of A that leads to B. I intentionally omit multi-links from NMC1.
Summary of Relationships:
Let's give a juicy, meaty example. Otter, Rosella, Romaq, Mikaela, Jekteir, Riverdale and Nekenyu all contributed to "The Hotel Nameless," a sample building project. The floorplan might be as follows:
Floor 1: Floor 2: Floor 3:
(Alley)
+----------+-*---+ +---------------+ +---------------+
| Kitchen * Back| |Fire Escape L2 | |Fire Escape L3 |
+-----*----+-----+ +---*+-*+*-+*---+ +---*+-*+*-+*---+
|Restaurant* Lg | | R1 |R2|R3| R4 | | R5 |R6|R7| R8 |
+--+--*----+*-+--+ +--+*+--+--+*+--+ +--+*+--+--+*+--+
|El* Lobby m *S1| |El* Hall L2 |S?| |El* Hall L3 |S2|
+--+----*-----+--+ +--+---------+--+ +--+---------+--+
(Street)
Key:
* Door
S1 Stairs 1 to 2
S? S1 and S2
S2 Stairs 2 to 3
El Elevator
Lg Lounge
m Monument to NMC1
Fire Escape L2, L3 and Back are outside the building.
Whew! This isn't a trivial case! And it'd take a while to write a script for NMC1. Lets see if we can simplify this a bit. Below is the creation of all of the Places in the example.
create "Hotel Nameless" as-a Placecreate Restaurant, Lounge, Kitchen, Back as-a Placecreate "Hall L2", "Room 1", "Room 2", "Room 3, "Room 4",
"Fire Escape L2" as-a Placecreate "Hall L3", "Room 5", "Room 6", "Room 7, "Room 8",
"Fire Escape L3" as-a Placecreate Elevator, Stair1, Stair2 as-a Placecreate Monument as-a Unmovable-ObjectEverything shown, including the monument, but excluding (Alley) and (Street), are crucial components of Hotel Nameless. So, we say Hotel Nameless consists-of each of them. Below, we record it.
"Hotel Nameless" consists-of Restaurant, Lounge, Kitchen, Back"Hotel Nameless" consists-of "Hall L2", "Room 1", "Room 2",
"Room 3, "Room 4", "Fire Escape L2""Hotel Nameless" consists-of "Hall L3", "Room 5", "Room 6",
"Room 7, "Room 8", "Fire Escape L3""Hotel Nameless" consists-of Elevator, Stair1, Stair2"Hotel Nameless" consists-of MonumentAs a side note, we might tag all of that together something like this:
create "Hotel Nameless" as-a Place"Hotel Nameless" consists-of
(create Restaurant, Loung, Kitchen, Back as-a Place)...Alright, all the objects are created, as places and listed as crucial components of "Hotel Nameless" except for one -- the Lobby! Well, actually, we already created it. The lobby is nothing more or less than the interior of the Place "Hotel Nameless." Alright, lets finish the job. There are some notable commands. One will put the Monument in the inventory of the Lobby, thus the hotel. The relationships contains and consists-of are not mutally exclusive. The Lounge, Restaurant, and Lobby are all three adjoining each other.
(adjoined "Hotel Nameless", Restaurant, Lounge)(hub Kitchen Restaurant, Back)(contains "Hotel Nameless" Monument)(hub "Hall L2" "Room 1", "Room 2",
"Room 3", "Room 4")(hub "Fire Escape L2" "Room 1", "Room 2",
"Room 3", "Room 4")(hub "Hall L3" "Room 5", "Room 6",
"Room 7", "Room 8")(hub "Fire Escape L3" "Room 5", "Room 6",
"Room 7", "Room 8")(hub Elevator "Hotel Nameless", "Hall L2",
"Hall L3")(hub Stairs1 "Hotel Nameless", "Hall L2")(hub Stairs2 "Hall L2", "Hall L3")(hub "Fire Escape L2" "Fire Escape L3", Back)As a side note, lets add room 9 to the top floor. This demonstrates the scalability of adding one more Place.
"Hotel Nameless" consists-of (create "Room 9" as-a Place)(hub "Room 9" "Hall L3", "Fire Escape L3")Welcome to NMC2 and the Hotel Nameless!
In its most gross and simple level, places are then objects which allow VR to occur within them and which organize (receive and dispatch) events between their participants. Places in NMC1 were implemented with "room objects". In NMC2, we don't need any hard-coded object type. A VR object is a place if it's configured to allow RP within it. Places are perceived differently based on the location of the observer.