January 2001

• Proper MU* style list Kyndig
• • Proper MU* style list Malcolm Tester
  • Proper MU* style list Daniel A. Koepke
  • Proper MU* style list Richard A. Bartle
  • • Proper MU* style list Christopher Allen
    • • Proper MU* style list Koster, Raph
  • Proper MU* style list Kerem HADIMLI
• MU* styles Kerem HADIMLI
• Moving away from the skill system Inq Admin
• • Moving away from the skill system Hulbert, Leland
  • Moving away from the skill system jrb@kc.rr.com
• About.com article on Skotos Christopher Allen
• • About.com article on Skotos Matthew Mihaly
  • About.com article on Skotos Christopher Allen
  • • About.com article on Skotos SavantKnowsAll@cs.com
    • • About.com article on Skotos Christopher Allen
      • About.com article on Skotos Matthew Mihaly
    • About.com article on Skotos Hans-Henrik Staerfeldt
  • About.com article on Skotos Klara
  • About.com article on Skotos Jon Morrow
  • • About.com article on Skotos Matthew Mihaly
• Skill-Trees & Christopher Allen
• • Skill-Trees & Phil Hall
  • • Skill-Trees & Wes Connell
    • Skill-Trees & Travis Casey
  • Skill-Trees & Christopher Allen
  • Skill-Trees & Dmitri Zagidulin
  • Skill-Trees & Travis Casey
  • Skill-Trees & Travis Casey
• Player statistics Wes Connell
• • Player statistics Marc Bowden
  • • Player statistics Wes Connell
    • • Player statistics Marc Bowden
    • Player statistics Matthew Mihaly
    • Player statistics rayzam
  • Player statistics Klara
  • • Player statistics Wes Connell
    • Player statistics Koster, Raph
    • • Player statistics Jake Song
      • • Player statistics Koster, Raph
        • Player statistics Matthew Mihaly
        • • Player statistics Dave Rickey
          • • Player statistics msew
        • Player statistics Jessica Mulligan
      • Player statistics Vincent Archer
      • • Player statistics Koster, Raph
        • • Player statistics David Kennerly
  • Player statistics Dave Rickey
  • Player statistics David Kennerly
  • • Player statistics Jake Song
  • Player Statistics Jessica Mulligan
  • Player statistics Jake Song
• CGDC Dinner J C Lawrence
• Skotos Anthony R. Haslage
• • Skotos Richard.Woolcock@rsuk.rohde-schwarz.com
• "Men are from Quake, Women are from Ultima" Koster, Raph
• • "Men are from Quake, Women are from Ultima" Marc Bowden
  • • "Men are from Quake, Women are from Ultima" Koster, Raph
    • • "Men are from Quake, Women are from Ultima" Willowreed@aol.com
      • "Men are from Quake, Women are from Ultima" Tess Snider
      • • "Men are from Quake, Women are from Ultima" Koster, Raph
        • • "Men are from Quake, Women are from Ultima" Michael Tresca
          • • "Men are from Quake, Women are from Ultima" Chris Lloyd
          • "Men are from Quake, Women are from Ultima" Tess Snider
    • "Men are from Quake, Women are from Ultima" SavantKnowsAll@cs.com
