<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Mud-Dev FAQ part I -->
<!--X-From-R13: [nevna Uevssvgu <telcubaNvnrui.ay> -->
<!--X-Date: Sun, 16 Jan 2000 10:59:17 -0800 -->
<!--X-Message-Id: Marcel-1.46-0116143650-bc8Ky&5#catling,demon.nl -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Mud-Dev FAQ part I</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:gryphon#iaehv,nl">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00100.html">Previous</a>
| <a href="msg00098.html">Next</a>
]
Thread:
[ <a href="msg00098.html">Previous</a>
| <a href="msg00100.html">Next</a>
]
Index:
[ <A HREF="author.html#00097">Author</A>
| <A HREF="#00097">Date</A>
| <A HREF="thread.html#00097">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Mud-Dev FAQ part I</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: Mud Dev Mailing list <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI>
<LI><em>Subject</em>: [MUD-Dev] Mud-Dev FAQ part I</LI>
<LI><em>From</em>: Marian Griffith <<A HREF="mailto:gryphon#iaehv,nl">gryphon#iaehv,nl</A>></LI>
<LI><em>Date</em>: Sun, 16 Jan 2000 14:36:50 +0000 (GMT)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Mud-Dev FAQ
part I
-----------
Last modified: 20 September 1999
14 November 1999
16 Januari 2000
*1. Introduction
*2. Frequently Asked Questions
*3. Previous Topics
*4. Scenarios
5. Resources
6. Glossary
7. Changes, To Do & Acknowledgements
(* chapters found in this part of the FAQ)
A web based version of this FAQ can be found at:
<URL:<A HREF="http://www.kanga.nu/FAQs/MUD-Dev-L/">http://www.kanga.nu/FAQs/MUD-Dev-L/</A>>
Please email any corrections, suggestions or constructive criticisms
to Marian Griffith at gryphon#iaehv,nl
Recent Changes:
16-01-2000 -- Faq split in two for size (chapters 1 to 4 and 5 to 7)
Resources: Added several new muds
Made some minor spelling corrections
991114 -- New moderator (Marian Griffith)
990920 -- Resources: Added Raph Koster's website, gaming section.
Glossary: New terms include full world reset, PK, psychological
disinhibition, world state and virtual sociopath.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Introduction
The following may also be found at the list's homepage straddled at
<URL:<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev/">http://www.kanga.nu/lists/listinfo/mud-dev/</A>>.
--<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:<A HREF="http://www.cs.okstate.edu/~jds/mudfaqs.html">http://www.cs.okstate.edu/~jds/mudfaqs.html</A>>. Take some time to
browse through the list's webpage. It may be found at
<URL:<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev/">http://www.kanga.nu/lists/listinfo/mud-dev/</A>>.
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 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#players-r-us,com> wrote:
>>> I just found a cool mud at <URL:<A HREF="http://web.mud.com">http://web.mud.com</A>>
>>
>> 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:<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev/">http://www.kanga.nu/lists/listinfo/mud-dev/</A>>, 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:<A HREF="http://www.kanga.nu/archives/MUD-Dev-L/">http://www.kanga.nu/archives/MUD-Dev-L/</A>>
9. How do I turn off the list while I'm on holiday?
Go to <URL:<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev/">http://www.kanga.nu/lists/listinfo/mud-dev/</A>>, enter your
subscribed email address at the bottom, and then edit your subscription
options as appropriate.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3. Previous Topics
Here's a list of practically all the topics discussed since the list's
creation up to the end of Dec 98 (early traffic may be missing):
Server design:
Affects vs. spoofs
Security concerns of spoofs
Component based bodies vs. aggregate bodies vs. atomic bodies
Rooms vs. coordinate spaces vs. mixed forms of the two
Methods of handling coordinate spaces: neighbourhoods, tree forms
R-Trees, R*-Trees, 3d arrays, Quad/Oct trees
Automated population containers
Event models
Internal process models
Security models
Multi-threaded server design [conflicts resolution?]
Database design for a server
Use of transactional databases in a MUD server
How to avoid resets
Parsing systems, and language development tools
Design of internal MUD languages
Variations on event-driven design
Disk vs. memory based designs for MUD servers
IO Socket efficiencies.
Telnet protocol and terminal emulation
Design of Object IDs and Object ID recycling
Artificial probability systems
Virtual rooms, virtual objects, virtual mobiles
Sending mail from within a mud server
String handling and memory
Verb handling - global vs. local vs. mixed
Generic objects
Object assemblies
Collision detection
Client scripting and scripting prevention
Graphical interfaces
Must have books for programmers
Web vs. Telnet
Game design:
Classes of players and what they want from a game
Levels vs. level-less vs. abstracted levels vs. level-comparatives
Keeping a goal progression without levels
Handling of character inventory and representation of inventory
Families and their impacts on clans, multi-charring, and tactics
Character senses, representation and extension
Re-usable quests or plotlines
Generic quest creation systems
Rumour systems, handling rumour propagation, and rumour decay
Races
Placement of characters in the MUD-world predator totem-pole
Handling of character death as an in-game event
Perma-death vs. resurrection
Economic systems (and lessons learnt by prior experiments)
Energy-style ecologies and economies
Ecologies for MUD worlds
Inter-player communication systems
Perceived danger levels for characters
NPC AI, goal-oriented NPCs, intelligently automating NPCs
Player characters as NPCs/monsters
Nutrition
Wounds and trauma systems
Combat systems (round based, no rounds, interactive, etc.)
Combat messages
Combat scripting and action
Dynamic descriptions and perception
Views on the "undead"
User command interface design
All about bows, longbows, crossbows, etc.
Festivals and in-game mud games
Supporting both RPers and GOPers
Virtual chemistry/alchemy
In-game political and social structures
Implementing mundane professions (or Nation of Shopkeepers)
Methods of integrating PK (coexistence with non-PK)
Handling poison and disease
Inebriation and drugs
Dragons - a number of viewpoints
Spoken and written languages
Food - interesting or irritating
Starting characters or creating characters
Amalgamud specification document
Alignment vs. reputation
Character positions and rank point system
Automatic name generation
Learning and skill progression
Classless systems and profession-based systems
Physics and the mud universe
Hard sci-fi vs. science fantasy
Character places of their own
Character henchmen and servants
Thieves - ideas
Allowing players to affect the world
Group play and group dynamics
Spells and spell-casting systems
Characters - heroes, nobodies, or prey species
Game balance
Hive minds
Traps and riddle lists
Representing character stats - numeric, descriptive and graphic
Settings for mud worlds
List members' inspirational fantasy and sci-fi books
Handling and building of large trackless areas
Gods and deity systems
Mud Administration/Philosophy
Lorry's document on wizarding
The morality of logging and snooping
Problems with socializers
Social control and engineering
Dealing with "problem" players
Is the virtual world real?
Gender issues
Bartle's mud papers
The purpose of mudding
Motivating builders and coders
Role-play vs. Game-Only Play discussion
PK vs. Non-PK discussions
The infamous rape discussion
Habitat papers and anecdotes
Overriding players' control of the character
The following is a list of topics that appeared on the MudDev list in
1998...
Server Design:
Event handling Socket programming
Task parsing Byte code
Java and Javascript Dynamic module loading
DBs and Events Java threading
Let's build a compiler Version control
Intermud communication Nested coordinate spaces
Persistent storage Transport layer UDP vs TCP
Atomic functions Algorithms for storing free space
Mapping - creating bitmaps Using SQL databases
Mapping data into RDBMs DevMUD project
Game Design:
Mud economy Vast areas in muds
Time travel and logging Unique items
Gods and worshippers Senses
Terrain rendering Simulating future history
Ultima Online's reputation system
Bad game designs (What we hate about muds)
Handling log out There can be only one
GRUMPS Character development
Teleportation code Avatars
Leaving characters in the game Mud school
Regulating player created objects In game bulletin boards
Level-less muds Describe concept
World persistence Random numbers
Charm Combat intelligence
Darkness visibility Thoughts on languages
Recursive look Equipment fitting
Implementing god Marian's tailor problem
Room descriptions Prescience rules/handling telepathy
Map-making programs Stack-based NPC AI
Multiple currencies Command parsing
Affordances and Social method Fun vs. realism
Client Design:
Netscape Clients Netscape Gecko
CORBA, RMI, DCOM Graphical Mud perspective
3D perspective Net protocols for mudding
Client side caching Using HTML in muds
Trusting the client/ security DIS - client/server protocol
Mud Administration/Philosophy:
Administrative Responsibility Impact of the Web on muds
PK debate summary The MLI project
XShipwars The Darkhole tests
Wired on Ultima Online CGDC summary
Golgotha Laws of Online worlds
Analysis and specification Mud web sites
What is a mud? Storytelling vs. Simulation
[courtesy of Jon A. Lambert]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. Scenarios
Standard scenarios used to demonstrate various mechanisms.
Dragon's Dinner - Alexander Weidt
~~~~~~~~~~~~~~~
/(o__. _____| \ |OcO|
---------/|-/|-( ,__)-------| | |--------+++++++++/|_| - |_
-----------
/\/ |/ |/ _ \++++++C+O+M+P+L|E+X+I+T+Y+++++O+F+++/f| `-' |
|\/ / \/ "++++++D+|+S+T+R+I+B+U+T+E+D+( u| |
___| . .____. /______________|
"|++++++S+Y+S+T+E+M+S+\n|_)___(_/-----------
_| /| |_ || |_ |____| | "++++++++\| | | | \
/__/LL__,) LL__,) | / (__|__) \
Pretty picture depicting the famous `` Dragon's Dinner'' problem, by
Jutta Degener.
The Dragon's dinner problem
---------------------------
One of the original goals for the DOME project was to provide a
parallel/distributed execution environment for an LPmud game
driver. LPmud is programmed in a language called LPC, which is derived
from C and enriched with constructs to enable object oriented
programming, complex data types such as associative arrays and lambda
closures. This is interpreted by the game driver which provides single
threaded execution semantics. Items in the game are represented by
LPC objects which provide methods specifying how they interact with
other objects in the game.
Consider the following problem (dubbed "Dragon's Dinner"). Assume, in
an asynchronous distributed system, that there are two room objects
(r1, r2) and a door object (d) that connects them. R1 contains a
hungry dragon (hd) and r2 contains an adventurer (a). The door is
currently open, the adventurer has just fled from r1 and is about to
close the door. The dragon, on the other hand, wants to go after the
adventurer. Code for the dragon is something like:
if (d->is_open())
hd->move_to(r2);
And the code for closing the door is something like:
d->close();
Now what if the following happens: The thread that executes the
dragon's action has checked that the door is indeed open, while the
other thread which is concurrently executing on a different processor,
closes the door. This succeeds and the adventurer sees the door
closing. However, when control returns to the dragon's thread, it
still believes that the door is open and steps through it, much to the
surprise of the adventurer who sees the dragon walking through a
closed door, before being devoured by the dragon.
Naturally this is merely a race-condition dictated by the asynchronous
execution of two data-dependent threads. The main goal of the DOME
project is to provide a system where the component objects can be
programmed in a sequential fashion, but have the run-time support
resolve such race-conditions (in a deadlock free manner) so that
parallel execution can be achieved.
Alexander Weidt [June 1995]
Uncertainty model - JC Lawrence
~~~~~~~~~~~~~~~~~
Uncertainty model: A representation model for a MUD world or objects based
on the following principles:
There are three types of objects in the world:
1) objects which have an uncertain state
2) objects which have a certain state.
3) objects which don't exist but retain a certain state.
The state in question about an object can be its exact identity (eg, not
just a key but the key to Castle Krak, not just a worn out sword but The
Sword of the Great God Goo Goo, etc), or the exact state of that
identified object (a gun vs a loaded gun vs a toy gun vs broken gun etc).
The terms:
-- All objects are indeterminate (unidentified) until identified (see
#1). Such objects are referred to as "ur-objects", or occasionally
"meta-objects".
-- Upon identification ur-objects are "realised" and become
"normal-objects".
-- Objects that have been lost and are thus candidates for becoming
ur-objects again, or otherwise torn down are termed "lost-objects" or
"limbo-objects".
The underlying concept is that the resolution of the identity of an
object is done at the last possible minute. All ur-objects have the same
innate possibilities of being any matching normal-object. The decision on
whether any particular ur-object is actually any particular normal-object
is done only at the moment of successful identification (eg an ur-key
successfully opens Castle Krak).
The Stamp Collector's Dilemma - Dr. Cat
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lots of people might like stamp collecting in your virtual
world. But those who do will never play with those who like other
features. Should you have stamp collecting in your world?" We know
that there are a wide range of features that people find enjoyable
in online worlds. We also know that some of these features are in
conflict with one another. Given the above, we don't yet know if it
is possible to have a successful world that incorporates all the
features, or whether the design must choose to exclude some of them
in order to keep the players happy.
The Tailor Problem - Marian Griffith
~~~~~~~~~~~~~~~~~~
Suppose Marian is (role)playing a tailor and in the game that is
a feasible profession. She learns the requisite skills and enjoys
her work, designing clothing for other players, and the opportunity
it provides to talk with many other players.
Along comes Boffo who doesn't like Marian, Tailors in general or is
just in a bad mood. He attacks, and kills, Marian, loots her shop
and leaves her to pick up the pieces.
The question now is: who should protect Marian from this? Marian
herself, being a tailor, has neither the skill nor the interest
in learning to fight and should arguably not be bothered with it.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More in part II (Marian)
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...
Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey
_______________________________________________
MUD-Dev maillist - MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00100.html">[MUD-Dev] Re: Databases</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00098.html">[MUD-Dev] Mud-Dev FAQ part II</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00098.html">[MUD-Dev] Mud-Dev FAQ part II</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00100.html">[MUD-Dev] Re: Databases</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00097"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00097"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><strong><A NAME="00118" HREF="msg00118.html">[MUD-Dev] Valhalla license?</A></strong>,
CFrancy <a href="mailto:CFrancy#aol,com">CFrancy#aol,com</a>, Tue 18 Jan 2000, 08:10 GMT
<UL>
<LI><strong><A NAME="00126" HREF="msg00126.html">Re: [MUD-Dev] Valhalla license?</A></strong>,
Matthew Mihaly <a href="mailto:diablo#best,com">diablo#best,com</a>, Tue 18 Jan 2000, 20:37 GMT
</LI>
<LI><strong><A NAME="00143" HREF="msg00143.html">Re: [MUD-Dev] Valhalla license?</A></strong>,
Richard Woolcock <a href="mailto:KaVir#dial,pipex.com">KaVir#dial,pipex.com</a>, Wed 19 Jan 2000, 02:56 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00098" HREF="msg00098.html">[MUD-Dev] Mud-Dev FAQ part II</A></strong>,
Marian Griffith <a href="mailto:gryphon#iaehv,nl">gryphon#iaehv,nl</a>, Sun 16 Jan 2000, 18:59 GMT
<LI><strong><A NAME="00097" HREF="msg00097.html">[MUD-Dev] Mud-Dev FAQ part I</A></strong>,
Marian Griffith <a href="mailto:gryphon#iaehv,nl">gryphon#iaehv,nl</a>, Sun 16 Jan 2000, 18:59 GMT
<LI><strong><A NAME="00100" HREF="msg00100.html">[MUD-Dev] Re: Databases</A></strong>,
T. Alexander Popiel <a href="mailto:popiel#wolfskeep,com">popiel#wolfskeep,com</a>, Sun 16 Jan 2000, 18:59 GMT
<UL>
<LI><strong><A NAME="00104" HREF="msg00104.html">Re: [MUD-Dev] Re: Databases</A></strong>,
Greg Miller <a href="mailto:gmiller#classic-games,com">gmiller#classic-games,com</a>, Mon 17 Jan 2000, 19:54 GMT
</LI>
</UL>
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00108" HREF="msg00108.html">RE: [MUD-Dev] Re: Databases</A></strong>,
Sellers, Michael <a href="mailto:MSellers#maxis,com">MSellers#maxis,com</a>, Mon 17 Jan 2000, 22:02 GMT
<UL>
<LI><strong><A NAME="00111" HREF="msg00111.html">Re: [MUD-Dev] Re: Databases</A></strong>,
Greg Miller <a href="mailto:gmiller#classic-games,com">gmiller#classic-games,com</a>, Mon 17 Jan 2000, 22:27 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>