[MUD-Dev] MudDev FAQ part 1
Marian Griffith
gryphon at iaehv.nl
Thu Apr 13 21:27:48 CEST 2000
Mud-Dev FAQ
part I
-----------
Last modified: 20 September 1999
14 November 1999
16 Januari 2000
13 April 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:
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 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
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
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list