[MUD-Dev] Mud-Dev FAQ part I

[Marian Griffith]

                        Mud-Dev FAQ
                          part I
                        -----------



Last modified:   20 September 1999
                 14 November  1999
                 16 Januari   2000

*1. Introduction
*2. Frequently Asked Questions
*3. Previous Topics
*4. Scenarios
 5. Resources
 6. Glossary
 7. Changes, To Do & Acknowledgements
(* chapters found in this part of the FAQ)

A web based version of this FAQ can be found at:
<URL:http://www.kanga.nu/FAQs/MUD-Dev-L/>

Please email any corrections, suggestions or constructive criticisms
to Marian Griffith at gryphon at iaehv.nl

Recent Changes:

16-01-2000 -- Faq split in two for size (chapters 1 to 4 and 5 to 7)
              Resources: Added several new muds
              Made some minor spelling corrections
991114 -- New moderator (Marian Griffith)
990920 -- Resources: Added Raph Koster's website, gaming section.
	  Glossary: New terms include full world reset, PK, psychological
		    disinhibition, world state and virtual sociopath.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
			1. Introduction



The following may also be found at the list's homepage straddled at
<URL:http://www.kanga.nu/lists/listinfo/mud-dev/>.

--<cut>--

List charter 

The MUD Development mailing list is not platform, language or game specific,
but concentrates on discussing the design and implementation of any and all
MUD servers and systems.  Another large related topic is game design.  This
does not mean that the details of a specific server or game design point
can't be discussed in excruciating detail, or even that server or game
source can't be bandied about and picked over, just that the list isn't to
become a religious stomping ground for your platform, language, server, or
hobby horse of choice.  The topic definition is not limited to technical
areas: social engineering, cultural considerations, applicability of
technical addresses to "soft" problems, and other less rigorous avenues of
investigation are also fair game. 

The goal is high signal, low noise. The MUD Development list is NOT an
email version of the rec.games.mud.* newsgroups.

--<cut>--


Also from the same page is a message for the commercially orientated amongst
us:

--<cut>--
Note from the list owner 

The list has a number of members who work professionally in the field. Their
presence raises certain concerns for intellectual property, trade secrets,
copyrights, etc for the list and for list postings. The below should give an
overview of this area, what I expect of list members, commercially
affiliated or otherwise, as well as the intended character of the list.

As list owner I expect all list members to be responsible for what they
post.
The rules are obvious: If there is something your company or affiliations
does not want publicised, then don't post it to the list. If you see one of
your commercial or other partners post something to the list that shouldn't
have been, then don't bring it up on the list -- take it to direct email.
Raising such issues on the list will be used as an excuse for removing
membership. 

Please do not use this as an alibi to start adding disclaimers to your
posts. You are the members on this list, not your companies. If it isn't
your opinion don't write it. If you are reporting someone else's opinion,
state it as such.

If a post is written as a representative of your company or affiliation,
then identify it as such. Adding a signature which identifies your
affiliation is not enough. That can be too easily automated and is not
an explicit statement of representation.  A leading paragraph identifying
the source or representation placed above all the textual body including
the attributions, will do (keep it short).

Commercial grandstanding, advertisements, chest puffing, or other forms of
promotion are not appreciated on the list and will be rewarded with removal
of membership. The list is an expressly non-commercial venue. It is intended
as an intelligent and free discussion by peers in the field, both hobbyist
and professional.

Membership of the list is not a right. You are here as my guests. This is a
private list run as a personal contribution to the field. I trust the list's
membership to behave accordingly.

Posting to the list may be considered analagous to having a conversation in
my living room using bull horns while the windows are open and everyone has
tape recorders. There is no secrecy, or control of the dissemination of data
once it is posted.

And on a final note: Attempting to invalidate or discourage a discussion or
avenue of investigation on the list because it strays too close to a
commercial project's field or other such interest will be deemed an
intentional personal insult and due cause for permanent removal from the
list along with all associates.