• NomicWiki J C Lawrence
• more idiocy from graphical MUD developers Matthew Mihaly
• An Idea... Mud Development Framework Jeremy Lowery
  <EdNote: Duplicate HTML copy deleted. Formatting cleaned up. I'd
  much rather you did this than me.>
  
  I've been developing a mud codebase for the past few months. At a
  certain point I realized that I was treading on all too common
  territory, and my ambitions began to take over. In a rush of creative
  energy (or hysteria), I thought up the idea of a mud programming
  framework. My goal is the think of a base that supports the widest
  variety of different game ideas. I'd been twittling with pieces of the
  thing in my mind for some time now. Below is my first thoughts on the
  system. Next ideas would be the implementation of serialization and a
  scripting language to support the framework, along with precisie object
  definition information. Will you folks tell me what you think?
  Inpracticallities? Has someone already done this? Holes? Of course, if
  you notice how I write. It seems like this thing already exists! Err. it
  doesn't :)
  
  MDK (Mud Development Kit)
  Jeremy Lowery
  
  Purpose
  
  The MDK's purpose is to provide a scriptable object-oriented MUD
  developing environment.
  
  The MDK Framework
  
  The MDK system is the framework that is used to develop muds. MDK
  implements a class-object hierarchy, design patterns, and polymorphic
  data-types to support the extensible nature of the development
  environment (DE).
  
  The Object Factory
  
  The object factory manages all objects created in the DE. The factory
  also includes built in support for object serialization via standard
  C++ file streams. The factory maintains the file structure of all game
  objects internally in a special resource file named ofrdb.mlib (object
  factory reference database). The factory also needs to keep track of
  all objects created in the game. This is accomplished by a unique
  virtual index number assigned to every single "thing" created in game
  (all of which are objects).
  
  Advantages include:
  
  a.. Item copying identification
  b.. System Snapshots
  
  The Notifier
  
  The object notifier is a singleton object that processes and
  dispatches object-based messages. Based on the message scope and type,
  the notifier dispatches the message to the corresponding target
  object(s). The notifier also has built in security features that allow
  message destruction before processing for invalid message usages. The
  notifier and object factory work closely together to handle
  object-creation and message dispatching. Indeed, they share the same
  object pool.
  
  Game Messages
  
  Object interaction is achieved by using the notifier. All objects must
  override member functions that parse system messages directed to them
  by other objects.
  
  In addition to simple object messages, the DE also supports message
  scope resolution for message sending objects. These specifiers can be
  used to send messages at a certain game-level scope (More on this a
  little later). All messages are identified by a unique integer
  constant abbreviated MM_ (for mud message). Associated with messages
  is a generic message handling data-type identifying message specific
  data. Unlike most MUD systems, the MDK does not explicitly bind client
  messages to character objects. One of the main advantages this
  approach exposes is the use of a common socket-polling connection for
  every kind of game manipulation that is possible. Aside from
  characters playing the game, this also allows administrators,
  builders, and developers to have parallel game access, but via
  different interfaces.
  
  System Messages
  
  The framework can also send messages to game objects. Unlike game
  message, system messages know no boundary. Of course, it is the
  object's responsibility to actually do something with the
  message. Common examples of system message include time messages,
  shutdown messages, client disconnection, and persistence messages
  (i.e. messages that tell objects to save themselves on a regular basis
  incase of system failure).
  
  The Network
  
  One of the only things that need to be hard-coded into the system is
  the actual game server. Of course, in reality it is just another
  object. It sends messages to other objects and receives them just as
  any other object does (via a method called message/object pooling
  discussed later). Not only does the network processes in route
  messages, it also binds client connects to game objects (mainly
  characters). The network then dispatches the messages to the object
  with a special client-specifying message. Although this can also be
  manipulated to include other objects such as items or rooms (not just
  characters). All objects that can be manipulated by clients exposes a
  command interface that is used for client manipulation. Scripts to
  manipulate the objects programmatically can also use this
  interface. For example: the Mobile object exposes a message-handling
  interface that includes a talk command. In a script, a NPC can use the
  exact same speaking interface that players use to communicate.
  
  Client-Binding
  
  All clients must always be binded to some object that exposes a
  command interface. Even if this object is not an in-game
  representation of something (such as a character). Other interface
  objects may include a character loader object, a shopping object, or a
  menu object.
  
  Game Objects
  
  Game objects are anything that exists within the game
  framework. Examples include items, characters, creatures, and rooms.
  Objects must also include built-in object serialization in their
  definition. They must also implement message handling of one kind or
  another. Objects can alternatively implement a command interface.
  NOTE: These are the only two ways the framework has direct access to
  the object. This may seem like a dire restriction. However, upon
  closer inspection, it is really all an object could possibly need. All
  objects implement a standard interface for generic object
  manipulation.
  
  Object Pools
  
  Objects obviously need a way to be grouped together in a programmatic
  fashion. Internally, they are structured as a linked list. However,
  object pools expose more general (albeit useful) functionality. Object
  pools are never independent entities (except in some extreme examples
  such as the global object pool). Instead, they are always composed
  inside a proxy class. The proxy object then implements indirect
  manipulation of the object pool. Besides standard link-list
  manipulation, pools also implement common game-specific collection
  information such as a ContentDescription(string lists) property. Also,
  even though object pools are hidden from outside object manipulation,
  the objects inside the pool still pick up game messages. This is
  implemented by a mandatory registration of all object pools upon
  creation of its proxy object. Of course in some object
  pools(i.e. ContainmentPools), the pool objects loose access to most
  game messages. It only seems practical that an item inside a closed
  backpack is inaccessible from the outside world. (even though messages
  sent from inside the backpack can be picked up.)
  
  Object Ownership
  
  The framework supports object-to-object (OtO) ownership. One should
  note that there is a distinct difference between object inheritance
  and ownership (more on that later). If ownership resembles anything,
  it is fancy definition by composition. OtO ownership comes in a
  distinct variety of flavors. These include containment, possession,
  and relevance.
  
  a.. Containment - the object is inside another object
  a.. A weapon is inside a backpack.
  
  b.. Possession - the object has exclusive control of another object
  a.. A player possesses a weapon.
  
  c.. Relevance - the object has a child-like relationship to another
  object.
  a.. Exits are relevant to specific rooms.
  
  
  Object ownership is implemented using object pools. These pools are
  derived from the more generic object pool definition. They are
  creatively named ContainmentPool, PossessionPool, etc.
  
  The Life of an Object
  
  Generally, all objects live the same life inside the program. They are
  created by the Object Factory, load their data from disk, sit around
  processing messages, and eventually die. Of course, the most
  interesting part is the message processing. All objects are inherently
  aware. They know when they change ownership, when to update
  themselves, and when they are about to be destroyed among other
  things. Many times, objects will never need to process certain
  messages. Either these messages will never get sent to the object, or
  the object doesn't care. For example a room object will never receive
  a MM_OWNERCHANGE message, and a broadsword shouldn't care what it
  belongs to whether it be the ground or some crazy dwarf. Of course, it
  could care. Maybe this broadsword doesn't like dwarves? The point is,
  the broadsword can pick and choose what it thinks is important solely
  from the broadsword's point of view.
  
  Immediate Message Pools (IMPs)
  
  There is also another special kind of object pool called a message
  pool. Message pools are used for game efficiency. The name is rather
  misleading because messages aren't really stored in the pool. However,
  messages can use the pools for faster resolution to their target. The
  idea lies in the fact that there could be thousands, if not millions,
  of objects in a standard mud at any given time. It makes no sense to
  have a player execute a move message and the dispatcher then has to
  look up the target(amongst thousands of other objects) to get the
  room. There should be a way to achieve faster resolution of the most
  common game messages that will be sent all of the time. This problem
  only exists because there is no direct upward transversal of object
  ownership. So why isn't there upward transversal?
  
  
  Why Child-Parent Relationships Don't Work
  
  I believe that introducing such object variables would take away from
  the extensibility of the system, and make programming the system
  harder. The parent ship of an object from the child's prospective can
  become blurry. Let's say a kobold is holding a short sword. Does the
  sword belong to the kobold? Intuitively, yes it does. But it could
  actually belong to the kobold's hand. Maybe it belongs to the body of
  the kobold, and then the body belongs to the kobold object. In this
  scenario, the exact relationship of the objects must be known for the
  short sword to tell the kobold something (Whatever the dire message
  may be!). Sure, this simple example could easily be resolved with a
  little standardization. However, it relies on assumptions. And
  assumptions can turn out to be bad.
  
  Let's step through a little scenario. The kobold object has a hand
  object in its object pool. The hand object then has the short
  sword. In battle a crazy dwarf chops off the kobold's hand. The hand
  still has the sword, but it's lying on the ground. The kobold then
  runs away in fear. Now, let's say the short sword processes a time
  message, and it decides that it's going to rust. The sword tells its
  parent, the hand, that it's rusting. The hand doesn't care, so in turn
  it sends the message to its parent (the kobold). But now the kobold is
  not here! We've got to make the hand understand this, or else the
  kobold miles away will know about its old sword rusting! I'm sure you
  can see where this is going. Nowhere! If something changed, everything
  below it would need to be changed as well, and everything would become
  tightly coupled.
  
  Enter IMPs and the Message Framework
  
  Instead of the method I just described, I will introduce an
  alternative approach. The short sword rusts. It then screams, "I'm
  rusting!" The sword's "voice" can only reach the room it is in. Every
  object in the room hears the sword's cry. A goblin corpse hears it and
  asks, "Is that sword mine? No! I don't care." Alternatively, if the
  arm were attached, the kobold would recognize it was its sword, and
  the appropriate text message could be sent "Your short sword is
  rusting." IMPs are the medium level containment devices that are used
  to dispatch local game messages: a medium between the extremes of a
  game-wide message and a message sent specifically to a target. A good
  way to look at it is like this. The IMP is every object's "parent."
  They don't really exist in game, so practical rules don't apply. There
  are basically 3 levels of IMPs: system(SMPs), zone(ZMPs), and
  room(RMPs). An IMP has access to the top-most object in its "level."
  IMPs serve as message safety nets. IMPs also implement message
  "scope." Depending on the "scope specifier" of a message, it can die
  at any particular IMP. All message are processed from RMP to ZMP to
  the SMP.
  
  Message Scope Specifiers:
  
  RMP_FT - room message pool fall through. If a room objects
  does not process the message, it falls through to a
  ZMP and then to the SMP.
  
  RMP_NFT - no fall through. If a room object does not process
  the message, it dies instantly.
  
  ZMP_FT - processing begins on the zone level with fall
  through.
  
  ZMP_NFT - processing only occurs in the ZMP
  
  SMP - processing only occurs on the system level.
  
  Messages can also specify their stop point. A message can die once it
  finds an object to process it, or the message can go through the
  entire IMP net.
  
  Message Stop Point Specifiers:
  
  a.. DOOC - Die on Object Contact
  b.. DOMP - Die on the Message Pool
  
  Specialized Message Pools
  
  The Framework also makes heavy use of MPs, although on a more
  specialized level. For example, the network maintains a Player Message
  Pool (a pool that includes references to all players). This allows for
  the bypassing of the message framework for certain situations. Other
  uses of message pools will be mentioned as needed.
  
  Message Pools and Object Pools: The Relation
  
  Let's run through another scenario. A player drops an axe on the
  ground. First, the actual item is removed from the player's object
  pool. The object pool then sends a message to the axe object. This
  message is sent directly to the axe, because the pool has the object
  reference. If the axe needs to do anything special when it's dropped
  (like maybe turn to dust), it receives this message now. The player
  object then send two messages. First it sends a text message to the
  player's client and then a MM_RNMMSG (Room Not Me Message) RMP_NFT
  DOMP saying that it's dropping the axe. The room object pool picks up
  the message and dispatches it to all objects in the room. As the
  message is iterated through the object pool, the objects ask, "Did I
  send this message? No? Send the message. Yes? Do nothing." When the
  object answers, "No. Send the message.", another message is generated.
  
  Network Object Pools : A Specialization
  
  There is a big difference between message dispatching via the network
  and other game objects. Because network I/O is a very big part of a
  MUD game, the network maintains a large connection of very small
  object pools (RelevancePools to be specific). These pools are actually
  pairs. They include socket reference objects (low level network) and
  another object that exposes a command interface (like a game
  character). Also, all command interface objects include an object pool
  reference to their network pool counterpart. This gives direct access
  to/from the client connection. In this care, the object pool is
  actually a very specialized message pool. Thus this is called
  object/message pooling.
  
  
  The Notifier and IMPs
  
  Early in this paper, I said that the Notifier "dispatches messages."
  How does it fit in with IMPs? Well, the Notifier is the master of the
  IMPs. It handles the creation of IMPs, the relationships of different
  MPs, and the MP hierarchy. The notifier also provides a backdoor for
  the system into the game world. By using the Global Object Pool (All
  of the objects in the game) GOP, and the MP hierarchy, a system
  routine can observe, intercept, and send game messages. Common uses of
  the Notifier include scanning all text for cuss words, detecting
  spamming, routine system rebooting, sending administrators important
  texts, and other daemon-like tasks.
