<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Skotos Proximity System - a Technical Summary (LONG) -->
<!--X-From-R13: "Quevfgbcure Oyyra" <QuevfgbcureONExbgbf.arg> -->
<!--X-Date: Tue, 18 Apr 2000 12:49:26 -0700 -->
<!--X-Message-Id: NDBBIGFBGLEIKKPEAHIBKEGKEEAA.ChristopherA@Skotos.net -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Skotos Proximity System - a Technical Summary (LONG)</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:ChristopherA@Skotos.net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00413.html">Previous</a>
| <a href="msg00427.html">Next</a>
]
Thread:
[ <a href="msg00501.html">Previous</a>
| <a href="msg00411.html">Next</a>
]
Index:
[ <A HREF="author.html#00414">Author</A>
| <A HREF="#00414">Date</A>
| <A HREF="thread.html#00414">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Skotos Proximity System - a Technical Summary (LONG)</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI>
<LI><em>Subject</em>: [MUD-Dev] Skotos Proximity System - a Technical Summary (LONG)</LI>
<LI><em>From</em>: "Christopher Allen" <<A HREF="mailto:ChristopherA#Skotos,net">ChristopherA#Skotos,net</A>></LI>
<LI><em>Date</em>: Mon, 17 Apr 2000 21:24:56 -0700</LI>
<LI><em>Importance</em>: Normal</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
This is the first of a number of "Technical Summary" documents that we
are working on to describe the technology behind our Skotos product.
I hope that you'll find it interesting, and that you'll pick holes in it
now so that we can fix it before we actually give the final version to
users ;-)
------------------------------------------------------------------------
.. Christopher Allen Skotos Tech Inc. ..
.. 1512 Walnut St., Berkeley, CA 94709-1513 ..
.. <<A HREF="http://www.Skotos.net">http://www.Skotos.net</A>> o510/649-4030 f510/649-4034 ..
The Skotos Proximity System - a Technical Summary
=================================================
(c)2000 by Skotos Tech Inc. <<A HREF="http://www.skotos.net">http://www.skotos.net</A>>
(See also article "An Evening At Chez Skoot - Proxes Part 1: Consent" at
<<A HREF="http://www.skotos.net/articles/chezskoot.html">http://www.skotos.net/articles/chezskoot.html</A>>)
A Sense of Place
================
Characterization and a Sense of Place
-------------------------------------
In fiction offering a sense of place is an important part of the
author's craft. Most writing instructors suggest giving the reader a
distinct sense of place and time in the opening paragraph if not the
first sentence. If a writer fails to do so, the reader can be confused.
Without a location to anchor him, a reader will be unable to envision
either the characters inhabiting that location or the actions they
engage in.
When multiple characters are involved, it is also important to explain
how characters are positioned relative to another. This not only gives
the reader a better sense of place, but also offers characterization. As
an example, notice the sense of place in the opening sentence of Dashiel
Hammett's "The Thin Man":
"I was leaning against the bar in a speakeasy on Fifty-second
Street, waiting for Nora to finish her Christmas shopping,
when a girl got up from the table where she had been sitting
with three other people and came over to me."
In this introduction we discover the protagonist is quite comfortable
lounging in an illegal bar, probably in the twenties, in some large
urban city in the USA. He has a girlfriend or wife that is wandering
elsewhere, and he isn't too worried about being separated from her. A
young woman, socializing with others, notices him, though he's doing
nothing in particular to attract attention, and goes over to him. You
already know that she wants to speak to him.
This paragraph gives a remarkable sense of place and of characterization
in just a few words.
Interactivity and Problems of Place
-----------------------------------
In multiplayer interactive fiction, a basic sense of place is easy.
Either the player exists in a room that can be examined or the player
exists in a scene that will be described as he takes actions. However,
multiplayer interactive fiction does a poor job of integrating that
sense of place with other players in the game.
This probably comes from multiplayer interactive fiction's roots in
single player games like "Adventure" and "Zork" , where there is truly
only one significant and realistic character--the player. At Infocom's
height, the best NPC were just a notch above a puzzle--not truly a
character.
In multiplayer interactive fiction, everyone is significant, and
everyone passes the Turing test (well, almost). So we need to find a way
to describe a player's interaction with his environment and with other
players, in a fashion that is significant to characterization.
The locale has been described, but how does the player fit in? Is he
comfortably leaning against a wall, resting at a table with his head in
his arms, or nervously standing at the door, waiting for someone? When
someone else arrives, how does he react? How does he show his interest
or lack of interest?
Problems solved by the Skotos Proximity System
----------------------------------------------
Skotos solves some of the problems of characterization and a sense of
place through a technique we call "Proximity". With the Skotos Proximity
System, combined with our Skotos Expression System (see the Technical
Summary), a player can be near a door, sit at a table, pray before the
altar, or kneel in front of his bride.
The proximity system also solves other problems. If someone approaches
you to kiss you, you have an opportunity to retreat before the kiss is
completed. If you drop something, it is close to you and someone else
will have to be just as close before they can pick it up. If you are
sitting at a table, you will not notice other people in the room unless
they are shouting, or unless you decide to pay particular attention.
Summary of the Skotos Proximity System
======================================
The Skotos Proximity System creates proxes, or proximities, which
qualify associations between objects.
* Proxes are defined by two objects, a vector, and a preposition.
* Prox chains describe how an object is linked up to the container it
is inside.
* Prox trees describe how all of the objects inside of a container
are linked.
* The categories of adjacent, nearby, vicinity, chamber, and
bordering describe how far apart proxes are.
The Prox
--------
A prox (short for proximity) is a distinct association between two
objects that describes the spatial relationship between those two
objects. It always includes a preposition (on, near, in, etc.) and a
vector.
Example:
spoon->ON->table
In this case the preposition is _on_ and the vector is from the spoon to
the table. In this situation, the spoon is described as "The spoon is on
the table" and the table is described as "The table has a spoon on it."
The spoon is considered to be a "child" of the table, and the table is
considered to be the "parent" of the spoon. The vector from the spoon to
the table (i.e. child to parent) is considered "up", and the reverse
vector from the table to the spoon (i.e. parent to child) is considered
"down".
Prox Chains
-----------
If you choose an object, find its parent (there can only be one), follow
that parent's prox up to another parent, etc., the entire set is known
as the "prox chain".
For example:
statue->ON->pedestal->NEAR->northwall->IN->room
Prox Tree
---------
If you choose an object, find its children, and discover all the
children of every child, all the way to the bottom of every chain, the
entire set is known as a "prox tree".
For example, this is a prox tree of a room:
statue->ON->pedestal->NEAR->northwall->IN->room
painting->ON-/ |
bowl->ON->table->NEAR->southwall->IN-/
spoon->ON-/ |
chair->NEAR-/ |
floor->IN-/
Adjacent, Nearby, Vicinity, Chamber, and Bordering Proxes
---------------------------------------------------------
Every object is "adjacent" to its parent and children. For instance
Alice is sitting next to Carol who is sitting next to the table; Carol
is adjacent to both Carol and the table, but Carol is only adjacent to
the table.
By default, unobvious actions and quiet sounds can be heard by all
objects that are adjacent. Thus when Alice whispers, Carol can hear her.
When Carol whispers, Alice can hear her, and if the table could listen,
it would hear her as well.
The "nearby" class of an object is determined by going up the object's
tree until the first non-volitional parent is found. All children of
that parent, down several levels, are "nearby". For instance, everyone
sitting at a table is nearby to each other, including the Alice who is
sitting next to Carol who is sitting at the table, and Bob who is
standing on the table.
By default everyone that is nearby will see all the actions and hear all
the sounds of those who are also nearby. Thus everyone speaking in a
normal voice will be heard by everyone at the table, and they will see
all normal actions.
"Vicinity" is defined as everything associated with the same detail of a
room (or container). The prox chain is traced up until a room/container
detail is reached. Then, all children down several levels are considered
to be in the "vicinity". For instance, Carol is sitting at a table in
the back corner of a room (a detail of the room). She is in the vicinity
of everyone at her table, of everyone to in the back corner of a room,
and of everyone sitting at other tables in the back corner of the room.
By default only significant actions and loud sounds will be seen or
heard by all that are in the same vicinity. Thus when Bob shouts and
dances on the table, all in the vicinity will see and hear it, but they
will not hear the normally voiced complaints of those that are at Bob's
table.
Every object that is inside the same room (or container) is considered
to be in the same "chamber". By default, a few very significant actions
and very loud sounds can be seen or heard be everyone in the same
chamber.
Two rooms (or containers) that share a common entrance/exit pair, are
considering to be "bordering" one another. Very loud sounds or a general
"din" of noise may also be heard in rooms bordering each other.
Proxes in Practice
==================
Proxes have a number of visible effects in the game:
* They can change how objects are described.
* They can interact with stances and poses.
(How proxes interact with intimate space and sound are described in
another section.)
Level of Description
--------------------
In most cases when an object is described, only one level of proximity
up and down is detailed.
spoon->ON->plate->ON->table->IN THE MIDDLE OF->room
If you "look at room" you'll see "You are in a room with a table in the
middle of it."
If you "look at table" you'll see "You see a table with a plate on it,
in the middle of the room."
If you "look at plate" you'll see "You see a plate with a spoon on it,
on a table."
If you "look at spoon" you'll see "You see a spoon on a plate."
Proxes with Stances & Poses
---------------------------
Prepositions are often combined with stances (i.e. "standing against the
wall" or "sitting near the flowers"), or with poses (i.e., "reading in
the chair") or both (i.e. "kneeling and praying before the altar"), as
per the Skotos Expression System (see that Technical Summary).
However, certain proxes may be disallowed with specific stances or
poses; for instance, you can't "kneel above the altar". Others stances
or poses may require specific kinds of proxes, for instance, "with his
arm around Carol".
Creating a Prox
===============
Proxes are created by examining four values:
* An active object. The active object is placed in relation to some
static object which is already part of a prox tree.
* A static object. The static object is already part of a prox tree;
an active object is placed in relation to it.
* A vector. This is the relation between the active object and the
static object. It defines one of them (usually the active object)
as a child and the other (usually the static object) as a parent.
* A preposition. This is a description of how the child and parent
are related.
In order to create a prox all four of these values must be known.
Usually a player will issue a command that will make these choices
obvious. Take the sample command: "put knife on plate". Clearly, the
active object is the knife and the static object is the plate. A vector
leads from the knife (child) to the plate (parent). The preposition is
"on".
Sometimes all of this information will not be obvious. Alternatively,
some of the "obvious" values may be changed to create more consistent
and interesting descriptions. In particular:
* The active object should always be obvious from the command.
* The static object will fall back to a default if it is not obvious
from the command.
* A default choice of vector is always obvious. However the vector
direction may be overridden to improve readability.
* The preposition will fall back to a default if it is not obvious
from the command. In addition, the vector direction may be
overridden to improve readability.
Choosing the Active Object
--------------------------
The *default* active object is always the object which is being acted
on. A ball is dropped or a frisbee is thrown or a rabbit is hidden in a
hat.
Choosing the Static Object
--------------------------
The static object will usually be obvious. A player will choose to put
the active object on (or in or under or over) a static object. For
example "put screwdriver in toolbox" or "brush dust under rug" or "put
paint bucket over doorway". However there are occasions when a prox will
have to be created without this information, such as when the command
"drop grenade" or "throw stink bomb through north door" is issued. In
these cases, a default static object is chosen.
The *default* static object is usually defined by one of a few special rules:
* If an object just entered a room (typically a volitional object
like a player or NPC, but possibly a thrown item like a stink bomb)
the static object will be the entrance it came from.
* If an object is dropped, the static object will be the volitional
object that dropped it, i.e. <code>grenade->CLOSE->player</code>.
* If the static object can not be determined, then the room or
container which the active object is in is chosen.
Choosing the Vector
-------------------
The *default* vector selects the active object as the child and the
static object as the parent. For example, in the command "put the
flowers next to the altar" the flowers, which are the active object, are
chosen as the child and the altar, which is the static object, is chosen
as the parent: "flowers->NEXT>altar".
Overriding Default Vectors
--------------------------
In some cases the default vector will confuse players reading a room
description. For instance, if the player puts the altar next the
flowers, the following prox would be created by default:
altar->NEXT->flowers
Clearly "The altar is next to the flowers" is not desirable outcome.
Whenever creating a prox, the distinctiveness of both items is examined.
If there is a large difference in distinctiveness between the two
objects, the system will override the player's choice of vector.
The general algorithm used to determine the vector is:
* If the two objects are within 33% of each other in bulk, then the
static object is made the parent.
* If the two objects are more then 33% different in bulk, then the
item that is larger is selected to be the parent.
However a number of other considerations are taken into place, to
determine the distinctiveness of an object:
* If an object has an adjective, it is more distinctive. For example
a silver spoon should be more distinctive then a spoon. A gold
spoon would be even more distinctive.
* Volitional objects (i.e. living beings) are considered to be
somewhat more distinctive then non-volitional objects.
* There is also a "distinctiveness" modifier. This is used for
objects that are quite notable. This allows the magic sword
Excalibur to be the most distinctive object, or a moving but non-
volitional object like a pendulum to be more distinctive.
A total distinctiveness value is calculated, and then it is used as a
multiplier to bulk for purpose of the vector-determination algorithm.
Choosing the Preposition
------------------------
Commands like "drop grenade" or "throw stink bomb through north door"
also leave the preposition to use up in the air. In these cases a
default preposition is chosen.
The *default* proposition is the relationship that most distinctively
describes the relationship between two objects:
Take the case of these two potential proxes:
table->NEAR->floor
table->ON->floor
The table can be "near" the floor, or "on" the floor. "On" is more
distinctive, so it is the default prox.
A number of rules are used for special cases when choosing propositions:
* If an object just entered a room (typically a volitional object
like a player or NPC, but possibly a thrown item) it will default
to be "near" the entrance that it came from, i.e.
"dog->NEAR->doggydoor".
* If an object is dropped, it will default to be "close" to the
volitional that dropped it, i.e. "stone->CLOSE->player".
* If a prox can't be found for an object, and the object that
contains it is quite large in relation (for instance a room), the
prox default is "near middle of", i.e.
"grenade->NEAR MIDDLE OF->room".
* If the container is not too much larger then the object, then it
will default to being just "in" the object, i.e. "rock->IN->chest".
Overriding Preposition Choices
------------------------------
Sometimes there will be a conflict between multiple propositions, such
as when a player puts a paper "below a sofa" when there is already a
rock "under a sofa". Which preposition should be used, below or under?
A system of priority decides which prox to use when synonymous proxes
such as "under" and "below" conflict. Each synonym is given a different
priority.
If a new prox is created with a synonymous preposition to an old prox
the higher priority preposition is used for both objects. In our example
of a "paper below a sofa" and a "rock under a sofa", they would become
"a paper and rock under a sofa".
In the lists below the prepositions to the left are given priority
(though the choices are somewhat arbitrary).
*Container Proxes* (Inventory Related):
* in, within
(special prox for items in a container that does not close)
* inside
(special prox for items in a container that does close)
* enclosed
(special prox for things inside a closed container)
* attached, held
(special prox for thing that move with the parent object when it is
moved, but are not inside.)
*Intimate Proxes* (Deniable Consent)
* close to, close by, close beside
* against
* under, beneath, below
* on, upon, on top of, across
(these may also be container proxes)
* around
*Near Proxes* (Delayable Consent)
* near, by, nearby
* over, above
* behind
* in front of, before
* beside, next to
*Other Proxes*
* with, among
(not an actual prox; will join the objects parent's prox)
* in the center of, in the middle of, near middle of
(used as part of the leave command, or a default -- the parent must
be a room or a detail of a room)
* at the edge of
(parent must be non-volitional, a room, or a detail of a room)
* outside of
(?)
* beyond
(?)
* between
(NOTE: Not to be implemented in v1 at it requires two proxes)
Disallowed Prepositions
-----------------------
Some kinds of objects may disallow certain prox prepositions. This
prevent such actions such as "put paper behind the wall", or "put paper
in the fork", etc.
Changing Proxes
===============
Once proxes are created they can be changed in a number of ways:
* If an object is removed, it breaks a prox chain and a new one must
be formed.
* A player can choose to join an existing prox.
* A player can choose to leave an existing prox.
* A player can choose to approach a volitional, such as a player. He
will join the volitional's existing prox, then enter a "near" prox,
then enter an "intimate" (or "close") prox.
Breaking a Prox
---------------
When an object is moved, the prox between it and its parent is broken,
as well as the proxes between it and its children (except for container
proxes.) A new prox will be created for the orphaned children, leading
to the moved object's parent.
Take the following example of a prox chain:
flowers->IN FRONT OF->picture->ON->table->NEAR MIDDLE OF->room
If you remove the picture, the prox chain for the flowers becomes:
flowers->ON->table->NEAR MIDDLE OF->room
Joining a Prox
--------------
The join command allows a player to move up to another volitional. It
causes the player's parent prox to become the same as the parent prox of
the volitional that he is trying to join.
For instance:
bob->NEAR->westdoor->IN->westwall->IN->room
carol->AT->table->NEAR->westsideofroom->IN->room
Bob types "join carol" and the proxes change:
bob->AT->table->NEAR->westsideofroom->IN->room
carol->AT->table->NEAR->westsideofroom->IN->room
Leaving a Prox
--------------
Another simple player command is "leave" or "leave _object_ " -- this
will cause the player's prox to become "near" his parent prox's parent.
If the new parent prox is the room that the player is in, it prox will
default to "near middle of room". If the player types leave from "near
middle" he will be "at the edge of room". If the player types leave one
more time, if there is a default "out" exit, it will be taken,
otherwise, a random exit other then the exit he originally came from
used, or if it is the only exit, the exit he arrived from. (NOTE TO
ENGINEERING -- we currently are not storing the entrance that a player
arrived from.)
Example of the results from multiple leave commands:
bob->NEAR->door->IN->westsideofroom->IN->room
bob->NEAR->westsideofroom->IN->room
bob->NEAR MIDDLE OF->room
bob->AT EDGE OF->room
bob->NEAR->door->IN->eastwallofnewroom->IN->newroom
Approaching a Prox
------------------
A more complex way for a player to change his prox is to "approach"
another object.
If the player and the object he is approaching have different parents,
but are in the same room (or other container), the approach command will
change the players' parent prox to be the same as the object he is
approaching. If the player and the object he is approaching are not
already in the same prox, this has the exact same effect as join.
As a start of an example:
bob->NEAR->westdoor->IN->westwall->IN->room
carol->AT->table->NEAR->westsideofroom->IN->room
After Bob gives the command "approach carol", and he will receive the
message "You begin to approach the table that Carol is at" and then
after a short delay: "You are at the table that Carol is at" Others
nearby, including Carol, will see only that Bob is approaching the
table. The proxes are now as follows:
bob->AT->table->NEAR->westsideofroom->IN->room
carol->AT->table->NEAR->westsideofroom->IN->room
If the player and the object he is approaching already have the same
parents, the approach command will change the player's parent prox to be
"near" the object he is approaching.
So if Bob gives the command "approach carol" again, he will receive the
message "You begin to approach near to Carol." If Carol doesn't move, he
will receive the message "You have approached near to Carol" after a
short delay. Others nearby will see these messages that Bob is trying to
be near to Carol. The proxes are now:
bob->NEAR->carol->AT->table->NEAR->westsideofroom->IN->room
carol->AT->table->NEAR->westsideofroom->IN->room
If the player is already "near" an object and gives an approach command
a third time, he will move "close to" it (into the intimate proximity).
So if Bob gives the command "approach carol" one more time, he will
receive the message "You try to approach close to Carol." After a delay,
if he is successful, he will see "You get closer to Carol" -- others may
or may not see a message (see "Avoiding Approaches" below).
bob->CLOSE TO->carol->AT->table->NEAR->westsideofroom->IN->room
carol->AT->table->NEAR->westsideofroom->IN->room
Bob could have said "approach near to carol" to skip one step, or
"approach close to carol" and skipped two steps; however, all the
intermediary messages will still happen as if the commands were
separate.
Bob also could have chosen other prepositions other then "near", for
instance "approach next to carol" or "approach in front of carol".
If Bob is "close to" Carol and types "approach", the system will say
that Bob is as close as he can get to Carol. The prepositions "on",
"against", and "under" are also considered intimately "close"; thus
further approaching isn't allowed.
Avoiding Approaches (or Not)
============================
Proxes also affect what players can choose to do to each other. The
Skotos Proximity System is consensual, by default it enforces a MUSH-
style sensibility. Thus there are opportunities to deny or avoid people
who are becoming too intimately close:
* The "close" proximity is considered part of a player's intimate
space. A player can deny other people from entering it.
* The further away "near" proximity isn't private space, but a player
still has an opportunity to leave before another player enters it.
Denying Intimate Proximity
--------------------------
Volitional objects, such as players, NPCs, and other living creatures,
may refuse the close approach of another volitional into an intimate
prox.
In the example above when Bob attempts to approach closely to Carol, she
will see the message "Bob begins to move close to you -- D)eny, A)ccept,
R)eturn, or C)ounter".
* If Carol D)enies the approach, only Bob will know that the attempt
failed. If Carol types nothing, the default is D)eny.
* If Carol A)ccepts the approach, everyone will see "Bob gets closer
to Carol".
* If Carol R)eturns the approach, everyone will see "Bob and Carol
get closer together".
* If Carol C)ounters the approach, everyone will see that Bob failed
to get close.
As any objects that they drop will also be "close"; once Bob is also
close to Carol, either of them can pick up any dropped item without
getting permission from the other.
Certain commands like kiss, slap, etc. may require that the active
player succeed in getting close to the receiving player first.
Repetitive Intimacy & Closeness
-------------------------------
When someone changes leaves a "close" prox, they have ten seconds to
return to it without retriggering consent. This allows for brief changes
of stance, pose, or prox for expressive purposes.
Automatic Response
------------------
If Bob persists attempting to get close to Carol, she can put him on her
"Deny" list, and all attempts to get close will automatically be denied
without delay. Or, she can put him on her "Counter" list and he will
automatically be opposed and everyone will see her rejection. She could
also put him on her "Accept" or "Return" list, and every time he
attempts to get close it will automatically succeed or be returned
without delay.
With each of these lists, she can also specify that they only work with
specific commands. For instance, Carol can allow a particular person to
kiss her, but disallow other commands that require intimate proxes.
Avoiding Near Proximity
-----------------------
Players may also avoid approaches by changing prox before the attempt is
complete.
In the above example, Bob approaches Carol, then goes "near" her and
finally "close". Carol can deny the "close" approach, but can't do
anything when Bob is just coming "near"--except move away. There is a
delay before Bob is successful; Carol can "leave" the table, causing
Bob's attempt to fail. Bob will remain at the table; he must start all
over to try to approach Carol again.
Automatic Avoid
---------------
In most cases, attempts to enter the "near" prox (or other preposition
proxes in the delayed category) can't be avoided without the target
leaving his or her own prox first.
Though it is an imperfect solution, Carol can put Bob on her "Avoid"
list, which will cause Bob's attempts to enter her delayed preposition
prox to be denied. Only she and Bob would see this failure. We are
considering if a "Strongly Avoid" list will be necessary; if so, it
would always allow Carol to publicly reject any of Bob's approaches.
Proxes & Psycho-Acoustics
=========================
Psycho-acoustics is the study of how sounds are processed by the ear and
brain to give the listener useful information about the world outside.
The study of how sounds are localized by the brain, how pitch is
determined, and how we separate simultaneous similar sounds or pick
useful sounds out of a 'noisy' background are all part of psycho-
acoustics.
In a sense this is the study of the 'subjective' perception of sound
properties. Important measures used in psycho-acoustics include
loudness, sharpness, fluctuation strength, pleasantness, and roughness.
Skotos uses some of the principles of psycho-acoustics to determine how
sounds work; it focuses on those factors associated with whether a sound
(usually speech) has been perceived, and whether it has been understood.
Psycho-acoustics are used by the SkotOS system, in conjunction with
proxes, to determine what can be heard and what can't. In particular:
* The subjective measure called 'son' is used to determine how likely
it is that a sound will be noticed.
* Sounds from more distant proxes are subjectively more quiet.
* Ambient noise can decrease the intelligibility of sounds.
* Particular rooms or locales can increase or decrease ambient noise
values.
The Decibel & the Son
---------------------
Various measures of sound and loudness are needed to determine the
audibility and intelligibility of speech.
The basic decibel (dB) is a logarithmic scale objectively measuring
sound intensity; a difference of 10 dB is a ratio of 10:1, and 3 dB is
about 2:1. The decibel scale is used because the ear responds to sound
in an approximately logarithmic fashion. Depending on the actual
frequency, most people will perceive a doubling in loudness for a dB
increase of 8 to 10.
Subjective perceived loudness (as opposed to actual sound power) is
measured in sons; a 40 dB sound with a frequency of 1 kHz is 1 son, and
an increase of 10 dB doubles the son value.
A sound will, of course, transmit through any material, but walls,
floors, etc. will dampen the sound before it emerges on the far side. In
order to be perceived, sounds must also be separated from other sounds
in the environment; this is greatly affected by relative frequency,
repetition, sound level, etc.
The attenuation and decay of sound depends on many factors including the
size and shape of the source, the environment, and reflection from walls
and other surfaces. An interior wall of an ordinary modern house will
reduce son levels to x1/8th as sounds pass through; better sound
isolation will produce reductions of x1/16th and x1/32nd son level. A
passenger jet's fuselage reduces the son levels by a factor of x1/128,
needed to preserve the passengers' comfort.
The intelligibility of a sound will begin to disappear as its son level
diminishes, and as the background (ambient) noise increases.
Intelligibility begins to disappear if the son level of speech drops
below 1/4 son, or to less than x1/4 of the ambient son level (hearing
impairments can also affect this). Thus, in a noisy bar you must speak
up a bit (to 6 son) to be heard over the chatter (24 son). Actual
audibility disappears (for most people) at x1/16th son, or if the sound
is less than x1/16th of the ambient level.
*Sample Loudness Levels, in sons:*
* 1/16 = not audible
* 1/8 = breathing
* 1/6 = rustling leaves
* 1/4 = not intelligible
* 1/4 = soft whisper
* 1/2 = very soft music, not-so-soft whisper
* 1 = average home, library, quiet office, quiet residential
outdoors
* 2 = rainfall, loud office
* 4 = human conversation
* 8 = busy street traffic, freeway traffic
* 16 = garbage disposal, doorbell, manual labor with tools
* 24 = handsaw, noisy restaurant/bar, inside soundproof tractor
cab
* 32 = train, lawnmover, shop tools, shouted conversation
(beginning of hearing loss)
* 48 = electric drill
* 64 = jack hammer, power tools, tractor without cab, factory,
boom box
* 128 = shouting, crying baby, concert, disco, car horn (hearing
loss at 1.5 minutes)
* 192 = subway screech, sand blasting, squealing pigs, stereo
headset at 11
* 256 = loud rock concert, band concert, basketball game,
thunder, jet plane idling, siren
* 384 = loud factory installed auto stereo
* 512 = jackhammer, air raid siren, percussion section of
symphony, stock car race
* 1000 = prop engine plane at takeoff, un-muffled 50 HP engine
fifty feet away
* 2000 = jet plane at takeoff, cannon (physical pain)
* 3000 = pistols and rifles
* 4000 = shotguns
* 5000 = rocket launch
Thus some basic evocation (speech related) verbs and adverbs produce:
* whisper 1/2
* say 4
* shout 32
* scream 64
* quietly x1/2
* loudly x2
Proxes, Speech & Sons
---------------------
Proximity affects how clearly things can be heard. In an average room
(ambient sound of 1 son) things are intelligible down to the level of a
soft whisper (1 x 1/4 son) for adjacent proxes.
Each additional category of proximity (nearby, vicinity, chamber,
bordering) increases the level of infallibility by approximately x4.
Thus the minimum intelligible level for nearby objects in a normal room
(1 son) is 1 son (1/4 x 4^1 x 1 son). Normal human conversation (4 sons)
can be heard in the vicinity (1/4 x 4^2 x 1 son). Quiet shouts (16 sons)
can be heard in the chamber (1/4 x 4^3 x 1 son). Screams can be heard in
bordering areas (1/4 x 4^4 x 1 son).
Below these levels, words are increasingly garbled, down to the level of
inaudibility (a multiplier of x1/4). Thus the minimum level at which
something garbled can be heard in a near prox is 1/4 son. This
multiplier could be carried through all the categories: nearby 1 son;
vicinity 4 son; chamber 16 son; bordering 32 son.
Other activities can increase these levels, such as paying attention,
which is a x4 multiplier. Thus the absolute minimum level at which
something garbled can be heard by an attentive listener in a near prox
is 1/16 son. This multiplier could be carried through all the
categories: nearby 1/4 son; vicinity 1 son; chamber 8 son; bordering 16
son.
Ambient Noise
-------------
If there is too much ambient noise, whispers will fail or be garbled due
to the "din" of noise. With large amounts of ambient noise, even normal
speech may become garbled.
The default value for ambient sound is 1 son, as given in the example
above. However, objects, room details, and rooms themselves can have
intrinsic ambient noise levels. For instance, the area behind a
waterfall could have an ambient noise value of 8 sons.
Ambient noise is also a function of speech and the number of volitional
objects in a room, so being in the middle of a crowded bar or amidst a
herd of bison will be quite noisy.
Attenuation & Amplification of Sons in Proxes
---------------------------------------------
Some objects, room details, and rooms may either attenuate (decrease all
sounds), absorb (decrease specific sounds), or even amplify (increase
all sounds) coming from a vicinity or chamber, or in some cases even
change how sounds that are adjacent are heard.
For instance, while in a booth in the corner you will hear less of the
crowd outside, and they will hear less of you. If you are on a stage,
they will hear more of you, but you will hear less of them.
Exits of a room may also attenuate or absorb sounds. They may do so in
different ways depending on if the exit is open or closed. This allows
for huge open city gates that stop few sounds, or a closed magical
portal that stops all sound.
State of Development
====================
The Skotos Proximity System is partially completed, the proof of concept
being quite powerful. Skotos' goal is to have the completed Skotos
Proximity System as described here ready for a consensual conflict (i.e.
MUSH-style) environment by September for the release in the Castle
Marrach game and for Stages shortly after that. After that, Skotos will
adapt the Skotos Proximity System to other (i.e. MUD-style) games with
non-consensual conflict.
Open Issues with Proxes
-----------------------
* It is possible in some situations to accidentally get into a prox
circle. These need to be eliminated.
* Is the distinction between close and near proxes significant enough
for new users?
* Will people abuse the near proxes, thus requiring consent for all
prox operations rather then just intimate ones? Is a "strongly
avoid" list required?
* The consent system is probably still open to some abuses that we
have not thought of.
* There are a number of issues with proxes between three objects, so
we don't allow it. Right now prox chains need to be unique. Thus
you can't have two people "next to each other" -- at least one has
to have a prox leading up into the room. Similarly, you can't have
a between prox (i.e. Bob is between Carol and Alice).
* Describing a room full of objects with proxes associated them with
needs to be integrated into the Skotos Crowd & Group System, and it
is unclear what all the issues are.
* Distinctiveness is also used by the Skotos Crowd & Group system --
are there any cases where the logic that works for one does not
work for the other?
* Proxes between crowds or groups (i.e. "the crowd moves toward the
stadium") are way beyond our scope right now.
* Ambient noise may be not clear enough to players to be worth the
trouble. Perhaps we should use a "din" marker rather than adjust
the intelligibility of sound? If we do support intelligibility,
what method do we wish to use to garble the speech?
* There is a relationship between container proxes (in, inside,
enclosed) and some of the intimate proxes (on, attached) with
inventory. The parallel of these proxes with inventory is clear,
but some of the implications of distinctiveness and order of
chaining are not. Many of the details need to still be worked out.
* There is a deep question related to our current haphazard chain-
extension approach. Should we try to maintain some of the
properties of a tree, such as attempting to keep it to a star shape
with more distinctive objects in the middle and least objects
distinctive toward the leaves? How much do we override player
choices to maintain such a tree?
* Example: When a very distinctive object enters a prox, it will
not become the child but the parent of the prox. This switching
occurs recursively so that more distinctive objects travel
towards a center of the net, which thus becomes star-shaped. In
a worst- case scenario, you could have lots of distinctive
objects entering and then leaving a long prox chain where each
such operation is O(N) where N is the length of the chain.
Say a dust mite is next to a fly is next to a bowling ball is
next to an anvil is next to a statue, and the highly distinctive
David Bowie enters the room and approaches the dust mite. He will
recursively be pushed to the head of this prox chain each time
he approaches the dust mite. This is not really an O(N^2)
scenario though. Currently our implementation of _describing_
prox chains is, but that is purely so that I wouldn't spend lots
of time coming up with clever algorithms to do it faster. The
problem is not inherently O(N^2).
-- Par
* Right now the offer and accept command applies to any transfer
between two volitionals. How closely should we integrate into the
prox system? For instance should you only be able to offer to
someone in a near or intimate prox? Should there be any automatic
acceptance? For instance do you need someone to separately accept a
gift if they have already accepted an intimate prox? In addition to
offer and accept, we may wish to have a "trade" object function --
does that change any interaction with the prox system, such as not
only working for close and near, but also nearby?
* Should we have a paranoia flag that automatically puts everyone on
your "avoid" list?
* The idea behind return is that if someone approaches you
intimately, you could in return respond by doing another intimate
action. A kiss could be returned with another kiss or a slap. How
restrictive do we want to be as to what actions can be returned?
What actions can be returned for each intimate action? How do we
prompt the player as to what actions are possible?
* What types of failure messages should people see when you counter
different actions? How do the messages differ for the approacher,
the counterer, and those nearby?
* It is possible that some intimate actions should not end with both
parties close, especially such casual actions such as shaking hands.
* There are some thief related close actions such as jostle, bump,
etc. Most of them should wait until we integrate a combat system
into the prox system. However, are there any easy things we can do
now to prepare for them?
-- CA
_______________________________________________
MUD-Dev mailing list
MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00413.html">Re: [MUD-Dev] RE: MUD-Dev request rejected</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00427.html">Re: [MUD-Dev] Alignment</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00501.html">Re: [MUD-Dev] Justifying twinking</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00411.html">[MUD-Dev] incremental revenue discussion</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00414"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00414"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>RE: [MUD-Dev] Justifying twinking</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="00511" HREF="msg00511.html">RE: [MUD-Dev] Justifying twinking</A></strong>,
Raph Koster <a href="mailto:rkoster@austin.rr.com">rkoster@austin.rr.com</a>, Sat 22 Apr 2000, 04:13 GMT
</LI>
</ul>
<LI><strong><A NAME="00464" HREF="msg00464.html">Re: [MUD-Dev] Justifying twinking</A></strong>,
S. Patrick Gallaty <a href="mailto:choke@sirius.com">choke@sirius.com</a>, Wed 19 Apr 2000, 18:55 GMT
</LI>
<LI><strong><A NAME="00476" HREF="msg00476.html">Re: RE: [MUD-Dev] Justifying twinking</A></strong>,
jolson <a href="mailto:jolson@micron.net">jolson@micron.net</a>, Wed 19 Apr 2000, 22:53 GMT
</LI>
<LI><strong><A NAME="00501" HREF="msg00501.html">Re: [MUD-Dev] Justifying twinking</A></strong>,
Hess, Ian W (Ian) <a href="mailto:ihess@lucent.com">ihess@lucent.com</a>, Sat 22 Apr 2000, 04:13 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00414" HREF="msg00414.html">[MUD-Dev] Skotos Proximity System - a Technical Summary (LONG)</A></strong>,
Christopher Allen <a href="mailto:ChristopherA@Skotos.net">ChristopherA@Skotos.net</a>, Tue 18 Apr 2000, 19:49 GMT
<LI><strong><A NAME="00411" HREF="msg00411.html">[MUD-Dev] incremental revenue discussion</A></strong>,
Matthew Mihaly <a href="mailto:the_logos@achaea.com">the_logos@achaea.com</a>, Tue 18 Apr 2000, 19:49 GMT
<LI><strong><A NAME="00405" HREF="msg00405.html">[MUD-Dev] new list</A></strong>,
Kevin Littlejohn <a href="mailto:darius@connect.com.au">darius@connect.com.au</a>, Tue 18 Apr 2000, 00:12 GMT
<LI><strong><A NAME="00403" HREF="msg00403.html">[MUD-Dev] RE: MUD-Dev request rejected</A></strong>,
Schubert, Damion <a href="mailto:dschubert@origin.ea.com">dschubert@origin.ea.com</a>, Tue 18 Apr 2000, 00:06 GMT
<UL>
<LI><strong><A NAME="00421" HREF="msg00421.html">[MUD-Dev] Value of Characters [was: Quote from a Simutronics developer]</A></strong>,
Christopher Allen <a href="mailto:ChristopherA@Skotos.net">ChristopherA@Skotos.net</a>, Tue 18 Apr 2000, 19:48 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>