Thank you.

J C Lawrence, MUD-Dev list owner.

--<cut>--


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
			2. Frequently Asked Questions



1. What should I do now I have joined?

If you have not already, please read the rec.games.mud.* FAQs to
familiarise yourself with all the different sorts of muds out there, see
<URL:http://www.cs.okstate.edu/~jds/mudfaqs.html>.  Take some time to
browse through the list's webpage.  It may be found at
<URL:http://www.kanga.nu/lists/listinfo/mud-dev/>.


2. How do I post?

Posting on the list is a privilege which may be obtained from the list
owner (who resides at mud-dev-owner at kanga.nu).  It is suggested you lurk for
a while to get a gist of how things work on the list.  When you do approach
the list owner for posting privileges, attach your intended posting.


3. What is the accepted standard for posting?

In short: No more than 80 columns wide, and only use 7bit ASCII.  If
you are posting from a country/language which uses "special"
characters, such as with umlauts or other diacritical marks, then
please ensure that your mailer properly MIME wraps them.  Most modern
mailers will do this properly.

MIME, HTML, RichText and similar are discouraged.  This includes
"vcard" attachments from NetScape mail and similar.  Small MIME
attachments, such as a graphic used to illustrate a point discussed in
the text of a message are acceptable.  The guiding rule is that the
brunt of the value of a message must always be in the text.

A reply to another posting must have at least the name of the original
author if your mailer does not automatically supply one, eg:

  [Bubba]
  >On  4 Jan 98 at 22:20, Boffo wrote:
  >> Buffy <Buffy at players-r-us.com> wrote:
  >>> I just found a cool mud at <URL:http://web.mud.com>
  >>
  >> Golly Gosh!  Cover me in eggs and flour and bake me for 40 minutes!

These are commonly referred to on the list as "attributions".

Web pages are usually referenced in angled brackets as above.  

When quoting a log from a game, put at least two spaces at the start
of each line so that when it is quoted it does not become confused
with other conversation text:

--<example>--
I have a maze in my game:

  > look
  You are in a maze of twisty little passages, all alike.

Isn't it neat?
--<example>--

Will be quoted as:

--<example>--
>I have a maze in my game:
>
>  > look
>  You are in a maze of twisty little passages, all alike.
>
>Isn't it neat?
--<example>--

Use a bit of common sense when quoting.  Include enough of the
original message to make sense; no more or less.  Avoid quoting an
entire post with a one line reply (btw, one line replies are bad :).

Also, don't be afraid to change the subject heading to something more
relevant if the topic has strayed somewhat (usually happens to most
threads).  

Oh yeah, and a sensibly sized signature.


4. What is meant by high signal to noise ratio?

The noisy postings include messages which essentially say "I agree!"
and add no extra value, or those that do not relate to the purpose of
the list (like what you had for dinner, how your codebase/driver is
clearly superior to all others in existence and why language such and
such is better than such and such).  Try to keep on topic and you
won't go wrong.  However, the list is infamous for long postings which
start with one topic and end up rambling on about something else
completely different towards the end.  But so long as it is regarding
muds...


5. I just made a post about such and such but no one responded to it!

There could be several reasons why no one has answered to your
posting.  If it was to start a new thread, it could have been that the
topic has just recently been discussed.  Try waiting a while before
bring it back up again.  If it was in answer to a current thread,
other list members will have read it but just might not have anything
to say on that point right then.  


6. What's all this Bubba business?