• • An Idea... Mud Development Framework David Loeser
  • An Idea... Mud Development Framework Bruce
  • • An Idea... Mud Development Framework Jeremy Lowery
    • • An Idea... Mud Development Framework Bruce
      • An Idea... Mud Development Framework Miroslav Silovic
      • • An Idea... Mud Development Framework Bruce
  • An Idea... Mud Development Framework Ben Chambers
  • • An Idea... Mud Development Framework Justin Rogers
    • • An Idea... Mud Development Framework Ben Chambers
  • An Idea... Mud Development Framework John Buehler
  • • An Idea... Mud Development Framework Bruce
    • • An Idea... Mud Development Framework Jeremy Lowery
      • • An Idea... Mud Development Framework Chris Jones
• Server stability (was: Player statistics) Bruce
• • Server stability (was: Player statistics) Koster, Raph
  • • Server stability (was: Player statistics) Bruce
    • • Server stability (was: Player statistics) Koster, Raph
      • • Server stability (was: Player statistics) J C Lawrence
        • Server stability (was: Player statistics) Valerio Santinelli
      • Server stability (was: Player statistics) Tess Snider
      • • Server stability (was: Player statistics) Bruce
        • • Server stability (was: Player statistics) Koster, Raph
          • • Server stability (was: Player statistics) Ben Chambers
  • Server stability (was: Player statistics) Chris Jones
