February 2001
- Rogue-Like Mud? Ron Moore
- Issues of Copyright (was Ebay bans character selling) geoffrey@yorku.ca
- brazil the_logos@www.achaea.com
- Dogma 2001 Frank Crowell
- Dogma 2001 David Turner
- FW: Article on Global Verbs & Bulk Bug Christopher Allen
- Slightly extreme reaction to IP and auction Frank Crowell
- Slightly extreme reaction to IP and auction Greg Underwood
- Slightly extreme reaction to IP and auction the_logos@www.achaea.com
- bandwidth the_logos@www.achaea.com
- Is immersipresense going to make a come back? Frank Crowell
- New Scientist Article... Eric Rhea
- New Scientist Article... Alistair Milne
- New Scientist Article... rayzam
- New Scientist Article... Hans-Henrik Staerfeldt
- New Scientist Article... rayzam
- volunteers the_logos@www.achaea.com
- volunteers Timothy Dang
- volunteers Jon Morrow
- volunteers the_logos@www.achaea.com
- volunteers Timothy Dang
- The Aedon rule system (was: FW: Article on Global Verbs & Bulk Bug) Federico Di Gregorio
- Content is Not King (from First Monday) Bruce
- [sweng-gamedev] BYOND game development system (fwd) J C Lawrence
- [sweng-gamedev] BYOND game development system (fwd) J C Lawrence
- Medievia interview Koster, Raph
- Medievia interview Alex
- Medievia interview Madman Across the Water
- Medievia interview Koster, Raph
- Medievia interview Joe O'Connor
- Medievia interview pyrographer@comcast.net
- Medievia interview J C Lawrence
- FW: Article on Data Inheritance Christopher Allen
- FW: Article on Data Inheritance Kevin Littlejohn
- job opportunities Koster, Raph
- Those (in)famous EQ stories bubba@bubba.mud
- Writing articles (was: FW: Article on Data Inheritance) Bruce
- Writing articles (was: FW: Article on Data Inheritance) the_logos@www.achaea.com
- Room-based vs. Coordinate based[Was semi-graphical muds] Ben Chambers
- Room-based vs. Coordinate based[Was semi-graphical muds] Warren Powell
- Room-based vs. Coordinate based[Was semi-graphical muds] the_logos@www.achaea.com
- Room-based vs. Coordinate based[Was semi-graphical muds] J C Lawrence
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC Russ Lewis
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC J C Lawrence
- Modular Design Issues RFC Bruce
- Modular Design Issues RFC J C Lawrence
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC J C Lawrence
- Modular Design Issues RFC Daniel.Harman@barclayscapital.com
- Modular Design Issues RFC Greg Lewis
- Modular Design Issues RFC Daniel.Harman@barclayscapital.com
- Modular Design Issues RFC Ben Chambers
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC J C Lawrence
- Modular Design Issues RFC J C Lawrence
- Modular Design Issues RFC Scion Altera
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC Kwon Ekstrom
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC Kwon Ekstrom
- Modular Design Issues RFC Ryan Rhodes
- Modular Design Issues RFC Kwon Ekstrom
- Modular Design Issues RFC Scion Altera
- Modular Design Issues RFC Jo Dillon
- Modular Design Issues RFC J C Lawrence
- Party at DundraCon Christopher Allen
- MUD-Dev digest, Vol 1 #246 - 6 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #246 - 6 msgs the_logos@www.achaea.com
- Roundtable status, changes, and future. J C Lawrence
- Roundtable status, changes, and future. J C Lawrence
- Persistent Worlds Ryan Rhodes
- Persistent Worlds J C Lawrence
- Persistent Worlds Hulbert, Leland
- Persistent Worlds J C Lawrence
- Persistent Worlds John Buehler
- Persistent Worlds J C Lawrence
- Persistent Worlds John Buehler
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds John Buehler
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds John Buehler
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Travis Casey
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Scion Altera
- Persistent Worlds John Buehler
- Persistent Worlds J C Lawrence
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds J C Lawrence
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Travis Casey
- Persistent Worlds Hulbert, Leland
- Persistent Worlds Jon Lambert
Ryan Rhodes wrote:
> World Persistence being, as far as I can understand it, a world
> which persists in state through reboots. To accomplish this I am
> assuming you are somehow running the world directly from disk, which
> is my first question.
> Question: In the runtime environment of your worlds do you have
> both a copy of the world in memory and a copy of the world on
> disk?
Depending on the size of the object cache and the size of database it
is certainly possible that all objects could exist in memory at one
time. This happens to me quite a bit since I have not built all
enough objects. It isn't necessary though. The only minimum
requirements are that the objects needed for a particular operation to
succeed need be in memory.
> Or do all games actions directly manipulate the DB?
Nope. I never manipulate the database directly. It's done as a a
backend task. The object manager subsystem stands as an independent
task. I use functional partitioning, although the concept is similar
to components. Subsystems are inherently concurrent, that is once
initialized they control their own execution requirements via thread
pooling. They also maintain their own message queues and interfaces.
Database manipulation is buried within the object manager and exist as
successive translation layers. Currently I can use any relational
database that supports ODBC and SQL 92. I also support various DBMs,
the NT registry, and some other experiments.
> If you run strait from disk, what memory caching techniques do you
> use to improve performance? Did you implement these yourself are
> have you used off the shelf software?
I've use both actually and at the same time. Let me explain. The
object manager runs in process space with the rest of the server.
Theoretically it's decoupled enough to run as an IPC, RPC or piped
process, although I've never attempted it. My feeling is and was that
it would always run best in process space anyways.
The object manager cache is contiguous reusable and fixed memory
space. Although fixed it can be adjusted on the fly manually. The
cache is maintained by a thread of the object manager. A sweep is made
of the cache and valid objects that have changed are updated to the
database. The sweep also ages _all_ objects by incrementing a byte
counter. When that counter reaches 255 the object is marked as
removable. When an access is attempted against an object and it is
found in the cache that counter is set to 0. If it is not found in
the cache it is loaded in from the database. New objects are
allocated to the first available free location. A free location is one
not occupied by an object or one where the object counter is 255.
This threshold of 255 is also manually configurable on the fly. This
is not original. I borrowed it from the way IBM's OS/390 manages
memory pages. It's simple and works well. I borrow a lot of old gems
from big blue. :-)
Now back to the off the shelf stuff. As a database backend I've used
Oracle, Access, and Watcom SQL. Each of these has their own caching
mechanisms. The Oracle server ran on a different machine and easily
cached the whole database in memory on that machine. No problem there
as long as it resides on a high speed network. My Access ran on the
same machine and is not configurable (at least not the parts of
interest to me). In fact it doesn't help at all, wasting memory that
I've already carefully managed myself. OTOH Watcom SQL runs as
another process on the same machine and you can turn off cacheing
completely! The interface is actually a nice lightweight IPC
implementation. This is sort of ideal. Not quite though. My homespun
database still performs better.
One thing to remember when using RDMS technologies is that cacheing
mechanisms are optimized for generalized access patterns. In the case
of some muds, especially those using object relationships, these
access patterns will almost always be sub-optimal (MOO, Cold). This
is not so for some other mud designs like (Diku, ROM). I believe I
posted an extensive post on the reasons why. The basic Diku design
also allows one to leverage referential integrity features of RDBMs.
Others have played around using using SQL with OO servers and have
posted their experiences. A big problem with these experiments with
existing OO codebases is that by design the objects are not
reflective. Internally yes, externally no. Because of that it those
experiments I've seen with RDMSs have stored the bulk of Object data
in BLOBs. Obviously that negates virtually all of the query features
of SQL beyond simple indexed access.
The basic problem is this. The object model is fundamentally
different from the relational model. Inheritence has to be fudged.
In the OO world children know their parents, but parents do not know
their children. In the relational world the opposite is true.
How Java and the JDBC handle these differences is something I don't
have the experience in. I do know that Poet, an popular object
database, has a JDBC.
> Question: Is it even neccesary to run the game strait from disk to
> effectively have a persistent world?
Obviously from above, no.
> Can you run the game from memory and just back the whole changing
> world up to storage for reboots?
Yes. I believe Mushes do this. I'm currently working on a ROM mud
that is mostly persistent and uses a similar approach. I believe many
LPMuds are using mublibs that are at least partially persistent.
> Does this make maintaining persistence somehow more difficult?
No the above method makes it easy. But it doesn't solve certain
problems. More below under WHY?
> Beyond the question of how your doing it, more importantly is why?
> I mean this most seriously as I'm trying to weigh the advantages. I
> understand your projects are less geared towards PK and more towards
> realistic simulations. The benefits I can come up with so far are:
I don't see any relationship between PK and Simulations. PK is a
moral concept that may be present in simulations as any other style of
game.
Why? Simulations need to save state. Not necessarily intervening
states. Look at Civilization, Railroad Tycoon or SimCity. How is
state saved? Simple. The player hits the save button.
So why didn't I just build in an administrative save button. Well the
save button approach doesn't solve the problem of fault tolerance.
Nor does it solve the problems in light of concurrency, incomplete
transactions, etc. Now it is certainly acceptable for a single player
of Civilization to roll back to the last time you saved. Or is it?
How about a multiplayer game of Civilization? Maybe not. Because
positions and plans may have been revealed that are now rolled back.
Generally when one saves such a game all action freezes while the
system saves its state. Is that acceptable in mud where maybe 20-100+
players are playing? How often can you get away doing that save of
state? Not too often.
Then we have the ugly problem of concurrency. Concurrency in my
system is hard-threaded. Other servers like MUQ and Cold concurrency
is soft-threaded. Yet it's still present.
The problem here with the global save technique is establishing a
quiesce point. One must both prevent new messages from being issued
or processed, and allow outstanding tasks to complete. And since most
tasks (transactions) end up reissuing messages, one must then save the
also state of the message queues. In short while a global save
mechanism works, they aren't really satisfactory as a restart point
for crash recovery. You still go back to an arbitrary point in time.
I wanted the latest complete transactions recovery. To do this
required building my own transaction commit and rollback mechanisms.
I didn't need to do this. But part of my design requirements of the
programming language was to make commit and rollback transparent to
the user programmer. Traditional application programming puts the
onus on the programmer. (think COBOL/DB2, PRO-C/Oracle, or maybe
not.. :-P )
> While pondering this, it occured to me that the developers role
> might become something different in this context. For the world to
> remain persistant it would now seem not enough to just store the
> original version of a room or object in the DB. You are now storing
> the element in all of its various states.
I dont do this. If a room changes it changes.. the original is lost
forever. The only exception is I maintain seperate heirarchies of
prototypes. Those prototypes are used to generate critters and
things. The only time I do this with rooms is with player housing.
These are prototypes of houses, castles, etc. that player purchases
from an architect and then customizes oneself.
> Question: If you are storing the original version of a room in the
> DB and it becomes burnt down, are you now storing the burnt
> version and completely throwing away the original? Or did you
> store both versions from the begining?
I never thought of that. But then I haven't implemented any sort of
in game terraforming outside of the housing stuff I mentioned above.
However it is a very interesting idea though. :-)
> In general this principle would seem to persist with the world, that
> you are no longer just adding creatures or items. You are now
> required to provide for the way these things are generated and
> repopulate.
Not really. There is fundamentally no difference between the
groundhog day style resets of Diku-style games and fancy population
algorithms. In fact some of the latest Diku derivatives do indeed
take the current population of a given item or critter into question
in determining whether to execute a reset. The major difference is
mainly in appearance, perception and level of abstraction from
"realism".
Now that I said that. I made major changes in the resets system when
I converted a certain ROM mud to be persistent. ;-)
> Question: Do you see putting together a more PK action oriented
> game with a persistent world as opposed ideas? What elements of a
> pk action world might in fact be less workable in a persistent
> world setup?
I don't see any relationship design-wise between PK and persistence.
PK or PvP is a game moral concept. It certainly does exist in
simulations.
> reflective. We do not use dynamic inheritence or dynamic
> attributes.
> Question: Will this system map to an RDBMs?
If you extend a class with an attribute then NO. Unless the JDBC
supports what I call DDL or data definition language. I may be wrong,
but the dynamic class loading of Java isn't going to be very useful in
this situation if that class is one that is persisted.
> for storage. Now if this is true, it would seem its not just
> runtime morphic systems that won't map, but all systems which are
> adding classes at runtime.
Yes. In fact outside of people working on Mud Servers, in all my
research I've only found a research project by an IBM engineer who was
looking at this sort of runtime dynamic database schema.
> Question: How would you suggest mapping collections to an RDBMS.
> Normally every field would map to a column in the corresponding
> classes table. An object field would end up mapping to a forein
> key reference to another table where that object would be stored.
> Collections like java Vectors, Hashtables, and arrays seem to pose
> a problem. I don't think I would want each object in the
> collection to map to a foreign key in the previous item in the
> lists table.
Map each collection type to a relationship table. If every object in
the system gets a unique key then any particular collection type can
be mapped to a single table.
For example:
Monster table
ID 10101
Name
Inventory "Monster_Inventory"
Worn "Monster_Worn"
...
GenericVector table
OwnerID 10101
CollectionName "Monster_Inventory"
Order "1"
ItemID 50505
...more rows for this collection
another row in same table
OwnerID 10101
CollectionName "Monster_Worn"
Order "1"
ItemID 50515
...more rows
Thing table
ID 50505
Name Sword
...
You need not use a string for collection name. You could assign
unique ids to specific collections as well. If the collection is not
ordered then you don't need a field to hold that. If the collection
type is keyed or an associated array then you'd need to hold more info
or keys.
--
--* Jon A. Lambert - TychoMUD Email:tychomud@ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *-- - Persistent Worlds Ryan Rhodes
- Persistent Worlds Jon Lambert
- Persistent Worlds Ryan Rhodes
- Persistent Worlds Jon Lambert
- Persistent Worlds Ryan Rhodes
- Persistent Worlds J C Lawrence
- Persistent Worlds Jon Lambert
- Persistent Worlds Ryan Rhodes
- Persistent Worlds Miroslav Silovic
- Persistent Worlds Bruce
- Persistent Worlds Ryan Rhodes
- Persistent Worlds Phillip Lenhardt
- Persistent Worlds Miroslav Silovic
- Persistent Worlds Ryan Rhodes
- Persistent Worlds Jon Lambert
- Persistent Worlds J C Lawrence
- Persistent Worlds John Buehler
- Persistent Worlds J C Lawrence
- Persistent Worlds John Buehler
- Persistent Worlds J C Lawrence
- Persistent Worlds John Buehler
- Persistent Worlds msew
- Persistent Worlds rayzam
- Persistent Worlds John Buehler
- Persistent Worlds rayzam
- Persistent Worlds Travis Casey
- Persistent Worlds John Buehler
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds John Buehler
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds John Buehler
- Persistent Worlds Tess Lowe
- Persistent Worlds John Buehler
- Persistent Worlds Travis Casey
- Persistent Worlds John Buehler
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds John Buehler
- Persistent Worlds Kevin Littlejohn
- Persistent Worlds J C Lawrence
- Persistent Worlds Tess Lowe
- Persistent Worlds J C Lawrence
- Persistent Worlds Dave Rickey
- Persistent Worlds Eli Stevens
- Persistent Worlds John Buehler
- Persistent Worlds Nathan F.Yospe
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Nathan F.Yospe
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Jon Lambert
- Persistent Worlds J C Lawrence
- Persistent Worlds Jon Lambert
- Persistent Worlds J C Lawrence
- Persistent Worlds rayzam
- Persistent Worlds Nathan F.Yospe
- Persistent Worlds Christopher Allen
- Persistent Worlds Travis Casey
- Persistent Worlds J C Lawrence
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Travis Casey
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Travis Casey
- Persistent Worlds Corey Crawford
- Persistent Worlds Marian Griffith
- Persistent Worlds Travis Casey
- Persistent Worlds the_logos@www.achaea.com
- Persistent Worlds Marian Griffith
- Persistent Worlds Brandon J. Rickman
- Persistent Worlds Nathan F.Yospe
- Persistent Worlds J C Lawrence
- Persistent Worlds Ryan Rhodes
- MMORPGs: Pointers to System Specs? Lars Duening
- MMORPGs: Pointers to System Specs? Jake Song
- Shameless Plug. SavantKnowsAll@cs.com
- Shameless Plug. Travis Casey
- Shameless Plug. J C Lawrence
- Shameless Plug. SavantKnowsAll@cs.com
- Shameless Plug. J C Lawrence
- Shameless Plug. SavantKnowsAll@cs.com
- Shameless Plug. Christopher Allen
- Shameless Plug. J C Lawrence
- Shameless Plug. SavantKnowsAll@cs.com
- Shameless Plug. J C Lawrence
- enforced roleplaying the_logos@www.achaea.com
- enforced roleplaying Sanvean
- enforced roleplaying the_logos@www.achaea.com
- enforced roleplaying Christopher Allen
- enforced roleplaying Mark Watson
- enforced roleplaying Klyde Beattie
- enforced roleplaying the_logos@www.achaea.com
- Real Life Consequences Corey Crawford
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences J C Lawrence
- Real Life Consequences rayzam
- Real Life Consequences John Buehler
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences J C Lawrence
- Real Life Consequences Christopher Allen
- Real Life Consequences Kerem HADIMLI
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences Kevin Littlejohn
- Real Life Consequences John Buehler
- Real Life Consequences Kevin Littlejohn
- Real Life Consequences J C Lawrence
- Real Life Consequences John Buehler
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences Jeff Freeman
- Real Life Consequences Marian Griffith
- Real Life Consequences David Loeser
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences John Buehler
- Real Life Consequences David Loeser
- Real Life Consequences Rodney Lorrimar
- Real Life Consequences Michael Tresca
- Real Life Consequences J C Lawrence
- Real Life Consequences John Buehler
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences Daniel.Harman@barclayscapital.com
- Real Life Consequences Marc Bowden
- Real Life Consequences J C Lawrence
- Real Life Consequences Mike Niederer
- Real Life Consequences Jon Morrow
- Real Life Consequences Jeff Freeman
- Real Life Consequences John Buehler
- Real Life Consequences the_logos@www.achaea.com
- Real Life Consequences John Buehler
- Real Life Consequences Jeff Freeman
- Real Life Consequences John Buehler
- Real Life Consequences Jon Morrow
- Real Life Consequences J C Lawrence
- Real Life Consequences Jon Morrow
- Real Life Consequences J C Lawrence
- Real Life Consequences Michael Tresca
- Real Life Consequences msew
- Real Life Consequences Adam Casbarian
- MUD-Dev digest, Vol 1 #249 - 28 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #249 - 28 msgs the_logos@www.achaea.com
- MUD-Dev digest, Vol 1 #249 - 28 msgs the_logos@www.achaea.com
- Job search Dr. Cat
- Pay for Play (or Commercial Rolecall) Ryan Rhodes
- Pay for Play (or Commercial Rolecall) J C Lawrence
- Pay for Play (or Commercial Rolecall) Marc Bowden
- Pay for Play (or Commercial Rolecall) Jeff Freeman
- Pay for Play (or Commercial Rolecall) the_logos@www.achaea.com
- Pay for Play (or Commercial Rolecall) Ryan Rhodes
- Pay for Play (or Commercial Rolecall) the_logos@www.achaea.com
- Pay for Play (or Commercial Rolecall) Dave Rickey
- Pay for Play (or Commercial Rolecall) Jeff Freeman
- Pay for Play (or Commercial Rolecall) Ananda Dawnsinger
- Pay for Play (or Commercial Rolecall) Dave Rickey
- Pay for Play (or Commercial Rolecall) Dave Rickey
- Pay for Play (or Commercial Rolecall) S. Patrick Gallaty
- Pay for Play (or Commercial Rolecall) Jeff Freeman
- Pay for Play (or Commercial Rolecall) Jon Lambert
- Pay for Play (or Commercial Rolecall) J C Lawrence
- Pay for Play (or Commercial Rolecall) the_logos@www.achaea.com
- Pay for Play (or Commercial Rolecall) Jon Morrow
- A new MUD-standard Ben Chambers
- A new MUD-standard Adam Casbarian
- A new MUD-standard Ben Chambers
- A new MUD-standard Christopher Allen
- A new MUD-standard Ben Greear
- A new MUD-standard Ben Chambers
- A new MUD-standard Ben Greear
- A new MUD-standard Ben Chambers
- A new MUD-standard rayzam
- A new MUD-standard katroutt@home.com
- A new MUD-standard Frank Crowell
- A new MUD-standard Bryce Harrington
- A new MUD-standard Frank Crowell
- A new MUD-standard Hans-Henrik Staerfeldt
- A new MUD-standard Ben Chambers
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Jon Lambert
- A new MUD-standard Frank Crowell
- A new MUD-standard Ryan Rhodes
- A new MUD-standard Ben Chambers
- A new MUD-standard Bruce
- A new MUD-standard Ben Chambers
- A new MUD-standard Chris Jones
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Ben Chambers
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard John Bertoglio
- A new MUD-standard J C Lawrence
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard J C Lawrence
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Bruce
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Kevin Littlejohn
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Bruce
- A new MUD-standard Kevin Littlejohn
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Ben Chambers
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Ben Chambers
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard Kevin Littlejohn
- A new MUD-standard Ben Chambers
- A new MUD-standard Kwon Ekstrom
- A new MUD-standard the_logos@www.achaea.com
- A new MUD-standard Frank Crowell
- Community (was: Semi Graphical Muds) Marian Griffith
- Defining a community Klyde Beattie
- Defining a community Dave Rickey
- Defining a community Jeff Freeman
- Defining a community Dave Rickey
- Defining a community Mark Watson
- Defining a community Koster, Raph
- Defining a community Ola Fosheim Grøstad
- "Doing a dungeon" (was: Permadeath or Not?) msew
- "Doing a dungeon" (was: Permadeath or Not?) the_logos@www.achaea.com
- "Doing a dungeon" (was: Permadeath or Not?) Daniel.Harman@barclayscapital.com
- "Doing a dungeon" (was: Permadeath or Not?) msew
- "Doing a dungeon" (was: Permadeath or Not?) Vincent Archer
- "Doing a dungeon" (was: Permadeath or Not?) msew
- "Doing a dungeon" (was: Permadeath or Not?) Brian Hook
- "Doing a dungeon" (was: Permadeath or Not?) John Buehler
- "Doing a dungeon" (was: Permadeath or Not?) Brian Hook
- "Doing a dungeon" (was: Permadeath or Not?) John Buehler
- "Doing a dungeon" (was: Permadeath or Not?) Brian 'Psychochild' Green
- "Doing a dungeon" (was: Permadeath or Not?) Travis Nixon
- "Doing a dungeon" (was: Permadeath or Not?) Koster, Raph
- "Doing a dungeon" (was: Permadeath or Not?) Travis Casey
- "Doing a dungeon" (was: Permadeath or Not?) Vincent Archer
- "Doing a dungeon" (was: Permadeath or Not?) msew
- "Doing a dungeon" (was: Permadeath or Not?) Brian Hook
- "Doing a dungeon" (was: Permadeath or Not?) Dave Rickey
- MUD Schools Ben Chambers
- MUD Schools David Bennett
- MUD Schools Alex
- MUD Schools David Bennett
- MUD Schools Marc Bowden
- MUD Schools Ben Chambers
- MUD Schools Michael Tresca
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") Tess Lowe
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") John Buehler
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") Ananda Dawnsinger
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") David Bennett
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") Adam Casbarian
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") J C Lawrence
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") rayzam
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") Travis Nixon
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") the_logos@www.achaea.com
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") Marian Griffith
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") John Buehler
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") Kwon Ekstrom
- Teaching ethics in MUDs (was "An essay on d00dism and the MMORPG") the_logos@www.achaea.com
- Teaching ethics in MUDs Tess Lowe
- Teaching ethics in MUDs John Buehler
- Mozilla as a client (was: A new MUD-standard) Bruce
- Mozilla as a client (was: A new MUD-standard) Kwon Ekstrom
- GoPers are ants at RP picnics!... was Pay for Play(or commercial rolecall) Jon Lambert
- Condsiders Daniel.Harman@barclayscapital.com
- Condsiders J C Lawrence
- Condsiders Jeff Freeman
- Condsiders J C Lawrence
- Condsiders Marc Bowden
- Condsiders Ryan Rhodes
- Condsiders Klyde Beattie
- Condsiders John Buehler
- Condsiders Klyde Beattie
- Condsiders rayzam
- Condsiders John Buehler
- (no subject) msew
- Phantasy Star online article Koster, Raph
- Phantasy Star online article the_logos@www.achaea.com
- Phantasy Star online article Koster, Raph
- Phantasy Star online article the_logos@www.achaea.com
- Phantasy Star online article msew
- Myn ynd Wymyn (was Teaching ethics in MUDs) Ananda Dawnsinger
- Myn ynd Wymyn (was Teaching ethics in MUDs) Ananda Dawnsinger
- Myn ynd Wymyn (was Teaching ethics in MUDs) Adam Casbarian
- Myn ynd Wymyn (was Teaching ethics in MUDs) Ananda Dawnsinger
- Item Distribution in Areas Jim S
- Item Distribution in Areas Brian Hook
- Item Distribution in Areas Vincent Archer
- Item Distribution in Areas rayzam
- Item Distribution in Areas Dave Rickey
- Game Developer Conference Proceedings? Ola Fosheim Grøstad
- Game Developer Conference Proceedings? Koster, Raph
- Game Developer Conference Proceedings? Timothy Dang
- Game Developer Conference Proceedings? the_logos@www.achaea.com
- New Bartle article Koster, Raph
- New Bartle article Richard A. Bartle
- New Bartle article Koster, Raph
- New Bartle article Richard A. Bartle
- New Bartle article the_logos@www.achaea.com
- New Bartle article rayzam
- New Bartle article Dave Rickey
- New Bartle article Richard A. Bartle
- New Bartle article Dave Rickey
- New Bartle article Daniel James
- New Bartle article the_logos@www.achaea.com
- New Bartle article Freeman, Jeff
- New Bartle article the_logos@www.achaea.com
- New Bartle article Vincent Archer
- New Bartle article the_logos@www.achaea.com
- New Bartle article Vincent Archer
- New Bartle article the_logos@www.achaea.com
- New Bartle article Adam Martin
- New Bartle article Richard A. Bartle
- New Bartle article Jeff Freeman
- New Bartle article Richard A. Bartle
- New Bartle article John Buehler
- New Bartle article Richard A. Bartle
- New Bartle article John Buehler
- New Bartle article Richard A. Bartle
- New Bartle article johnbue@msn.com
- New Bartle article Richard A. Bartle
- New Bartle article John Buehler
- New Bartle article Richard A. Bartle
- New Bartle article John Buehler
- New Bartle article Richard A. Bartle
- New Bartle article John Buehler
- New Bartle article Phillip Lenhardt
- New Bartle article the_logos@www.achaea.com
- New Bartle article John Buehler
- New Bartle article msew
- New Bartle article Richard A. Bartle
- New Bartle article Brian Hook
- New Bartle article Richard A. Bartle
- New Bartle article Vincent Archer
- New Bartle article Richard A. Bartle
- New Bartle article the_logos@www.achaea.com
- New Bartle article Jon Lambert
- New Bartle article the_logos@www.achaea.com
- New Bartle article Brian Hook
- New Bartle article the_logos@www.achaea.com
- New Bartle article Brian Hook
- New Bartle article the_logos@www.achaea.com
- New Bartle article Adam Martin
- New Bartle article Dave Rickey
- New Bartle article Brian Hook
- New Bartle article Dave Rickey
- New Bartle article Steve {Bloo} Daniels
- New Bartle article Daniel.Harman@barclayscapital.com
- New Bartle article Dave Rickey
- New Bartle article Vincent Archer
- New Bartle article Vincent Archer
- New Bartle article Travis Casey
- New Bartle article msew
- New Bartle article Richard A. Bartle
- New Bartle article Travis Casey
- New Bartle article Richard A. Bartle
- New Bartle article the_logos@www.achaea.com
- New Bartle article Richard A. Bartle
- New Bartle article the_logos@www.achaea.com
- New Bartle article Richard A. Bartle
- New Bartle article the_logos@www.achaea.com
- New Bartle article Richard A. Bartle
- New Bartle article Dave Rickey
- New Bartle article Richard A. Bartle
- New Bartle article Dave Rickey
- New Bartle article Richard A. Bartle
- New Bartle article Dave Rickey
- New Bartle article Richard A. Bartle
- New Bartle article Marc Bowden
- New Bartle article Richard A. Bartle
- New Bartle article rayzam
- New Bartle article Daniel.Harman@barclayscapital.com
- New Bartle article Richard A. Bartle
- New Bartle article Daniel.Harman@barclayscapital.com
- New Bartle article Blane Bramble
- New Bartle article Richard A. Bartle
- New Bartle article Gaffney, Jeremy
- New Bartle article Richard A. Bartle
- New Bartle article Dave Rickey
- New Bartle article Richard A. Bartle
- New Bartle article Freeman, Jeff
- New Bartle article Wells, Thomas
- New Bartle article Trump
- New Bartle article Brian Hook
- New Bartle article Travis Nixon
- New Bartle article Brian Hook
- New Bartle article Daniel James
- New Bartle article Brian Hook
- New Bartle article John Buehler
- New Bartle article Koster, Raph
- New Bartle article msew
- New Bartle article Vincent Archer
- New Bartle article shren
- New Bartle article Vincent Archer
- New Bartle article Timothy Dang
- New Bartle article Richard A. Bartle
- New Bartle article msew
- New Bartle article Koster, Raph
- New Bartle article John Buehler
- New Bartle article Koster, Raph
- New Bartle article John Buehler
- New Bartle article Paul Schwanz - Enterprise Services
- New Bartle article Sanvean
- New Bartle article the_logos@www.achaea.com
- New Bartle article Brian Hook
- New Bartle article the_logos@www.achaea.com
- New Bartle article Travis Casey
- New Bartle article the_logos@www.achaea.com
- New Bartle article Travis Casey
- New Bartle article Travis Casey
- New Bartle article Timothy Dang
- New Bartle article Travis Casey
- New Bartle article Marc Bowden
- New Bartle article Marc Bowden
- New Bartle article Matt Mihaly
- everquest banning sarapis@www.achaea.com
- Fallen Age (was Shameless Plug) SavantKnowsAll@cs.com
- Fallen Age (was Shameless Plug) the_logos@www.achaea.com
- Fallen Age (was Shameless Plug) SavantKnowsAll@cs.com
- Fallen Age (was Shameless Plug) the_logos@www.achaea.com
- Fallen Age (was Shameless Plug) SavantKnowsAll@cs.com
- Fallen Age (was Shameless Plug) Brian 'Psychochild' Green
- Fallen Age (was Shameless Plug) the_logos@www.achaea.com
- Fallen Age (was Shameless Plug) SavantKnowsAll@cs.com
- Myn ynd Wymyn (was Teaching ethics in MUDs) Adam Casbarian
- Myn ynd Wymyn (was Teaching ethics in MUDs) Willowreed@aol.com
- Yamauchi Puts the Industry In Its Place msew
- Item drain was Item Distribution in Areas Brian Hook
- MUD-Dev digest, Vol 1 #255 - 27 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #255 - 27 msgs John Buehler
- realism and unrealism Travis Casey
- realism and unrealism Federico Di Gregorio
- realism and unrealism Marian Griffith
- Limiting rewards was Interesting EQ rant (very long quote) Brian Hook
- Limiting rewards was Interesting EQ rant (very long quote) S. Patrick Gallaty
- Limiting rewards was Interesting EQ rant (very long quote) Brian Hook
- Limiting rewards was Interesting EQ rant (very long quote) Daniel.Harman@barclayscapital.com
- Limiting rewards was Interesting EQ rant (very long quote) the_logos@www.achaea.com
- Damaging items was New Bartle article Brian Hook
- Damaging items was New Bartle article msew
- Damaging items was New Bartle article Brian Hook
- Damaging items was New Bartle article Travis Casey
- Damaging items was New Bartle article John Buehler
- Damaging items was New Bartle article Travis Casey
- Damaging items was New Bartle article Marian Griffith
- MUD-Dev digest, Vol 1 #255 - 27 msgs Dr. Cat
- Distributed Processing John Buehler
- Distributed Processing Gaffney, Jeremy
- Distributed Processing John Buehler
- Distributed Processing Vincent Archer
- Distributed Processing Timothy Dang
- Distributed Processing Adam Martin
- Distributed Processing shren
- Distributed Processing Gaffney, Jeremy
- Quests + No Spoils (was: Interesting EQ rant) Corey Crawford
- Quests + No Spoils (was: Interesting EQ rant) the_logos@www.achaea.com
- Where's The Line Drawn Kyndig
- Where's The Line Drawn KaVir@dial.pipex.com
- Where's The Line Drawn Frank Crowell
- Multiple Character Races John Buehler
- Multiple Character Races Brian Hook
- Multiple Character Races Caliban Tiresias Darklock
- Multiple Character Races John Buehler
- Multiple Character Races Koster, Raph
- Multiple Character Races John Buehler
- Multiple Character Races ghovs
- Multiple Character Races the_logos@www.achaea.com
- Multiple Character Races Michael Tresca
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) Vincent Archer
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Zak Jarvis
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Koster, Raph
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Koster, Raph
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) Freeman, Jeff
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Jeff Freeman
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) shren
- FW: Interesting EQ rant (very long quote) Freeman, Jeff
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Jon Lambert
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Travis Nixon
- FW: Interesting EQ rant (very long quote) F. Randall Farmer
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Nathan F.Yospe
- FW: Interesting EQ rant (very long quote) J. Coleman
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) Koster, Raph
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) Kevin Littlejohn
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Travis Casey
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) Paul Schwanz - Enterprise Services
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) J. Coleman
- FW: Interesting EQ rant (very long quote) Freeman, Jeff
- FW: Interesting EQ rant (very long quote) Brian Hook
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Travis Casey
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Travis Casey
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Travis Casey
- FW: Interesting EQ rant (very long quote) Matt Mihaly
- FW: Interesting EQ rant (very long quote) Travis Casey
- FW: Interesting EQ rant (very long quote) shren
- FW: Interesting EQ rant (very long quote) Paul Schwanz - Enterprise Services
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Kevin Littlejohn
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Kevin Littlejohn
- FW: Interesting EQ rant (very long quote) John Buehler
- FW: Interesting EQ rant (very long quote) Adam Martin
- FW: Interesting EQ rant (very long quote) the_logos@www.achaea.com
- FW: Interesting EQ rant (very long quote) Vincent Archer
- FW: Interesting EQ rant (very long quote) holding99@mindspring.com
- FW: Interesting EQ rant (very long quote) david.l.smith@home.com
- FW: Interesting EQ rant (very long quote) holding99@mindspring.com
- FW: Interesting EQ rant (very long quote) Nathan F.Yospe
- Balance was Damaging items was New Bartle artic le Palacio, Ryan
- License Laws was Where's The Line Drawn Èric Rhéa
- License Laws was Where's The Line Drawn Frank Crowell
- Scripting Ben Chambers