[MUD-Dev] MudDev FAQ - part 1

Marian Griffith gryphon at iaehv.nl
Sun Aug 12 12:50:28 New Zealand Standard Time 2001


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



Last modified:   20 September 1999
                 14 November  1999
                 16 Januari   2000
                 13 April     2000
                 11 June      2000
                 24 March     2001

*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:

24-03-2001 -- Added pointers to MUD timelines to the Resources
11-06-2000 -- Frequently asked questions: Some answers reworded as
              per request by list owner, added a new question after nr.3
              Resources: started a list of member muds
13-04-2000 -- Added Topic list for 1999 to part 3. Other lists
              reformatted to make room.
              Resources: Minor modifications to adress, added some muds.
              Started a new resource subject (ftp sites)
              Glossary: Minor modifications
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.  It is suggested that you
lurk for a while to get a gist of how things work on the list.
Reading the list archives can also be very useful.


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. Why all these rules on how to write your message?  

Simply: More signal, less noise.  Per the list owner, each of the
rules and guidelines are things that he has seen help keep a
mailing list on track, help maintain mutual respect among the
members, and help keep the discussions focussed and useful.


5. 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...


6. 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.  


7. 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).


8. 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.


9. How do I access the archives?

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


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

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

Mud Administration/Philosophy
-----------------------------
 The morality of logging and snooping      Lorry's document on wizarding
 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         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
 Bad game designs (What we hate about muds)


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


The following is a list of Topics that appeared on the list in 1999
There is a html version that contains pointers into the archive. This
will be made available as soon as I figure out how :)

New and old topics that were discussed under misleading subject headers
are probably not included.

Server Design
-------------
DevMud Database Design                      Collision Detection
Adjective Server                            Maze Generation
Sockets and Fibers                          Java I/O and Threads
C/C++ Optimization and Profiling            World file parsing using RTTI
Event handling                              Connections (Scaling)
Object Naming and Directories               Distributed Servers/ load balancing
VM Design                                   Sockets Programming
Multithreading                              Macro Languages
QuadTrees                                   Text Parsing
Dispatching Events                          Circular Buffers & Logging
Using HTML and XML                          Singleton Pattern
IMP: Interactive Mud Protocol               Using MySQL in a Mud
System Security                             Random Numbers
Programming Languages for Mud Drivers       Physics and Simulations
Hilbert Curves/Spatial Data Structures      About MOO
Neural Networks/ AI Engines                 ColdStore
Garbage Collection                          Optimized Object Storage
Embedded Languages and Persistence          Telnet and Winsock
OO Multithreaded Mud Programming Languages
Language Parsing & Tokenization/Lex/Bison


Game Design
-----------
Levels vs. Skills                           Skill trees and webs
Combat Tactics/Implementation/Systems       Mobile Movement
Matrix Game System                          Reset Death
Exploration Points                          Personalized Quests
CthulhuMud Driver (Horror themes)           AI Life/Ecologies
Monster AI and Automation                   Renaming Objects
Permadeath                                  Game Balance
Elder Games                                 MUD Economies
Languages                                   Small Game Worlds
Planes of Existence                         Dynamic Room Descriptions
Time Discontinuous Mud                      AutoGenerating Maps
Magic Spells vs. Abilities                  Room Alternatives
Goal Oriented Interfaces                    On Realism
Playing the Monsters                        Roleplaying and Multiple Goals
Roleplaying and Immersion                   Storytelling vs. Simulation
Injury Based Combat                         Tile-based Movement
PK and Monster AI                           Essay on PK
Skill Power vs. Skill Rarity                Weather
Personalizing Mobiles                       Player Stats
Player Capture                              Biosystems
Souvenirs                                   Fair/Unfair Scenarios
Mud History (as created by players/implementors)
Mule characters (Reasons - automation of boring functions)


Client Design
-------------
Protocols - 1                               Client/Server vs. Peer to Peer
Graphic Design Document                     Blending Graphics with Text
Containing Automation                       Graphical Mud Design
Pueblo                                      Public Domain Client


Mud Administration/Philosophy
-----------------------------
Terminology                                 Mud Reviewing
Influential Muds                            The Terrorist Class (paper)
User-Centered Design                        Target Audiences
Censorship                                  Immortals and Trust
Virtual Property                            Gender and Mud Development
GM Touring Company                          Peer Pressure and Cooperation
Online Migration and Population Mobility    Mud vs. Mush Membership
Attracting Players                          History of Online Gaming
Patents/Copyrights/Legalities/Ethics        Undesirable Players
Licensing topics                            Admins as Mortals
Clay Shirky's "Playfulness in 3-D Spaces"



[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 mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list