• New Muds Corey Crawford
• Dinner scheduling and possible roundtable J C Lawrence
• New Mud Fox McCloud
• MUD-Dev digest, Vol 1 #277 - 13 msgs Dr. Cat
• • MUD-Dev digest, Vol 1 #277 - 13 msgs Matthew Mihaly
  • • MUD-Dev digest, Vol 1 #277 - 13 msgs Jake Song
  • MUD-Dev digest, Vol 1 #277 - 13 msgs Jeff Freeman
• Server stability (was: Player statistics) Par Winzell
• • Server stability (was: Player statistics) J C Lawrence
  • Server stability (was: Player statistics) Bruce
  • • Server stability (was: Player statistics) Felix A. Croes
    • • Server stability (was: Player statistics) Klara
• MUD-Dev digest, Vol 1 #277 - 13 msgs J C Lawrence
• • MUD-Dev digest, Vol 1 #277 - 13 msgs Jake Song
  • MUD-Dev digest, Vol 1 #277 - 13 msgs Bruce
  • • MUD-Dev digest, Vol 1 #277 - 13 msgs Mark Watson
• ANNC: .NET Frameworks based Mud Codebase Justin Rogers
• • ANNC: .NET Frameworks based Mud Codebase Bruce
  • ANNC: .NET Frameworks based Mud Codebase szii@sziisoft.com
  • • ANNC: .NET Frameworks based Mud Codebase Justin Rogers
    • • ANNC: .NET Frameworks based Mud Codebase szii@sziisoft.com
• Announcing: Pan J C Lawrence
• • Announcing: Pan J C Lawrence
  • Announcing: Pan Kyndig
• Experience System Differences Alornen
• • Experience System Differences Malcolm Tester
  • • Experience System Differences Hulbert, Leland
    • • Experience System Differences rayzam
      • • Experience System Differences Ben Chambers
        • • Experience System Differences rayzam
          • • Experience System Differences Ben Chambers
            • • Experience System Differences Travis Casey
              • • Experience System Differences Mark Watson
              • Experience System Differences rayzam
    • Experience System Differences Kindred321@aol.com
  • Experience System Differences Hans-Henrik Staerfeldt
  • • Experience System Differences Brian M. Schkerke
    • Experience System Differences Ben Chambers
  • Experience System Differences Malcolm Tester
  • Experience System Differences Warren Powell
• speaking of symposia... Robert Zubek
• MUD-Dev digest, Vol 1 #281 - 18 msgs Dr. Cat
• • MUD-Dev digest, Vol 1 #281 - 18 msgs Jeff Freeman
• I Want to Bake Bread Neeby
• • I Want to Bake Bread Richard
  • • I Want to Bake Bread John Buehler
    • • I Want to Bake Bread Richard
    • I Want to Bake Bread Ryan
    • • I Want to Bake Bread Patrick Dughi
    • I Want to Bake Bread Siobhan Perricone
  • I Want to Bake Bread Hal Bonnin
  • • I Want to Bake Bread Travis Casey
  • I Want to Bake Bread John Buehler
• Exploration Exp (was: Experience System Differences) Corey Crawford
• • Exploration Exp (was: Experience System Differences) Lord Ashon
  • Exploration Exp (was: Experience System Differences) John Buehler
  • Exploration Exp (was: Experience System Differences) Philip Loguinov, Draymoor
  • • Exploration Exp (was: Experience System Differences) nbossett@pierb.com
    • Exploration Exp (was: Experience System Differences) Warren Powell
    • • Exploration Exp (was: Experience System Differences) rayzam
      • • Exploration Exp (was: Experience System Differences) Justin Rogers
• MUD research, good ideas and designers who care? Ola Fosheim Grøstad
• Baking Bread Lord Ashon
• • Baking Bread John Buehler
• Distributed PSW design Stephane Bura
• • Distributed PSW design Frank Crowell
  • • Distributed PSW design Bruce
    • Distributed PSW design Stephane Bura
    • • Distributed PSW design John Buehler
      • • Distributed PSW design J C Lawrence
        • • Distributed PSW design Justin Rogers
          • Distributed PSW design John Buehler
          • Distributed PSW design Eli Stevens
          • • Distributed PSW design John Buehler
• MUD-Dev digest, Vol 1 #282 - 18 msgs Dr. Cat
• • MUD-Dev digest, Vol 1 #282 - 18 msgs Koster, Raph
• IOWA project / Request for addition to FAQ Bruce
• No Exp? (was: Exploration Exp) Corey Crawford
• • No Exp? (was: Exploration Exp) John Buehler
  • • No Exp? (was: Exploration Exp) Hulbert, Leland
    • • No Exp? (was: Exploration Exp) John Buehler
      • • No Exp? (was: Exploration Exp) msew
        • • No Exp? (was: Exploration Exp) John Buehler
  • No Exp? (was: Exploration Exp) Travis Casey
  • No Exp? (was: Exploration Exp) rayzam
  • No Exp? (was: Exploration Exp) Michael Tresca
  • • No Exp? (was: Exploration Exp) John Buehler
    • No Exp? (was: Exploration Exp) msew
    • • No Exp? (was: Exploration Exp) Michael Tresca
  • No Exp? (was: Exploration Exp) Alistair Milne
  • No Exp? (was: Exploration Exp) J C Lawrence
  • • No Exp? (was: Exploration Exp) John Buehler
    • • No Exp? (was: Exploration Exp) J C Lawrence
      • • No Exp? (was: Exploration Exp) John Buehler
  • No Exp? (was: Exploration Exp) J C Lawrence
• C# Greg Miller
• Player Created Object System Philip Loguinov, Draymoor
• • Player Created Object System Richard
  • • Player Created Object System Philip Loguinov, Draymoor
    • Player Created Object System Christopher Allen
    • • Player Created Object System Bruce
  • Player Created Object System Richard
• Distributed PSW design (Frank Crowell) Peter Yu
• • Distributed PSW design (Frank Crowell) Frank Crowell
• MUD-Dev digest, Vol 1 #282 - 18 msgs Jeff Freeman
• • MUD-Dev digest, Vol 1 #282 - 18 msgs J C Lawrence
  • • MUD-Dev digest, Vol 1 #282 - 18 msgs Jake Song
• Room Generation Nathanael Dermyer
• • Room Generation J C Lawrence
  • • Room Generation George Greer
    • Room Generation Bruce
    • • Room Generation Bruce
      • Room Generation Richard
      • Room Generation Mordengaard
    • Room Generation Kwon Ekstrom
    • Room Generation Jon Lambert
  • Room Generation Patrick Dughi
  • • Room Generation Ola Fosheim Grøstad
    • • Room Generation Travis Casey
      • Room Generation Ola Fosheim Grøstad
  • Room Generation Eli Stevens
  • Room Generation Richard
  • Room Generation Richard
  • Room Generation Colin Coghill
  • Room Generation efindel@earthlink.net
  • Room Generation Ryan P.
• Variant Methods for Related Skills Christopher Allen
• • Variant Methods for Related Skills Travis Casey
• Anyone know of plans for an I-Mode MUD/LARP? J C Lawrence
• • Anyone know of plans for an I-Mode MUD/LARP? Koster, Raph
  • Anyone know of plans for an I-Mode MUD/LARP? Ola Fosheim Grøstad
  • • Anyone know of plans for an I-Mode MUD/LARP? rayzam
    • Anyone know of plans for an I-Mode MUD/LARP? Travis Casey
    • Anyone know of plans for an I-Mode MUD/LARP? Jon Lambert
    • Anyone know of plans for an I-Mode MUD/LARP? Jeff Freeman
• Room and Terrain Integration in Textual Environments vognsen@post10.tele.dk
• • Room and Terrain Integration in Textual Environments Bruce
• Project Entropia the_logos@www.achaea.com
• • Project Entropia John Vanderbeck
  • • Project Entropia Christopher Allen
    • • Project Entropia J C Lawrence
      • • Project Entropia J C Lawrence
        • • Project Entropia John Vanderbeck
    • Project Entropia the_logos@www.achaea.com
  • Project Entropia Batir
  • • Project Entropia the_logos@www.achaea.com
  • Project Entropia Frank Crowell
  • • Project Entropia Jessica Mulligan
    • • Project Entropia Frank Crowell
      • • Project Entropia Jessica Mulligan
    • Project Entropia the_logos@www.achaea.com
    • • Project Entropia the_logos@www.achaea.com
• MUD-Dev digest, Vol 1 #285 - 32 msgs Dr. Cat
• • MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
  • • MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
    • • MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
      • • MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
        • • MUD-Dev digest, Vol 1 #285 - 32 msgs Koster, Raph
          • • MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
          • MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
        • MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
• Skill System Kwon Ekstrom
• • Skill System Travis Casey
  • • Skill System justice@softhome.net
  • Skill System Ben Chambers
  • • Skill System Batir
    • • Skill System Ben Chambers
      • • Skill System Batir
    • Skill System justice@softhome.net
• Long Day's Journey Into Tights J C Lawrence
• MUD-Dev digest, Vol 1 #289 - 8 msgs Dr. Cat
• • MUD-Dev digest, Vol 1 #289 - 8 msgs the_logos@www.achaea.com
  • • MUD-Dev digest, Vol 1 #289 - 8 msgs Hans-Henrik Staerfeldt
    • • MUD-Dev digest, Vol 1 #289 - 8 msgs Nathan F.Yospe
    • MUD-Dev digest, Vol 1 #289 - 8 msgs justice@softhome.net
  • MUD-Dev digest, Vol 1 #289 - 8 msgs Dave Rickey
  • • MUD-Dev digest, Vol 1 #289 - 8 msgs Vincent Archer
  • MUD-Dev digest, Vol 1 #289 - 8 msgs msew
  • • MUD-Dev digest, Vol 1 #289 - 8 msgs Travis Casey
• When Do We Get the "Right" to Privacy? J C Lawrence
• • When Do We Get the "Right" to Privacy? Nathan F.Yospe
  • • When Do We Get the "Right" to Privacy? Koster, Raph
• Cybercafes a fluke? (was: MUD-Dev digest, Vol 1 #289 - 8 msgs) Scion Altera
• Cybercafes a fluke? (was: MUD-Dev digest, Vol 1 #289 - 8 msgs) Holly Sommer
• An interesting concept Richard.Woolcock@rsuk.rohde-schwarz.com
• [iggamedes] WAKE UP! :) Tomb Raider style games? J C Lawrence
• • [iggamedes] WAKE UP! :) Tomb Raider style games? Jon Lambert
• Cultural Differences in Gaming and Gamers SavantKnowsAll@cs.com
• • Cultural Differences in Gaming and Gamers Koster, Raph
  • Cultural Differences in Gaming and Gamers the_logos@www.achaea.com