Bubba, Boffo, Buffy and friends are all typical mud players bred for
test scenarios devised by various list members.  Originally procreated
by J C Lawrence (how, I don't wish to know), they have since come into
widespread use amongst the mud usenet groups (much to J C's amusement).


7. Aaargh!  The traffic is too much!

Perhaps switching to the daily digest mode would help?

Go to <URL:http://www.kanga.nu/lists/listinfo/mud-dev/>, enter your
subscribed email address at the bottom, and then edit your subscription
options as appropriate.


8. How do I access the archives?

List traffic is archived daily and housed at:
<URL:http://www.kanga.nu/archives/MUD-Dev-L/>


9. How do I turn off the list while I'm on holiday?

Go to <URL:http://www.kanga.nu/lists/listinfo/mud-dev/>, enter your
subscribed email address at the bottom, and then edit your subscription
options as appropriate.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
			3. Previous Topics



Here's a list of practically all the topics discussed since the list's
creation up to the end of Dec 98 (early traffic may be missing):

Server design:
 Affects vs. spoofs
 Security concerns of spoofs
 Component based bodies vs. aggregate bodies vs. atomic bodies
 Rooms vs. coordinate spaces vs. mixed forms of the two
 Methods of handling coordinate spaces: neighbourhoods, tree forms
 R-Trees, R*-Trees, 3d arrays, Quad/Oct trees 
 Automated population containers
 Event models
 Internal process models
 Security models
 Multi-threaded server design [conflicts resolution?]
 Database design for a server
 Use of transactional databases in a MUD server
 How to avoid resets
 Parsing systems, and language development tools
 Design of internal MUD languages
 Variations on event-driven design
 Disk vs. memory based designs for MUD servers
 IO Socket efficiencies.
 Telnet protocol and terminal emulation
 Design of Object IDs and Object ID recycling
 Artificial probability systems
 Virtual rooms, virtual objects, virtual mobiles
 Sending mail from within a mud server
 String handling and memory
 Verb handling - global vs. local vs. mixed
 Generic objects
 Object assemblies
 Collision detection
 Client scripting and scripting prevention
 Graphical interfaces
 Must have books for programmers
 Web vs. Telnet

Game design:
 Classes of players and what they want from a game
 Levels vs. level-less vs. abstracted levels vs. level-comparatives
 Keeping a goal progression without levels
 Handling of character inventory and representation of inventory
 Families and their impacts on clans, multi-charring, and tactics
 Character senses, representation and extension
 Re-usable quests or plotlines
 Generic quest creation systems
 Rumour systems, handling rumour propagation, and rumour decay
 Races
 Placement of characters in the MUD-world predator totem-pole
 Handling of character death as an in-game event
 Perma-death vs. resurrection
 Economic systems (and lessons learnt by prior experiments)
 Energy-style ecologies and economies
 Ecologies for MUD worlds
 Inter-player communication systems
 Perceived danger levels for characters
 NPC AI, goal-oriented NPCs, intelligently automating NPCs
 Player characters as NPCs/monsters
 Nutrition
 Wounds and trauma systems
 Combat systems (round based, no rounds, interactive, etc.)
 Combat messages
 Combat scripting and action
 Dynamic descriptions and perception
 Views on the "undead"
 User command interface design
 All about bows, longbows, crossbows, etc.
 Festivals and in-game mud games
 Supporting both RPers and GOPers
 Virtual chemistry/alchemy
 In-game political and social structures 
 Implementing mundane professions (or Nation of Shopkeepers)
 Methods of integrating PK (coexistence with non-PK)
 Handling poison and disease
 Inebriation and drugs
 Dragons - a number of viewpoints
 Spoken and written languages  
 Food - interesting or irritating
 Starting characters or creating characters
 Amalgamud specification document
 Alignment vs. reputation 
 Character positions and rank point system
 Automatic name generation
 Learning and skill progression  
 Classless systems and profession-based systems
 Physics and the mud universe
 Hard sci-fi vs. science fantasy
 Character places of their own
 Character henchmen and servants 
 Thieves - ideas  
 Allowing players to affect the world
 Group play and group dynamics
 Spells and spell-casting systems 
 Characters - heroes, nobodies, or prey species
 Game balance
 Hive minds
 Traps and riddle lists
 Representing character stats - numeric, descriptive and graphic
 Settings for mud worlds
 List members' inspirational fantasy and sci-fi books
 Handling and building of large trackless areas
 Gods and deity systems

Mud Administration/Philosophy
 Lorry's document on wizarding
 The morality of logging and snooping
 Problems with socializers
 Social control and engineering
 Dealing with "problem" players
 Is the virtual world real?
 Gender issues
 Bartle's mud papers
 The purpose of mudding
 Motivating builders and coders
 Role-play vs. Game-Only Play discussion
 PK vs. Non-PK discussions
 The infamous rape discussion 
 Habitat papers and anecdotes
 Overriding players' control of the character 


The following is a list of topics that appeared on the MudDev list in 
1998...


  Server Design:

  Event handling			  Socket programming
  Task parsing				  Byte code
  Java and Javascript			  Dynamic module loading
  DBs and Events			  Java threading
  Let's build a compiler		  Version control
  Intermud communication		  Nested coordinate spaces
  Persistent storage			  Transport layer UDP vs TCP
  Atomic functions			  Algorithms for storing free space
  Mapping - creating bitmaps		  Using SQL databases
  Mapping data into RDBMs		  DevMUD project

  Game Design:

  Mud economy				  Vast areas in muds
  Time travel and logging		  Unique items
  Gods and worshippers			  Senses
  Terrain rendering			  Simulating future history
  Ultima Online's reputation system
  Bad game designs (What we hate about muds)
  Handling log out			  There can be only one
  GRUMPS				  Character development
  Teleportation code			  Avatars
  Leaving characters in the game	  Mud school
  Regulating player created objects	  In game bulletin boards
  Level-less muds			  Describe concept
  World persistence			  Random numbers
  Charm					  Combat intelligence
  Darkness visibility			  Thoughts on languages
  Recursive look			  Equipment fitting
  Implementing god			  Marian's tailor problem
  Room descriptions			  Prescience rules/handling telepathy
  Map-making programs			  Stack-based NPC AI
  Multiple currencies			  Command parsing
  Affordances and Social method		  Fun vs. realism

  Client Design:

  Netscape Clients			  Netscape Gecko
  CORBA, RMI, DCOM			  Graphical Mud perspective
  3D perspective			  Net protocols for mudding
  Client side caching			  Using HTML in muds
  Trusting the client/ security		  DIS - client/server protocol

  Mud Administration/Philosophy:

  Administrative Responsibility		  Impact of the Web on muds
  PK debate summary			  The MLI project
  XShipwars				  The Darkhole tests
  Wired on Ultima Online		  CGDC summary
  Golgotha				  Laws of Online worlds
  Analysis and specification		  Mud web sites
  What is a mud?			  Storytelling vs. Simulation

[courtesy of Jon A. Lambert]


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
				4. Scenarios



Standard scenarios used to demonstrate various mechanisms.


Dragon's Dinner				- Alexander Weidt
~~~~~~~~~~~~~~~

            /(o__.       _____|  \                     |OcO|
 ---------/|-/|-(  ,__)-------|    |   |--------+++++++++/|_| - |_
-----------
       /\/ |/ |/ _ \++++++C+O+M+P+L|E+X+I+T+Y+++++O+F+++/f|  `-'  |
    |\/         / \/      "++++++D+|+S+T+R+I+B+U+T+E+D+( u|       |
 ___| . .____. /______________|
"|++++++S+Y+S+T+E+M+S+\n|_)___(_/-----------
  _| /| |_  || |_             |____|   |        "++++++++\| | | | \
 /__/LL__,) LL__,)                 |  /                    (__|__) \

Pretty picture depicting the famous `` Dragon's Dinner'' problem, by
Jutta Degener. 

The Dragon's dinner problem
---------------------------

One of the original goals for the DOME project was to provide a
parallel/distributed execution environment for an LPmud game
driver. LPmud is programmed in a language called LPC, which is derived
from C and enriched with constructs to enable object oriented
programming, complex data types such as associative arrays and lambda
closures. This is interpreted by the game driver which provides single
threaded execution semantics.  Items in the game are represented by
LPC objects which provide methods specifying how they interact with
other objects in the game.

Consider the following problem (dubbed "Dragon's Dinner"). Assume, in
an asynchronous distributed system, that there are two room objects
(r1, r2) and a door object (d) that connects them. R1 contains a
hungry dragon (hd) and r2 contains an adventurer (a). The door is
currently open, the adventurer has just fled from r1 and is about to
close the door. The dragon, on the other hand, wants to go after the
adventurer. Code for the dragon is something like:

        if (d->is_open())
                hd->move_to(r2);

And the code for closing the door is something like:

        d->close();

Now what if the following happens: The thread that executes the
dragon's action has checked that the door is indeed open, while the
other thread which is concurrently executing on a different processor,
closes the door. This succeeds and the adventurer sees the door
closing. However, when control returns to the dragon's thread, it
still believes that the door is open and steps through it, much to the
surprise of the adventurer who sees the dragon walking through a
closed door, before being devoured by the dragon.

Naturally this is merely a race-condition dictated by the asynchronous
execution of two data-dependent threads. The main goal of the DOME
project is to provide a system where the component objects can be
programmed in a sequential fashion, but have the run-time support
resolve such race-conditions (in a deadlock free manner) so that
parallel execution can be achieved.

Alexander Weidt [June 1995] 



Uncertainty model			- JC Lawrence
~~~~~~~~~~~~~~~~~

Uncertainty model: A representation model for a MUD world or objects based
on the following principles:

  There are three types of objects in the world:

    1) objects which have an uncertain state

    2) objects which have a certain state.

    3) objects which don't exist but retain a certain state.

The state in question about an object can be its exact identity (eg, not
just a key but the key to Castle Krak, not just a worn out sword but The
Sword of the Great God Goo Goo, etc), or the exact state of that
identified object (a gun vs a loaded gun vs a toy gun vs broken gun etc).

The terms:

  -- All objects are indeterminate (unidentified) until identified (see
#1).  Such objects are referred to as "ur-objects", or occasionally
"meta-objects".  

  -- Upon identification ur-objects are "realised" and become
"normal-objects".

  -- Objects that have been lost and are thus candidates for becoming
ur-objects again, or otherwise torn down are termed "lost-objects" or
"limbo-objects".

The underlying concept is that the resolution of the identity of an
object is done at the last possible minute.  All ur-objects have the same
innate possibilities of being any matching normal-object.  The decision on
whether any particular ur-object is actually any particular normal-object
is done only at the moment of successful identification (eg an ur-key
successfully opens Castle Krak).



The Stamp Collector's Dilemma		- Dr. Cat
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lots of people might like stamp collecting in your virtual
world. But those who do will never play with those who like other
features. Should you have stamp collecting in your world?" We know
that there are a wide range of features that people find enjoyable
in online worlds. We also know that some of these features are in
conflict with one another. Given the above, we don't yet know if it
is possible to have a successful world that incorporates all the
features, or whether the design must choose to exclude some of them
in order to keep the players happy.



The Tailor Problem			- Marian Griffith
~~~~~~~~~~~~~~~~~~

Suppose Marian is (role)playing a tailor and in the game that is
a feasible profession. She learns the requisite skills and enjoys
her work, designing clothing for other players, and the opportunity
it provides to talk with many other players.

Along comes Boffo who doesn't like Marian, Tailors in general or is
just in a bad mood. He attacks, and kills, Marian, loots her shop
and leaves her to pick up the pieces.

The question now is: who should protect Marian from this? Marian
herself, being a tailor, has neither the skill nor the interest
in learning to fight and should arguably not be bothered with it.





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

More in part II                                             (Marian)
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...

Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev