Mud-Dev FAQ
Last modified: 8 July 1998
1. Introduction
2. Frequently Asked Questions
3. Previous Topics
4. The Members
5. Scenarios
6. Resources
7. Glossary
8. Changes, To Do & Acknowledgements
Please email any corrections, suggestions or constructive criticisms
to Ling, elkll@student.lboro.ac.uk.
Recent Changes:
980708 -- Snipped signatures from members' bios suggested by Alex Oren. :(
Minor typo and adjustments suggested by JCL. Overdue addition
of MUDDex and Lydia Leong's MUD resource collection to Resources.
"Faucet->Drain economy" term for Glossary added. Stole list
charter from homepage to act as a welcome message of sorts.
Small reorganisation of sections 1,2,3. Added Bartle's early
MUD history to web link in Resources. The Bungle link in Resources
disappeared, added back in, though different site. Quietly dropped
Derrick Jones' bio (was empty).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Introduction
The following may also be found at the list's homepage living at
<URL:
http://www.kanga.nu/~petidomo/lists/mud-dev/index.html>.
--<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.
Thankyou.
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/~petidomo/lists/mud-dev/index.html>. Answers
to most list operation related questions may also be found there.
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@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 encludes
"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 prepend one, eg:
[Bubba]
>On 4 Jan 98 at 22:20, Boffo wrote:
>> Buffy <Buffy@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 twistly 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 twistly 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? Please refer
to your invitation for the appropriate information.
[NB: Since the change to Petidomo, this is no longer supported but
I believe it is being worked on. In fact, 70% done as of Jun/98. ]
8. How do I access the archives?
List traffic is archived daily and housed at:
<URL:
http://www.kanga.nu/~petidomo/lists/mud-dev/index.html>
9. How do I turn off the list while I'm on holiday?
There is a "nomail" feature which keeps you subscribed whilst not sending
you list traffic. It may be activated by mailing mud-dev-request@kanga.nu
with the body of the text as follows:
nomail <your email address>
To turn it back on after the holiday, substitute "mail" for "nomail".
Note the email address is optional.
Posting privileges are retained so you may find the same feature useful
if you post from several email addresses but would like to receive mail at
just one (don't forget to get posting privs for those addresses).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3. Previous Topics
Here's a list of practically all the topics discussed since the list's
creation up to early Jan 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: neighborhoods, 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
Rumor systems, handling rumor propagation, and rumor 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
[courtesy of Jon A. Lambert]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. The Members
Below is not the complete list of members but it does give a good
picture of a small and active cross section. Feel free to post any
corrections or additions to the maintainer.
--------oOOOo--------
John Bertogio
Occupation: head geek for Pulse Research,Inc. <URL:
http://www.paper.net>
Location: Portland, Oregon
Addresses: alexb@internetcds.com (son's account, hits machine at home)
jb@internetcds.com (son's account, hits machine at home)
Webpage: <
http://www.paper.net/mud/> (just samples)
Personal details:
- Married 25 years, three children. Ages: 4, 12 and 19
(sophamore at Reed College in Portland
- Politics: Non-doctrinare Libertarian (Wife: Bleeding heart liberal)
- Excessive use of "", () and ... in posts.
- Table top war gamer in my youth. (Hobby killed by family life)
- Engineering education. Started in 1970. Finished with liberal
arts degree in 1989
- Worked in sales and marketing, first in audio industry, later
moved to computers when audio went goofy (pre-cd).
- Worked for Egghead Software in its salad days...played hundreds
of pc-based computer games.
- Moved to Pulse Research about 10 years ago. Did sales and systems
work. Company has over 2000 newspaper clients in North America
We got into internet systems for newspapers almost 4 years ago
with (god help us) bbs systems.
- Started bbs project with contract developer...very talented person
with serious flaws. We developed and still own world's best
newspaper-oriented bbs system. Of course, no one including us
now cares about that. Used RIP techology...great technology
god-awful CEO. BBS used xbase database at its core.
- Implosion of bbs market led to decision...find a way to move
technology to the web or get a real job and actually work for a
living.
- Moved technology to the web. Used FoxWeb <www.foxweb.com> to link
MS Visual FoxPro dbase. Fired contract developer and rewrote and
expanded all programs from BBS. Something of a trick since
previous programming experience was a D in one quarter of Fortran
in 1971 and a few "Hello World" level projects in basic.
- Got idea a xbase mud was possible from TBBS program Legends (no
connection to mud of the same name)
- Used company technology to build a prototype mud. Mud development
now produces technology used in company products.
Server concepts/features:
- Built on relational database model. Extensive use of SQL. Engine
has very high speed indexed searches.
- Totally persistant world with the ability to handle millions of
objects.
- 1200 by 800 cell base world creates "Civ" style world map. Not
tiled currently...but could be, uses solid color pixels for maps.
- Current world has 1 million base cells with 4 million gateways
connnecting.
- Each cell can have infinite number of traditional mud style rooms.
- Auto generation of some terrain features as areas are exploited
(Example: Mines)
- Stateless elements dealt with by combination of cookies, session
tracking, auto events and auto refresh.
- HTML form-based editing for all system elements.
- System is designed to be very extensible. Adding new features or
skills can often be done in minutes.
- Hybrid NPC/flora/faunua generation.
- Adventurers can form parties which are persistant and gain stats
- PC, NPC and significant creatures use the same data structure.
- Designed to allow active gamemastering
Client concept/features
- Client program is MS IE 4.0...stock, no plugins, no ActiveX
- Hate frames? You'll really hate this one.
- Multiple user interfaces. Selectable
- On-the-fly generated HTML provides most of the content
Game concepts/features:
- Game system based on amalgam of systems: Aftermath, C&S, elements
of AD&D, GURPS and some freeware systems.
- Skill based. No fixed classes. Skill trees encourage differentation.
- Attempts to bring the elements of good single player frp games
to multi-player existance. Inspiration is the "Dream Park"
novels.
- Ability to 'get lost' in a huge world and build a presense
- Managed Pk system with subtle intervention
- Easy player building of elements
- Unusual use of world time elements
- Extensive use of profiles. Player controls plans of character but
does not have absolute control over all actions, especially in
detailed interactions like combat.
- Very limited exposure to numbers. Game has stats on/off command used
for development and testing.
- IC advantages to eating and drinking in taverns.
--------oOOOo--------
Travis S Casey
Occupation: Unix sysadmin
Address: casey@nu.cs.fsu.edu
Personal details:
- Started in '89 on a Tiny variant.
- Really started in '93 on MudDog (LP).
- Accidently wizzed on SWmud (LP).
- Erratic development of a cyberpunk mud.
- Contributed some to the Lima LP mudlib.
- FAQ maintainer for rec.games.design.
- Married with two cats.
--------oOOOo--------
Matt Chatterley
Occupation: Student.
Location: England.
Addresses: neddy@itl.net
caffeine@unreal.org
root@mpc.dyn.ml.org
Personal details:
- Main interests are game design (theoretical), and ways to change
things that are (tm) into things that should be (patent pending).
- Occasional cynic, and critic of online gaming environments.
Server: Caffeine (LP)
--------oOOOo--------
Reed Copsey, Jr.
Occupation:
- Whatever I find at the time (Usually programming or database
administration or setup)
Addy: rdc@efn.org
Personal details:
- Too damn busy to do anything
- Spends lots of time lurking here, and unfortunately doesn't
participate nearly as much as he should and would like to
- Basically a self-taught programmer who spends more time
tinkering and coming up with different ways of doing things
than getting anything productive written
- Is always trying to figure out the best (and cheapest, as he's
currently way in debt) way to learn just about anything he can
get his hands on
Secret Server Project:
- Kolmteist
Server Highlights:
[ Note: This is mostly in design phase. I very recently decided
on a complete rewrite for both the server and the client, so all
that's left that is at all useful is some basic utility-type
classes: socket handling, data structures, string handling, etc... ]
- Written in C++
- Uses a relational database backend, though total persistence
is not (yet) a major goal (though this has changed many times
as he comes up with new arguments for or against it)
- Completely event driven
- Object customization through an internal extension language
- Current design (which will probably last another week
*snicker*) is actually inspired by MS Access (yuck),
with simple extensions being written as very straight forward,
macros on any object, which have the ability to call
user-written procedures, hopefully allowing some semblance
of flexibility in a roundabout way
- Hoping to allow players to use the same macro interface
in a stripped down manner to allow for a fairly high
degree of player-customization and automation (see below)
- A significantly slower-than-average combat system which is
completely unautomated unless macros are used... (Roughly turn
based from the player's POV, with a turn/round once every few
seconds, the avg fight lasting 1-4 minutes)
- Completely disassociation, both in code and in game, of players and
wizards/imms. (builder/administration have no direct in-game form)
- A custom client required for various reasons:
- direct path (completely bypasses the game server) to the
relational database backend, allowing building
and game administration even if the mud is down or the
builder doesn't want to deal with people
- more flexibility in display to allow better-than-ansi color
and text handling parsed client side, inline images, and
some html-ish functionality similar (and inspired by)
various mud extensions chaco add in pueblo (point and click
commands, etc)
- the ability to spawn multiple windows (crucial)
- Will have an account style login, with menu's to choose
which character(s) to play, each of which spawns a separate
window.
- All out of character communication, information, etc will
be directed to the account window (or a private chat-style
window spawned for private, ooc communication)
- the hope is to encourage roleplaying by complete separation
of VR and non-VR commands, both in the commands (without
using a special character like $, @, or #) and in output
--------oOOOo--------
Marc Eyrignoux
Occupation: Student
Address: eyrignou@efrei.fr
Location: Paris, Toulouse (both in France)
Personal details:
- 21 years old
- Role player
- Attempting to code a mud with friends (for school, for entertainment
and for improving in programing)
Server design:
- in C++
- using a relational database (surely MySQL)
- under Linux RedHat 5.0
- multi-threaded, event driven
- still only in project phase
- 1 world: small basic medieval-fantastic world, with basic races
like elves, humans, orks...
- trying to promote the roleplay aspect of the game, with (hopefully)
a quest generator for not having to rewrite another quest every
day.
Client design:
- in Java, graphic oriented
- the most intelligent as possible, but not as much as Nathan's one
--------oOOOo--------
Chris Gray
Occupation: Programmer (UNIX?)
Address: cg@ami-cg.GraySage.Edmonton.AB.CA
Location: Edmonton, Alberta, Canada
Personal details:
- Never really played a MUD other than his own (bar 4 hours on Northern
Crossroads, and some LP experimenting)
- Old enough to be the father of most of you, so his perspectives
might be quite different
- Done very little RPG-ing, but a fair amount of Adventure gaming
- Thinks the Web and C++ suck big time! (shocking!)
- Studied programming languages for AI at Alberta. Attempted to
implement a language called ALAI (A Language for Artificial
Intelligence - original, huh?) but got bogged down.
- Taught computer architecture, programming languages, and adaptive
information systems for the department instead.
- Started but never finished PhD in required internal features for
multi-user protected OSes (at Alberta!)
- Creator of programming language 'Draco' for CP/M, later ported to
Amiga/68k.
- CP/M version of Draco still in Simtel. Docs managed to end up in a
McGraw-Hill book without any permission!
- Worked with Myrias, a parallel computer company.
- Wrote Myrias' ANSI C compiler.
- And Amiga Empire (rewrite of Empire, in Draco of course!)
- Heard about MUDs and wrote a quick and dirty AmigaDUM.
- Myrias went bust two months later (no connection!).
- Now works with the remnants of Myrias which has been brought back to
life.
- After 6+ yrs, AmigaDUM it is now called AmigaMUD and can be found on
Aminet (v1.1).
- AmigaMUD currently being ported to Linux.
--------oOOOo--------
Marian Griffith (De Vries Griffith to be more precise)
Addresses: gryphon@iaehv.nl
Web page: <URL:
http://www.iaehv.nl/users/gryphon>
- Lots of information on the !Overlord project. An attempt to collect
ideas to improve on muds but does not aim at any finished product.
Interests:
- Interest in roleplaying and game world building but will talk about
anything ;) (except for pk because there's nothing to be added that
hasn't been said many times already)
--------oOOOo--------
Michael Hohensee
Occupation: Part time student?
Addresses: michael@sparta.mainstream.net
Personal details:
- 17 yrs of age during March '97
Server: AeMud - Arbitrarily Expandable MUD
Server concepts/features:
- Written in C.
- Treats all objects equally for certain common uses.
- A spiffy and mostly efficient memory-allocation/recycling system.
(Which may actually be kinda pointless, but it was interesting to
code)
- A command queue that is used equally by players and computer-driven
objects.
- Highlights include interactive portals and simulation of liquids.
--------oOOOo--------
Raph Koster
Occupation: Lead designer for Ultima Online, for Origin Systems
Location: Austin TX
Addresses: rkoster@origin.ea.com
Personal details:
- Creative director of mud (not actually director of UO).
- Married to fellow mud designer Kristen Koster, also list member.
- One kid, another on the way.
- BA in English (creative Writing) and in Spanish (Literature), and a
Master of Fine Arts in Creative Writing.
- Age 26.
- Particularly interested in social evolution in virtual environments,
and related issues such as administration of said environments,
methods of social control, user awareness of social context, etc.
- Game and server features that contribute to the above.
- Most everything Mike Sellers listed off ;) such as ecological sim
layers, Maslow, etc :)
Server: LegendMUD, known on there as Ptah
<
http://mud.sig.net>
<
telnet://mud.sig.net:9999>
- Used to run lectures often of interest to the mudding community.
Server concepts/features:
- Has evolved into a weird hybrid of LP and Diku.
Game concepts/features:
- First classless mud.
- Probably the first historical theme gaming mud.
- Attempt to provide a truly fictional immersion, from detailed
hand-designed questing, to carefully crafted and well-written
areas, to output designed to read like prose (see the speech
system for an example of what I mean - adverb support, etc etc).
- Word-based spell system (it doesn't work, wasn't pushed far enough
into the realm of spell language).
Server: Ultima Online, known there as "Designer Dragon"
<
http://www.owo.com>
Game concepts/features:
- World simulation.
- Maslow-based AI system for ecological sim and for basic human
activity (NPC moods, etc)
- Pool-based conversation system.
- Economic sim layer.
- Social control mechanisms (notoriety, etc).
- Dynamic modular quest system.
Noteable facts:
- Appears to be the first big mass market persistent world that really
breaks through and establishes the genre as a commercially viable
one.
- Pretty controversial, plagued with all sorts of problems from day
one, reviews range from stellar to in the toilet. ;)
--------oOOOo--------
Jon A. Lambert
Occupation: contract programmer for 12 years, primarily mainframe DBA
Addresses: jlsysinc@ix.netcom.com
Web page: <
http://www.netcom.com/~jlsysinc>
Personal details:
- Former BBS operator - C64 and later DOS, ran many mud-like games.
- Occasional player on funny little Compuserve mud
- Attempts to rationalize interest in muds as practical professional
education. :P
- Player of paper & pencil games since mid-70s... primarily early
D&D, RoleMaster, Vampyre, Warhammer and Cyberpunk
- Favorite Computer Games - Tradewars, Civilization, Simcity, Hammurabi,
Empire, Railroad Tycoon...Ok just about anything design by Sid Meir
- Age - Too old to rock-n-roll, too young too die.
- Favorite color - blue
- Favorite character - Odysseus Laertes of Ithaca
Secret Project: TychoMud
Mud theme:
- Greek city states - synthesis of historical period 2500-200 BC with
unique interpretations of popular and lesser known mythologies.
Game physics, sciences and medical lore almost wholly based on
Plato's wacky universe. Yes, water does flow upward, at least
through the hole in middle of Earth.
Alternate Themes:
- Original FRPG campaign world.
- Dark postmodern theme.
Server concepts/features:
- Complete persistent objects backed by transactional relational
database
- Event driven and multi-threaded
- Graphical interface to text-based game
- Object-oriented concurrent stack-based mud programming language
(a twisted genetic mutation of Rexx, Java and Ada)
- Graphical user/builder component-level programming/building
Game concepts/features:
- Game system based on RoleMaster FRPG - skill driven system
- Heavy roleplay single account - multi-PC, NPC, or
gamemaster/storyteller
- Deistic intervention (always IC), capricious and encouraged
Direct
- Deistic programmed control of in-game systems (solar, lunar,
climate, oceans, etc.)
- Realistic flora and fauna ecologies (reset/repop - thou shalt not)
- Resource driven economies Social, political and economic driven game
- Magic rare and equipment poor
- Realistic professions
--------oOOOo--------
JC Lawrence
Notes:
MUD-Dev list owner.
All postings written as list owner are identified as such.
Occupation:
Contract programmer for 15+ years, ex-school teacher, printer,
sailor, fisherman and other sundries, small time SF&F writer,
dinosaur, philosopher. Self taught.
Addresses:
claw@null.net (work)
coder@ibm.net (home)
Please use these in preference to all other addresses.
Personal details:
Started MUDding in '84 on Shades, SX MUD (MUD1/MUD2), and still
heavily influenced by same. Was a part of the IOWA project with
Pip Caudrey. Been working on a MUD server on and off since '85.
Major inspirations in chronological order: Shades, MUD2,
Transputers, Marcus Ranum, Uber, Unter, LP, Aber, Tiny*, Northern
Lights, MOO, Stephen White, LambdaMOO, a large bunch of IBM's OS/2
developers, Cool, Interlude (neat!), Dave Engberg, C++, Cold, Mike
Cowlishaw, Legend, ColdX, Greg Hudson, MUQ, BeOS, Inferno, Limbo.
Self-educated in pure math, english literature and religious
philosophy.
Server:
Unnamed, but last referred to as "Murkle". There are several
increasingly sarcastic acronymic expansions of "murkle" that are
left up to the reader to discover.
Server features:
Written in C++. Compleatly persistent world achieved by
transactional persistant store. Event driven heavily
multi-threaded lockless server design. OO internal programming
language ala Python/C. Server has no prior knowledge of the game
mechanics it is hosting. DB (persistant store) is disk based and
contains a full rollback feature for crash recovery, bug hunting
and logging. Same rollbacks allow for limited time travel by
users. Free user programming allowed. No logical difference
between mobiles, NPCs, and players. Players may control multiple
bodies simultaneously. Swarm-type bodies as possible. Players are
heavily abstracted from their characters, which are heavily
abstracted from their character bodies. Players connect to
accounts, from which they select characters to play, which in turn
control bodies. Thous shalt not repop, and thou shalt not reset.
No global namespace in game, players and characters all have
individual private namespaces.
Game features:
Particle based energy-centric resource economy drives and limits
the game world. Magic is merely a side-effect of the particle
economy. Permadeath. Free PK. Extremely high magic world. No
particular interest in RP. GoP-centric. Players and mobiles may
freely steal bodies from each other. The goal is to re-attain
godhood. Resolution of control from body toward player is
generally not possible. Violently fluid programmable combat where
very minor items and affects can be devastating. Skill webs. No
real levels. A human should never have to wait for a machine --
there is no waiting. Heavy use of unstable positive feedback loops
for populations and NPC behaviours.
Scenarios:
Bubba and the Crystalline Tree
The Great God GooGoo and his holy relics
Castle Krack, the Elven Forest, and the Sceptre
UggUgg's mana fight
Orc breeder/fighter/nobles
Mobile population migrations
A farcical justice system
Trash collectors (TC's)
Bubba digging the Panama Canal
...many others...
--------oOOOo--------
Jon Leonard
Occupation: Chip designer
Location: Mountain View, California
Address: jleonard@slimy.com
Web Page: <
http://www.slimy.com/~jleonard/>
Personal details:
- Started MUDing as a freshman in college on the LPmud at
fenris.claremont.edu. I took over admin of it and played
with the server source code until I determined that it would
be easier to start from scratch to get what I wanted. This took
a few years.
- mostly a lurker on the list
- I'm paying for a full-time net connection, so I can host my
MUD, or any other interesting MUDs.
Server: Qxhrptrwzzllp't
<
telnet://slimy.com:2121>
This is a completely from-scratch design, which at this point is
mostly a lisp-like interpreter with a partially written mudlib
running on it.
--------oOOOo--------
Kam Ling Lo (prefers Ling)
Occupation: Electronic & electrical engineering student, will probably
specialise in either microprocessor design or EMC.
Addresses: K.L.Lo-94@student.lboro.ac.uk (or elkll@ for short)
kllo@iee.org
Personal details:
- Merely 21 but feels far too old anyway.
- Purple hair!
- Self-taught computer knowledge, so quite ignorant.
- Broad interests in science in general.
- Pet interests include artificial life and graphic novels.
- Thinks gameplay is of paramount importance.
- Heavily sci-fi orientated. Influences include all C64 and Amiga
games past, various books, cartoons, especially those with 'mechs
in them.
- Somehow managed to accumulate knowledge of various paper games no one
else has ever heard of (eg: Air Eaters Strike Back!)
- More interested in heavy strategy gamer than muds.
Server: Vague (DGD LP)
Mud Theme:
- Post Interstellar War, set in one solar system cut-off for several
hundred/thousand years. Heavily commercialised, whole system
fragmented into legal mush.
cf: Against a Dark Background by Iain M. Banks.
Server concepts/features:
- Just barely working. Currently investigating quaternions.
- Switching from the tradition view that the connection controls a body
in the game to the connection controls a soul which directs the
body. Oughta credit JC Lawrence one day for inspiration/blatant
rip-off.
- This design should eliminate a few design problems and further
minimise creators cheating by forcing creators to code only when
disconnected from the body.
- Would like to implement a translator that compiles a custom
scripting language to LPC.
Game concepts/features:
- Meat of the mud is not remotely mud-like in the traditional sense.
- Players direct a team of agents on a series of missions, for each
mission a 1km x 1km world will be generated.
- Players perceive the game world through the eyes of their agents,
text descriptions will be generated on the fly.
- Heavy emphasis on espionage and covert operations.
cf: Goldeneye
- Design documents available at request.
--------oOOOo--------
David Love (aka Sauron)
Occupation: Student
Address: dlove@kusd.kusd.edu
Personal details:
- Worked as admin on ROCK
- Oldest of six children
- Has a grasp on perl, expanding on C, trying to learn Java
- Enjoys indulging in mindless hack & slash off and on
- Lover of the Final Fantasy series along w/ many console rpg's
- Pastimes: arcade games, paper rpg's, ccg's, computer games (XvT
and War2 among favorites), bbs-ing (anyone remember MajorMUD?)
Server: TWON, a slowly warping version of PennMUSH
Game concepts/features:
- Attempt at a hybrid between the RP aspects of a MUSH and the
in-depth combat style of a MUD
- Faction-based
- Attempts at a working real-time combat system
MU* Theme:
- Attempts to be an epic war story
--------oOOOo--------
Katrina McClelan
Occupation: student of Electrical Engineering/Computer Science (*)
Address: kitkat@directcheck.aries.net
Personal details:
- Interested in rpgs (kinda standard huh?) and sports (as a spectator).
[Any particular preferences?]
- Programmer of 11 years (considering I'm only 21, rather a long time).
- 3+ years completed towards a degree in CS, although I recently
changed to EE for more of a challenge.
- I work full time for the school doing a lame brainless job, but it
pays better than student work, and I get free tuition.
- My dream server would be based on objects and collisions to
resolve damage, to the extreme that even players would be
represented as organic "objects".
- Favourite colour: Cyan/teal.
(*) from occupation, if I were to get a "real job" it'd be as a UNIX
systems administrator or a UNIX programmer, both of which I am more
than qualified to do :)
Server: Erizon (katmud v1.0)
Server concepts/features:
- Mostly it is a remake of diku with smarter mobs, better handling of
most things, cleaner code. To someone that has only been exposed
to circle/merc/rom type muds, my code would look really awesome.
To the members of this list, the code is average at best.
I'd implement something better if I had time to.
- It is becoming a little more event driven now that I've gone to
a segmented combat engine.
- Strongly based on AD&D rules, which despite lacking realism
are reasonably simple to understand/program.
- It has delayed casting/combat which uses what is more or less
an event engine to resolve them.
- Mobs are allowed to have default eq if they don't load with it.
- I have a string sharing table and a zone reset engine that is
pre-processed for speed (if a zone loads 10 orcs, the mud will
load 1 orc from disk and memcpy it onto 10 mobile structs).
Nothing flashy, but it craps all over stock mud.
- Has a terminal server which allows menu based OLC with
lib curses.
Game concepts/features:
- Faithfully based on AD&D.
- It uses the maintained powers psionics model from AD&D.
--------oOOOo--------
Greg Munt
I lurk too much. Partly due to being unemployed (maybe I should petition
BT(*) for free local calls), being overwhelmed by list traffic, and partly
due to the fact that I have been in New York for the past 3 or 4 months. Whilst
there, I got engaged to a Bahamian. Maybe my email address will swap a 'uk' for
a 'bs' soon (reasonably likely). At least local calls are free there. Grrr.
Found muds in early '94, in the form of a Tiny derivative, UglyMUG (one of
the few muds on JANET(**)'s PAD network at that time). Left six months later to
join the administration of a derivative of Ugly. 18 months after that, was
running it. 6 months after that, had been kicked out of the admin team, and
banned - now bitter, twisted, and forever opposed to democratic muds. The
so-called "Admin Wars" produced a satirical re-telling of Star Wars,
where I was reduced to a dribbling figure, shivering over a VIC-20 and a
2400 baud modem. (I kid you not.)
My 'real' experience has been working in COBOL/DB2 for British Steel.
Currently I'm trying to use that to get a job. Alternatively I might
have an opportunity as a Junior Games Programmer (with CodeMasters -
possibly UK-only company? *shrug*)! Who said mudding was a waste of time? :)
Since selling the VIC-20 (*koff*), I hacked up a mud from scratch, and
after six months produced "Frontiers". The website (at
http://www.uni-corn.demon.co.uk) was produced - not by me, I hasten to
add - in 6 days, and is infinitely better. It was around this time that I
began reading rec.games.mud.admin, and Martin Keegan wandered onto
Frontiers. (Read DejaNews for the results;)
Now, Frontiers has been closed down, and I have started anew. First
efforts are always worst efforts - probably - but I learnt a lot from it,
and continue to plod through. Current project is called "Ubiquity", and
is, I am quite proud to announce, at the design stage (Frontiers started
at the implementation stage *doh*). At the moment, it is nothing more
than a BBS with talker extensions, but I plan to later turn that into an
underlying command shell for a coordinate-based, all-singing, all-dancing
mud (yes, I'm still working that bit out). The command shell idea was
actually suggested (or I evolved it from one of his ideas, I can't
quite remember) by Nathan Yospe, on this list. This time I am going
slowly, working on the things I know about first, rather than tackling
everything at once, and achieving nothing (see Frontiers).
Age: 24.
Height: 6'8 (which may be irrelevant - though it's always
sort of relevant to people, when they meet me).
Likes: unconventional ideas.
Dislikes: the accepted norm (see DejaNews).
Worst attribute: 50% of my time is spent planning; 5% of my
time is spent carrying out those plans.
Best attribute: Selfless, emotional.
Best thing about my life: I'm so in love...
Worst thing about my life: ...with someone who lives thousands of miles away.
Claim to fame: I once met Ling's brother. He compared me to
John Lennon, which I still find amusing.
-------------------------------------------------------------------------------
There is a 99% chance that I hate and despise your miserable little existence.
(*) British Telecommunications charge 1UKP/hour for local phone calls. Scowl.
(**) The Joint Academic NETwork - now forms the *.ac.uk part of the Internet.
--------oOOOo--------
Alex Oren
Occupation: Programmer in a consulting firm.
Address: alexo@bigfoot.com
MUD Background:
- AD&D DM since '85. Had a brief and fascinating encounter with an LP.
- Got interested in OO MUD server design in '95.
- Posted a request for help[*] (22-5-96) that started a correspondence
which later evolved into the "CC list".
- Due to RL pressures reduced to lurking status. The server,
unimplemented, now gathering dust in some obscure corner of my
mind.
Server concepts/features:
Affects.
[*]
http://search.dejanews.com/msgid.xp?MID=<31a32684.293427796@news.ibm.net.il>
--------oOOOo--------
Mike Sellers
Occupation: Chief Creative Officer for The Big Network; Chief Alchemist of
Online Alchemy. Okay, both of those are real titles, but they boil down to
being a game and game-world designer.
Some previous occupations: creator of Meridian 59, user interface designer,
software engineer, animal fertility lab scientist, fantasy miniature
sculptor, movie extra (Apocalypse Now), and one-time circus roustabout.
Location: Pleasanton, California
Address: mike@online-alchemy.com
Interests and Personal stuff:
- Homeostatic mechanisms in world politics, ecologies, and economies
- Maslovian-inspired AI for NPCs and mobiles
- creation of strong communities online
- creating games that provide a truly immersive experience
- making online entertainment into a viable business
- being happily married with six kids :-)
--------oOOOo--------
Vadim Tkachenko
Occupation: Web Developer & Java reusable code manager
Location: Quad Cities (border of IA/IL), USA
Address: vadimt@4cs.com office
Webpage: <URL:
http://206.139.13.63/~vt/gradient> [moved to below?]
<URL:
http://gatekeeper.4cs.com/~vt/gradient> [temporary]
There is an access restriction based on the rule:
I want to know who you are. Register, and get it free.
Personal details:
- Age 32, programming since 1988
- Reusable multi-tiered architectures
- Consistent game model
- Balanced extensible world
- Like to design MUDs more than to play them (as they exist now)
- Hundreds, if not thousands, hours spent playing one-player RPGs, the
favorites are Eye of Beholder, Ultima Underworld
Server: Gradient
Status: Skeleton
Features:
- Implemented in Java, based on the reusable client/server framework
model, code-named Jukebox (BTW, today (Feb0298) accepted as a
corporate standard :-)
- Inherently multithreaded, multi-protocol, multi-model (you can just
plug in the protocol adaptor, business logic adaptor and Voila!
You have it)
- Persistent objects as DB (now looking at Voyager -
<URL:
http://www.objectspace.com/voyager>), no resets
- External NPC engine, based on the logic and interaction history
- Multi-protocol clients: stock telnet clients as well as specialized
graphical ones (DB implications here)
- Ability to invoke the scripts as URL references (for advanced players
:-) - you specify the URL, it's being interpreted and executed
Game model:
- Consistent object interaction model, based on property tree,
representing weighted features/subfeatures/sub-subfeatures and the
actions result of which depends on the property values (including
regexp on the property values). Actor/Target/Context property
evaluation model is engaged, which allows easy implementation of
the gradient worlds (BTW, this is where the name comes from).
- Game balance is considered critical for the world playability's sake
- Gods balanced with their incarnations, energy balance between the
gods and worshipers.
- Magic energy transformations (fixed input, accumulation by accidental
targets, transformations to other kinds of energy)
- Soul and body are separated, resurrection (or, more exactly, body
capture) for bodies, perma-death for souls
- Advanced NPCs indistinguishable from players (ideally), control over
which may be taken by admins/players (body capture)
- Stubborn unique objects which have own idea how to behave depending
on the conditions (location, current ownership, etc.)
- Alternate realities and terraforming for players (initial idea from
Castle Amber by Roger Zelazny)
- Object-oriented structure: you can have the inheritance
(object/weapon/blade/katana)
- Objects hidden inside one another: the more advanced you become, the
more you're able to identify/use the object.
--------oOOOo--------
Greg Underwood
Occupation: Foole :P Student, primarily, Simulation design Co-Op to pay
the bills. (as a side note, I am probably one of the younger members of
the list, weighing in at age 23)
Addresses: s001gmu@nova.wright.edu
Location: Dayton, Ohio, USA (yeah, the place where they had the Bosnia
Peace Talks a couple years back).
Personal details:
- Used to work on Diku/merc/rom derivatives, specifically Eternity of
Discord. (the code base of which has survived in various forms
under a couple of of different names, which surprises the heck
out of me.. it sucks. :)
- Currently working on a home-grown project with a friend who is
currently a lurker on the list.
Server concept/features:
- Key features include event driver, object orientated nature of the
program, mSQL relational database for info management and non-io
specific, requiring specialised clients to transform data into
something more palatable.
Game concept/features:
- The major foci of the project include a MUCH more realistic combat
model from Diku. Key differences include combat between one
versus many results in one dead opponent v.quickly, usually.
- Heavy magic world with well defined metaphysics, which defines the
physics of the world.
- Primarily a numbers/resource management game, rp will be a side
effect due to the multi-player nature.
- Pkill & "permanent" deaths.
- Player characters will include self-preservation code/instincts,
player can override instincts for complete control but without
overriding, can't get character to behave self-destructively.
--------oOOOo--------
Adam Wiggins
Occupation: Lead programmer for Cinematix Studios, Inc
Location: Phoenix, Arizona, USA.
Address: nightfall@inficad.com
Personal details:
- Primary interests for a mud are enhanced 'realism' and internal
consistency of the game world, mainly getting rid of all the
old kludges (hitpoints, experience, levels, classes, tell)
and creating a much more detailed and complex world.
- Proponent of skill-based systems which encourage roleplaying
by making the charcter one plays act and respond as befitting
their race/temperment.
Server: Strife mud
--------oOOOo--------
Nathan F. Yospe
Occupation: Software engineer, writer, cartoonist. (yes, really, all of these)
Addresses: yospe@hawaii.edu
Location: Hawaii
Personal details:
- Interests in elements of solid state and materials science, and
biochem, specializing in molecular genetics and crossover areas
with biomedical science.
- My goals are not particularly relevant to this list, aside from the
fact that I have written sucess at them into the ancient history
of my mud universe, by some anonymous other, fifty years after
I'll likely be dust. The goals: complete supplemental immune
system simulated by organic nanotechnology.
Server: Physmud++
Server concepts/features:
- Mud built by first defining fundamental laws and then constructing the
world in a lego-like manner.
- Functions as a client with a single server, every text transaction and
most decision-tree transactions are handled clientside and passed to
the server as tokened sequences.
- Physmud++ has evolved in the time that I have been on this list, from
a Diku-like C++ mud to what it is today, completely unique.
Server: GURU
Server concepts/features:
- Started 2.5 yrs ago, completion date of December 2002
- Graphical, VR orientated, mass scale distributed fantasy world.
- Designed from the world go for scaleability and most of the
innovations in Physmud++ are really those of the GURU, simplified
and tested in an environment that I can, peice at a time, actually
accomplish.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5. 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 envirionment for an LPmud game
driver. LPmud is programmed in a langauge 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 specifiying 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 occassionally
"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 underlieing 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
sucessfully opens Castle Krak).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6. Resources
Anything notable and mud related that should be read/investigated.
Webpages:
A Rape in Cyberspace
<URL:
http://www.apocalypse.org/pub/u/lpb/muddex/vv.html>
The infamous article by Julian Dibbell.
How it really happened...
<URL:
http://www.apocalypse.org/pub/u/lpb/muddex/bartle.txt>
Richard Bartle's early history of MUDs.
Killers Have More Fun
<URL:
http://www.wired.com/wired/6.05/ultima.html>
An article by Amy Jo Kim.
Lucasfilm's Habitat:
<URL:
http://www.communities.com/company/papers/lessons.html>
Detailed document about an ambitious graphical mud.
Lydia Leong's MUD resource collection:
<URL:
http://www.godlike.com/muds/>
[Raph K]
Marian Griffith's !Overlord project:
<URL:
http://www.iaehv.nl/users/gryphon>
Full of information useful to mud designer/admins.
MUDDex:
<URL:
http://www.apocalypse.org/pub/u/lpb/muddex/>
A collection of documents including Bartle's, Dibbell's mentioned
above. [Raph K]
Muds:
AlphaWorld: <URL:
http://www.cs.cuc.edu/~sopwith/aw/>
Anyone care to comment?
AmigaMUD: <URL:
telnet://mud.myrias.com:23>
Chris Gray's custom mud. Moving site. [Jun 1998]
Armageddon: <URL:
telnet://ginka.armageddon.org:4050>
To my knowledge the ONLY truly successful full-bore RP environment
based on a Diku-style server with full combat and the like. Often
cited as such at any rate. [Raph K]
Aturion Dynasty: <URL:
http://aturion.com:4444>
Almost all the muds done by Owen Emlen have interesting design
features to them too. [Raph K]
[See also EmlenMud II]
Avalon: <URL:
http://www.avalon-rpg.com>
Commercial text muds. Avalon has an interesting newbie tutorial
mode, and room description generation code that is nifty
too. [Raph K]
ColdMUD: <URL:
telnet://ice.cold.org:1138>
Uses the Genesis driver.
CoolMUD: <URL:
http://csclub.uwaterloo.ca/u/sfwhite/coolftp>
Incredibly elegant server design. [JCL]
Dark Sun Online: <URL:
http://www.ssionline.com>
Commercial graphical mud with turn-based combat in a real-time
environment. [Raph K]
DartMUD: <URL:
telnet://dartmud.com:2525>
A very ambitious LP mud with lots of good ideas which never seemed
to have gelled together correctly. Plenty of bugs. A sequel is
being worked on.
DragonRealms (Gemstone): <URL:
http://dragonrealms.net>
Gemstone was and prolly still is the most popular mud in the
world, period. It evolved into DragonRealms. [Raph K]
Duris: <URL:
telnet://duris.org:6666>
A pk mud with economy?! [Down? Jul 1998]
Eternal City, The: <URL:
telnet://eternal-city.com:6370>
Commercial mud using the Cold server.
EmlenMud II: <URL:
http://degu.cs.indiana.edu:6669/em2.html>
Looks like Owen Emlen is in the process of making a new mud.
Furcadia: <URL:
http://www.realtime.net/furcadia/>
A commercial graphical mud by Dr. Cat.
LambdaMOO: <URL:
http://vesta.physics.ucla.edu/~smolin/lambda/>
One of the pages for this MOO.
LegendMUD: <URL:
telnet://mud.aus.sig.net:9999>
The first classless mud, strange diku/LP hybrid. See Raph
Koster's bio.
Medievia: <URL:
telnet://medievia.intersphere.com:4000>
The most popular free gaming mud I know of. Pioneered the use of
things like in-game spam ads for themselves and lack of due credit
given for code (:P) but also has things like ASCII map terrain,
large algorithmically generated areas, etc. [Raph K]
M59: <URL:
http://www.3do/meridian>
Ask Mike S.
Mortal Conquest: <URL:
telnet://199.74.98.37:9999>
That game I can't remember with the whities and the darkies. [JCL]
By Own Emlen. [Down, 1st March]
MUD2: <URL:
telnet://mud2.com:23>
<URL:
http://www.mud2.com>
A licensed copy run by Bartle.
MUQ: <URL:
http://www5.biostr.washington.edu/~jsp/muq.html>
Northern Lights:
<URL:
http://www.ludd.luth.se/mud/aber/northern_lights.html>
<URL:
telnet://aber.ludd.luth.se:6715>
Realms, The: <URL:
http://www.realmserver.com>
Realms is a commercial graphical mud from Sierra.
Shades: <URL:
telnet://games.world.co.uk:23>
TODO - get Bartle's comment here.
Toril: <URL:
telnet://torilmud.com:9999>
One of two offshoots of Sojourn (other being Duris).
Trash: <URL:
http://games.world.co.uk>
Somewhere in the webpage with Shades. [Down, Jun 1998]
Tron: <URL:
telnet://polaris.king.ac.uk:3000>
An out and out pk mud, more of an arcade game using ASCII maps than
a mud in the conventional sense. Not one for the faint hearted.
Should you want a game but can't find anyone, drop me a bell.
Start learning with disc or spider. Be prepared to break your
keyboard. [Ling]
UOL: <URL:
http://www.ultimaonline.com>
Ask Raph K.
Worlds of Carnage: <URL:telnet//carnage.labs.emich.edu:4000>
The first Diku mud with an internal scripting language, called
"easyacts." This code formed the basis of the MobProgs put into
Merc 2.2. LegendMUD is a spiritual offshoot of Carnage, and Cythera is
a literal offshoot. (Interestingly, Damion Schubert, a designer on
M59, was also a Carnage immort alum). Imperium Gothique's scripting
was derived from either mobprogs or Carnage, not sure which. Carnage
definitely had a lot of influence on the world of Dikudom. [Raph K]
Notable muds yet to be found:
ColdMUD:
Not to be confused with ColdX/Genesis. Cannot find info on.
IOWA Project, The:
TODO - dig up references in Bartle's MUD survey, browse LambdaMOO
ftp site and MUDDev.
Keywords: MirrorWorld, Gods, Pippin ("Pip") Caudry.
Island:
Did this not die some time back? [Tho Keegan may yet resurrect it]
MUD1:
Although MUD2 is up above.
Sojourn:
Died. Will have to hang. Unlikely to find any info. Spawned Toril
and Duris, main difference being the way PK is handled. Search
Dejanews for references? (thanx Raph K)
Habitat:
TODO - look at Electronic Communities (Inc). Hope JCL accidently
sends me some URL's.
Not so mud related webpages:
Anti-Mac interface: <URL:
http://www.acm.org/cacm/AUG96/antimac.htm>
AI Nodes/ANN: <URL:
http://206.107.246.21/packhste/5/>
BSP trees: <URL:
http://reality.sgi.com/bspfaq/index.shtml>
Image formats (esp PPM): <URL:
http://www.dcs.ed.ac.uk/~mxr/gfx/2d-lo.html>
R-Trees: <URL:
http://www.cs.cuhk.hk/~drsam/methods.html>
VR programming tutorial:
<URL:
http://www.cs.virginia.edu/~rg3h/networkVR/paper.html>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7. Glossary of Terms
The list has managed to come up with its own jargon. Here are some of
the current buzzwords:
Cooperative role-playing: Refers to a specific kind of RP where each
player's personal 'storyline' is paramount. All players are aware
of, and sensitive to, the needs of each player for their story, and
all actions are completely consentual. This is a type of play often
found on MUSHes.
Event: A system design alternative to polling loops. Objects generate
events, which are processed in their proper order by the event
handler. This is frequently clearer and far more efficient,
especially with large numbers of objects. Examples are a torch
generating an event to burn out in two hours, or a spell generating
an event for an earthquake to occur in four seconds.
Faucet->Drain economy: A virtual economic system wherein there is an
ongoing influx of new items into the game (usually via a reset model)
and a hopefully corresponding outflow, usually accomplished through
object attrition involving equipment danage, rent fees, etc. It is worth
noting that traditionally, designers have been unable to easily come up
with a big enough drain to handle all the 'water.' This is as opposed to
a "Closed economy" in which an attempt is made to close the loop,
creating new objects only when old ones are used up. [Raph K]
Fixed random seeding: Using a fixed value (such as a character's
unique ID, or the character's position in XYZ space) to seed the
random number generator, assuring that the same random number will
always be rolled if the circumstances are exactly the same, but
requiring no storage. This allows parts of the world or its
behaviours to be dynamically generated from the seed value as
needed, and yet to have each "new copy" be the same as all the
others because the seed calue hasn't changed.
Functional roleplaying: A kind of gaming, whilst GoP motivated, is heavily
tailored to the in-game reality. There's no thee's or thou's, or even
pretension of IC/OOC separation, but an awful lot of attention is spent
by the player in working his character thru the game realities rules as
it controls and affects his character. Examples would include
negotiation of reputation and influence systems, votes, political systems,
clans and guilds and other similar structures, etc. Appearance is not
the key. Function is. [JCL]
Global namespace: Referring to the fact that most muds rely on characters
(and sometimes other objects) are given a single and unique name.
Typing 'who' on most muds gives you a list of these; if you see
someone named Bob you know that he is the only Bob in the world, and
can't be confused with anyone else. This is as compared to a system
of generated descriptions to which players can attach proper names
as they please, which may or may not overlap or match up with the
names assigned by other players.
GoP: Short for 'game-oriented play' or possible 'goal-oriented play'.
This is usually a competitive style of play usually oriented around
the accumlation of various resources (money, power, combat ability).
Levels: For the purpose of keeping discussions generic, this term may be
used as an abstract measurement of a character's ability, skill or
expertise whether the game system is level-based or skill-based.
Eg: "If a low level character tries XXX a high level character..."
The precise details are not of interest as opposed to the impact and
result of the undefined imbalance.
Lockless server or DB:
Events request objects from the DB.
If the object is not in the cache, the DB loads the object.
The DB replies to the event with a read-only shared reference to the
object.
The event is added to the "interested parties" list for the object.
If the event attempts to modify the object, a new local, event-specific
copy of the object is made, and the changes are made to that. A copy
of the original reference however is still kept.
The event (loosely) attempts to keep track of what members of the
object it referenced.
During the execution of an event. all external IO is buffered and held.
Upon the event terminating it compares its copy of the original object
(the local reference) with the object that's actually in the DB (may
have been changed by events commiting during the current event's
execution). Some intelligence is attempted here to only compare those
values etc which were referenced by the event.
Should the original copy and the current-in-DB copy compare OK, then
the event commits, the IO is released, and all its changes in its
written-to copies are commited atomically. This is the
Compare&Commit, or C&C.
If the C&C fails, the event is thrown away, all the copies are released,
the IO is discarded, and the event is rescheduled to try again.
There is also some background intelligence here where the DB watches
the objects that are affected by event's C&C'ing, and will signal the
other events that are members of those object's interested party list
that they may be invalidated by the other event's C&C and so should
kill themselves and reschedule.
ref: DEMOS and the DOME project (JCL)
Markup language: An internal set of codes used by a server to generate
semi-dynamic messages. An example is "%c dives %I %o" which might result
in "Bubba dives behind the wall", "A woman dives into the pool", or
any number of other strings.
mud or MUD: It is not an acronym. It is a collective term for all the
types of games discussed on this list, including both RP and GoP.
[NB: Another description may be found at the list's homepage
<URL:
http://www.kanga.nu/~petidomo/lists/mud-dev/index.html> ]
Object: Because most of the servers discussed here are
object-oriented, the word object is being used in its general
programming sense to include characters, locations, inanimate items,
and so forth, rather than referring to only inanimate items as is
typical in some mud servers.
Realism: This is not necessarily corespondance to the real world, but
rather refers to internal consistency. In many cases using the
working of real world systems (physics, for example) is a good
example for how to build a consistent system for a game world.
To quote:
"This is, of course, partially my invention, to suit the gaming world
we are working on, and is not intended to mirror Real Life - just to
borrow enough bits and pieces from it, so that it is recognized as
somewhat structured (rather than totally whimsical) to the player."
- Holly Sommer
Repop: See Reset.
Reset: Usually a function called in a mud at irregular intervals, the
purpose of which is to put back the game, or some fragment of the
game or game world into a known state. Typically this might mean
locking an opened door, or resurrecting an NPC that was killed by a
player and putting him back to guard the door, Resets and repops
are common on games that promote repetitive actions for advancement.
Skill net: A single layered skill web. Skills are directly weighted to
each other. See skill web (NY)
Skill tree: A skill system where skills have a single parent and
several children. A skills at the bottom of the tree being very
specialised. Skills higher up the tree will affect the value of
skills further down.
Skill web: a non-heirarchical two layered skill system wherin each
skill is weight-related to an arbitrary number of attributes, and
the improvement of skills therefore automatically improves related
skills. Examples of skills might be rowing and flycasting, examples
of attributes, strength (upper arm) and precision (forearm).
[Note: I triple weight my skill web, so that there are direct
connections to the condition of the character's body and mind, and
so that the resiliance of same are improved by conditioning. Nathan Y]
[Note 2: The web is modeled after a simple neural net design I found in
Dr. Dobbs' Journal. Nathan Y]
Verb binding: Attaching verbs to an object, such as 'fly' to a
jetpack. The command essentially does not exist when you don't have
the jetpack.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8. Changes, To Do & Acknowledgements
980506 -- Moved the changes list to a section in the back, only the most
changes since the last post appear here now. Appended Holly
Sommer quote to "realism" glossary term. Added "functional
roleplaying" glossary term. Updated Frequently Asked Questions.
Added networking tutorial web link to Resources. Added Bungle
web link to Resources.
980428 -- New scenarios section,a couple more glossary terms and more
member's bios.
980308 -- Mailing list invite.
980301 -- Even more addresses for the resource section.
980201 -- More bios, more addresses for the resource section.
980107 -- Added a few more questions. Previous topics now has its own
universe as suggested by Adam Wiggins. Plonked in a resources
section. Took out standard technical terms as suggested by Adam
Wiggins.
971201 -- FAQ created.
To Do:
Conventions of example scenarios (Bubba, Boffo, Buffy, etc)
List of references for specific scenarios/docs (Habitat/Great God GooGoo,
Crystalline Tree, recognising Sting in the weapons shop, etc).
Solutions for the scenarios?
Obtain addresses for the muds in the resource section.
Statement of topic definition (cf welcome message).
Update previous topics section.
Acknowledgments:
Everyone on the list who contributed with a bio, everyone on the
list who posts and special thanks to Jon A. Lambert, Adam Wiggins,
Nathan Yospe, Raph Koster and lastly but definitely not the least,
J C Lawrence.