• System burps and outages J C Lawrence
• Semi Graphical Muds Ben Chambers
• • Semi Graphical Muds Peter Yu
  • Semi Graphical Muds Christopher Allen
  • Semi Graphical Muds the_logos@www.achaea.com
  • • Semi Graphical Muds Ben Chambers
    • • Semi Graphical Muds David Loeser
      • • Semi Graphical Muds Ben Chambers
        • • Semi Graphical Muds David Loeser
      • Semi Graphical Muds the_logos@www.achaea.com
      • • Semi Graphical Muds Ben Chambers
        • • Semi Graphical Muds Corey Crawford
    • Semi Graphical Muds Kerem HADIMLI
    • • Semi Graphical Muds Jon Lambert
      • • Semi Graphical Muds the_logos@www.achaea.com
        • • Semi Graphical Muds J C Lawrence
      • Semi Graphical Muds Ben Chambers
      • • Semi Graphical Muds Kerem HADIMLI
        • Semi Graphical Muds Frank Crowell
        • • Semi Graphical Muds Ben Chambers
          • • Semi Graphical Muds Koster, Raph
            • • Semi Graphical Muds Ben Chambers
              • • Semi Graphical Muds Caliban Tiresias Darklock
                • Semi Graphical Muds Bruce
                • • Semi Graphical Muds Jay Carlson
                  • • Semi Graphical Muds the_logos@www.achaea.com
                    • • Semi Graphical Muds Jon Lambert
                      • • Semi Graphical Muds J C Lawrence
                    • Semi Graphical Muds Bruce
                • Semi Graphical Muds the_logos@www.achaea.com
            • Semi Graphical Muds Bruce
  • Semi Graphical Muds Christopher Allen
  • • Semi Graphical Muds Bruce
    • • Semi Graphical Muds Felix A. Croes
      • • Semi Graphical Muds Christopher Allen
        • • Semi Graphical Muds Felix A. Croes
          • • Semi Graphical Muds Ben Chambers
            • Semi Graphical Muds Bruce
            • • Semi Graphical Muds David Loeser
              • Semi Graphical Muds Marc Bowden
              • Semi Graphical Muds Felix A. Croes
              • • Semi Graphical Muds Bruce
                • • Semi Graphical Muds Felix A. Croes
  • Semi Graphical Muds Adam Casbarian
  • Semi Graphical Muds J C Lawrence
  • • Semi Graphical Muds the_logos@www.achaea.com
    • • Semi Graphical Muds J C Lawrence
  • Semi Graphical Muds Koster, Raph
  • • Semi Graphical Muds J C Lawrence
    • • Semi Graphical Muds Koster, Raph
      • • Semi Graphical Muds the_logos@www.achaea.com
        • • Semi Graphical Muds J C Lawrence
          • • Semi Graphical Muds the_logos@www.achaea.com
            • • Semi Graphical Muds John Buehler
          • Semi Graphical Muds Koster, Raph
          • Semi Graphical Muds Dave Rickey
          • • Semi Graphical Muds Hulbert, Leland
            • • Semi Graphical Muds Dave Rickey
              • Semi Graphical Muds geoffrey@yorku.ca
            • Semi Graphical Muds the_logos@www.achaea.com
      • Semi Graphical Muds rayzam
      • • Semi Graphical Muds J C Lawrence
        • • Semi Graphical Muds Sanvean
          • • Semi Graphical Muds J C Lawrence
            • • Semi Graphical Muds Tamzen Cannoy
              • • Semi Graphical Muds J C Lawrence
                • • Semi Graphical Muds the_logos@www.achaea.com
                  • • Semi Graphical Muds Frank Crowell
          • Semi Graphical Muds rayzam
        • Semi Graphical Muds the_logos@www.achaea.com
        • • Semi Graphical Muds rayzam
          • • Semi Graphical Muds the_logos@www.achaea.com
            • • Semi Graphical Muds J C Lawrence
              • • Semi Graphical Muds the_logos@www.achaea.com
                • • Semi Graphical Muds rayzam
                  • • Semi Graphical Muds the_logos@www.achaea.com
                    • • Semi Graphical Muds Ben Chambers
                      • Semi Graphical Muds rayzam
            • Semi Graphical Muds Kevin Littlejohn
            • • Semi Graphical Muds J C Lawrence
      • Semi Graphical Muds Ben Chambers
    • Semi Graphical Muds the_logos@www.achaea.com
  • Semi Graphical Muds J C Lawrence
  • Semi Graphical Muds Adam Casbarian
  • • Semi Graphical Muds the_logos@www.achaea.com
• Ebay bans character selling the_logos@www.achaea.com
• • Ebay bans character selling susie
  • • Ebay bans character selling Frank Crowell
  • Ebay bans character selling Frank Crowell
  • • Ebay bans character selling the_logos@www.achaea.com
    • • Ebay bans character selling Richard.Woolcock@rsuk.rohde-schwarz.com
      • Ebay bans character selling Kevin Littlejohn
      • • Ebay bans character selling Travis Casey
    • Ebay bans character selling Hans-Henrik Staerfeldt
    • Ebay bans character selling Hans-Henrik Staerfeldt
  • Ebay bans character selling rayzam
  • • Ebay bans character selling John Buehler
    • • Ebay bans character selling Hans-Henrik Staerfeldt
    • Ebay bans character selling Dave Rickey
    • • Ebay bans character selling Eric Lee {RAT}
    • Ebay bans character selling Frank Crowell
    • • Ebay bans character selling Timothy Dang
      • Ebay bans character selling Paul Robinson
    • Ebay bans character selling Peter Yu
  • Ebay bans character selling Daniel.Harman@barclayscapital.com
  • Ebay bans character selling David Kennerly
  • • Ebay bans character selling Neeby
  • Ebay bans character selling Willowreed@aol.com
  • • Ebay bans character selling Travis Casey
  • Ebay bans character selling rayzam
  • • Ebay bans character selling Jeremy Music
    • • Ebay bans character selling rayzam
  • Ebay bans character selling Yves K
  • • Ebay bans character selling the_logos@www.achaea.com
• front end clients.....was Semi Graphical Muds Willowreed@aol.com
• • front end clients.....was Semi Graphical Muds Frank Crowell
  • front end clients.....was Semi Graphical MUDs Christopher Allen
• Meta-gaming: (real <--> game) transfers David Kennerly
• EverQuest Study Dave Rickey
• [pol-core-test] New file uploaded to pol-core-test (OT) Jeff Freeman
• • [pol-core-test] New file uploaded to pol-core-test (OT) the_logos@www.achaea.com
  • • [pol-core-test] New file uploaded to pol-core-test(OT) Dave Rickey
    • • [pol-core-test] New file uploaded to pol-core-test(OT) Valerio Santinelli
      • • [pol-core-test] New file uploaded to pol-core-test(OT) Frank Crowell
• PvP Systems John Buehler
• • PvP Systems Jon Lambert
  • • PvP Systems the_logos@www.achaea.com
  • PvP Systems Federico Di Gregorio
  • • PvP Systems John Buehler
    • • PvP Systems gmiller@classic-games.com
      • • PvP Systems John Buehler
        • • PvP systems Greg Miller
          • • PvP systems John Buehler
            • • PvP systems gmiller@classic-games.com
              • • PvP systems John Buehler
                • • PvP systems gmiller@classic-games.com
                  • • PvP systems John Buehler
                    • • PvP systems gmiller@classic-games.com
                    • PvP systems the_logos@www.achaea.com
                    • • PvP systems J C Lawrence
                      • • PvP systems the_logos@www.achaea.com
                        • • PvP systems J C Lawrence
                          • • PvP systems the_logos@www.achaea.com
            • PvP systems the_logos@www.achaea.com
            • • PvP systems Dave Turner
              • PvP systems gmiller@classic-games.com
              • • PvP systems the_logos@www.achaea.com
              • PvP systems S. Patrick Gallaty
              • • PvP systems the_logos@www.achaea.com
      • PvP Systems Federico Di Gregorio
      • • PvP Systems John Buehler
        • • PvP Systems the_logos@www.achaea.com
          • • PvP Systems John Buehler
            • • PvP Systems Jake Song
              • PvP Systems the_logos@www.achaea.com
              • • PvP Systems John Buehler
                • • PvP Systems the_logos@www.achaea.com
                  • • PvP Systems John Buehler
                    • • PvP Systems the_logos@www.achaea.com
            • PvP Systems Corey Crawford
        • PvP Systems Jon Lambert
        • • PvP Systems John Buehler
          • • PvP Systems Jon Lambert
            • • PvP Systems John Buehler
              • • PvP Systems Sanvean
                • PvP Systems J C Lawrence
                • • PvP Systems John Buehler
                  • • PvP Systems J C Lawrence
                    • • PvP Systems John Buehler
                      • • PvP Systems J C Lawrence
                        • • PvP Systems John Buehler
                          • • PvP Systems J C Lawrence
                            • • PvP Systems the_logos@www.achaea.com
                              • • PvP Systems J C Lawrence
                                • PvP Systems Michael Tresca
                              • PvP Systems John Buehler
                • PvP Systems Jon Lambert
                • • PvP Systems John Buehler
              • PvP Systems Travis Casey
          • PvP Systems the_logos@www.achaea.com
          • • PvP Systems Kerem HADIMLI
      • PvP Systems the_logos@www.achaea.com
      • • PvP Systems The Druid
  • PvP Systems rayzam
  • • PvP Systems John Buehler
    • • PvP Systems msew
      • • PvP Systems Koster, Raph
        • • PvP Systems msew
  • PvP Systems msew
  • • PvP Systems John Buehler
  • PvP Systems msew
  • • PvP Systems Vincent Archer