May 2002

• Random Resets John Robert Arras
• • Random Resets Kwon Ekstrom
  • • Random Resets John Robert Arras
• [MLP] The use of ecology models Rayzam
• Interesting things to do (was: Player Accounts on a Non-Commercial MUD) John Buehler
• • Interesting things to do (was: Player Accounts on a Non-Commercial MUD) Damion Schubert
• Apple WWDC? amanda@alfar.com
• • Apple WWDC? Nathan F. Yospe
  • • Apple WWDC? Amanda Walker
    • • Apple WWDC? Sasha Hart
      • • Apple WWDC? amanda@alfar.com
        • • Apple WWDC? Brian Hook
          • Apple WWDC? John A. Bertoglio
          • • Apple WWDC? Daniel.Harman@barclayscapital.com
            • Apple WWDC? Matt Mihaly
            • • Apple WWDC? shren
              • • Apple WWDC? Matt Mihaly
              • Apple WWDC? John A. Bertoglio
            • Apple WWDC? James Edward Gray II
        • Apple WWDC? Brian Hook
• Encouraging groups without grouping Brian 'Psychochild' Green
• Introduction and My solution to Powergamers, Treadmills, and Content Devaluation. Ken Raisor
• • Introduction and My solution to Powergamers, Treadmills, and Content Devaluation. shren
  • Introduction and My solution to Powergamers, Treadmills, and Content Devaluation. Gladimir
  • Introduction and My solution to Powergamers, Treadmills, and Content Devaluation. szii@sziisoft.com
• The audience is the medium. For now. John Szeder
• • The audience is the medium. For now. John Buehler
  • • The audience is the medium. For now. Damion Schubert
    • • The audience is the medium. For now. Ted L. Chen
      • • The audience is the medium. For now. Shane Gough
        • The audience is the medium. For now. Michael Tresca
        • • The audience is the medium. For now. Ted L. Chen
          • • The audience is the medium. For now. Marian Griffith
            • The audience is the medium. For now. Vincent Archer
  • The audience is the medium. For now. Damion Schubert
  • The audience is the medium. For now. David B. Held
  • The audience is the medium. For now. Ted L. Chen
  • The audience is the medium. For now. Marian Griffith
  • The audience is the medium. For now. F. Randall Farmer
  • • The audience is the medium. For now. J C Lawrence
  • The audience is the medium. For now. Frank Crowell
• Ownership of characters Jasper McChesney
• Explorers? (Was: Codename Blue & Facets - Nick Yee's new studies) Brian 'Psychochild' Green
• • Explorers? (Was: Codename Blue & Facets - Nick Yee's new studies) Matt Mihaly
• Befriending Critters (was: Random Resets) Arthaey
• • Befriending Critters (was: Random Resets) Rayzam
  • Befriending Critters (was: Random Resets) shren
• Questions about server design Ben Chambers
• • Questions about server design Michael Bayne
  • Questions about server design Sean Middleditch
  • Questions about server design Mike Shaver
  • Questions about server design Kwon Ekstrom
  • Questions about server design szii@sziisoft.com
  • Questions about server design F. Randall Farmer
  • • Questions about server design James Edward Gray II
  • Questions about server design Shane Gough
• Extensibility Ben Chambers
• • Extensibility Ammon Lauritzen
  • Extensibility Kwon Ekstrom
  • Extensibility Ben Chambers
  • • Extensibility "Christopher {siege} " OBrien
  • Extensibility Sean Middleditch
  • Extensibility Sean Kelly
  • • Extensibility John Buehler
    • • Extensibility shren
      • • Extensibility John Buehler
    • Extensibility szii@sziisoft.com
    • • Extensibility John Buehler
      • • Extensibility szii@sziisoft.com
  • Extensibility Mike Shaver
• Question: Any published research on Sims type game personae? susan wu
• • Question: Any published research on Sims type game personae? Robert Zubek
• [MLP] Why care about levels? (was: The use of ecolo Richard Woolcock
• [MLP] Why care about levels? (was: The use of ecolo gy models) Jon Lambert
• Component Design (was: Extensibility) Scion Altera
• [BIZ] Selling Stock (formerly Blacksnow revisted ) Robert A. Rice, Jr.
• Games are Hot. Period Michael Tresca
• • Games are Hot. Period Gladimir
  • • Games are Hot. Period Richard Aihoshi aka Jonric
    • • Games are Hot. Period Freeman, Jeff
      • • Games are Hot. Period Richard Aihoshi aka Jonric
      • Games are Hot. Period Koster, Raph
      • • Games are Hot. Period Vincent Archer
        • Games are Hot. Period Richard Aihoshi aka Jonric
  • Games are Hot. Period Matt Mihaly
• fun Matt Mihaly
• [TECH] Shortest Path William Murdick
• [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
• • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction John Buehler
  • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
    • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction John Buehler
  • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
  • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Eli Stevens
    • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Jon Leonard
      • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Hans-Henrik Staerfeldt
      • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction Robert Zubek
      • • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction ceo@grexengine.com
  • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Hans-Henrik Staerfeldt
  • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
    • • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction Koster, Raph
      • • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction lynx@lynx.purrsia.com
        • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
  • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Rudy Neeser
  • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
  • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Matt Mihaly
  • • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction Daniel.Harman@barclayscapital.com
    • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction John Buehler
      • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Ted L. Chen
        • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction John Buehler
        • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction Mike Shaver
        • • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction John Buehler
          • [TECH] Voice in MO* - Phoneme Decomposition and Reconstruction amanda@alfar.com
        • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction Koster, Raph
        • • [TECH] Voice in MO* - Phoneme Decomposition and Rec onstruction Steve {Bloo} Daniels
• Combat with Style (was Player Accounts on a Non-Commercial MUD) lynx@lynx.purrsia.com
• Playskins Koster, Raph
• People were talking about resets.. Anderson, David
• • People were talking about resets.. Sasha Hart
  • • People were talking about resets.. Anderson, David
  • People were talking about resets.. John Buehler
  • People were talking about resets.. Anderson, David
  • People were talking about resets.. Arnau Rossell=?US-ASCII?Q?=F3?= Castell=?US-ASCII?Q?=F3?=
  • • People were talking about resets.. shren
    • People were talking about resets.. Anderson, David
    • • People were talking about resets.. David B. Held
  • People were talking about resets.. shren
  • • People were talking about resets.. Anderson, David
    • • People were talking about resets.. Michael Tresca
      • • People were talking about resets.. Fred Clift
        • • People were talking about resets.. Lars Duening
          • People were talking about resets.. Michael Tresca
          • • People were talking about resets.. Rayzam
            • • People were talking about resets.. Matt Mihaly
  • People were talking about resets.. Tand'a-ur
  • • People were talking about resets.. John Buehler
    • People were talking about resets.. Leland Hulbert II
  • People were talking about resets.. lynx@lynx.purrsia.com
  • People were talking about resets.. Jason Murdick
  • • People were talking about resets.. Jeff Lindsey
    • People were talking about resets.. Ben Chambers
  • People were talking about resets.. Sasha Hart
  • • People were talking about resets.. David B. Held
    • • People were talking about resets.. Sasha Hart
      • • People were talking about resets.. Anderson, David
        • People were talking about resets.. David B. Held
        • • People were talking about resets.. Acius
          • • People were talking about resets.. Marian Griffith
• Question about copyovers. Anderson, David
• • Question about copyovers. Tand'a-ur
  • • Question about copyovers. Anderson, David
    • • Question about copyovers. Kwon Ekstrom
      • • Question about copyovers. Adam
        • Question about copyovers. Oliver Jowett
        • • Question about copyovers. Kwon Ekstrom
          • • Question about copyovers. Adam
      • Question about copyovers. Lars Duening
  • Question about copyovers. Jon Lambert
  • Question about copyovers. fred@clift.org
  • • Question about copyovers. Zach Collins {Siege}
  • Question about copyovers. Smith, David {Lynchburg}
• non-violent activities (was People were talking about resets..) Ammon Lauritzen
• References on personality and emotion models Robert Zubek
• Multimodal interface conference. Rayzam
• Hyperbolies R Us shren
• • Hyperbolies R Us Matt Mihaly
• TECH: Systems Administration Issues Thomas Leavitt
• Questions about ... XML as data format Adam
• • Questions about ... XML as data format Anderson, David
  • Questions about ... XML as data format Kwon Ekstrom
    From: "Adam" <ya_hoo_com@yahoo.com>
    > Kwon Ekstrom <justice@softhome.net> wrote:
    >> Other than time required, I'd recommend XML.
    
    > I'd very very strongly recommend avoiding straightforward XML
    > under Java as a method for storing server data, for ANY
    > application where there's likely to be any more than trivial
    > amoutns of data.
    
    XML is a good solution, and there are possibilities out there. I
    recently took a look at DOM4j benchmarks and it shows slower
    read/write performance to Apache Xerces although it has extremely
    faster node access (which is where I've found most of my slowdown).
    
    There are a variety of solutions even light-weight XML parsers that
    don't support all the specs (do you need DTD's, validation, or
    schema?) which run with acceptable speed.
    
    > E.g., using reasonably up to date version of Zerces (the
    > IBM-opensourced XML/java parser), time taken to load a 2mb XML
    > file is heading towards ten minutes on low-end pentiums.
    
    Using a mid-range computer, I've noticed about 110ms to load up my
    socials file, I'm not sure of what the size was, but I imported the
    socials from ResortMUD and had 593 socials... For a text mud that's
    an awful lot of socials. I'll probably store alot of my system data
    as XML, and areas as well. My machine is only 450mhz, about what
    you'd expect a text mud-server to be.
    
    > Bear in mind that to store lots of small pieces of data (e.g. the
    > hitpoints for each of many monsters) imposes massive storage
    > overhead in XML (one byte of data takes often 100 to store, since
    > you have to have an open tag, a close tag, and will often choose
    > to have additional attributes too). Note that this is, of course,
    > highlt compressible. Note too, that to make a small change to the
    
    If you output the data as a number, yes. You could output it as a
    byte array, although that'd lower your effectiveness for using XML.
    The tools available for use with XML are extensive.
    
    > file saved on disk essentially requires rewriting the whole file
    > (XML is not a clever file format designed to make partial
    > rewriting to a file easy). Som you soon end up automatically
    > splitting your XML file into many small files, and compressing
    > each one, and then having buffers to cache reads/writes, and ...
    
    If you design your system to handle these from the start it's quite
    powerful. Personally I don't see why you wouldn't want to split
    your data into multiple files. Areas each in their own file, your
    players in their own files. System data in a file, commands in a
    file, etc.
    
    > So. You're much better off IMHO going with a database of some sort
    > to start off with. This is really just an application of an old
    > maxim that any app which generates/uses/modifies any significant
    > amount of data should ALWAYS use a database - in case it grows too
    > large for basic emulation of database features using savefiles.
    
    Databases are a wonderful way to store databases, they're
    specifically written to handle that. You can use a hybrid system as
    well, such as storing your data in a database in XML format. You
    then gain the ability of incremental updates, and database indexed
    searching along with the object oriented structure of XML.
    
    You'd still have to parse the data when you pull it from the
    database, and you'd still have to output in XML format. This would
    require you to instantiate and object (or pull an object from a pool
    and apply the xml to it as a template... which I recommend if you're
    tossing objects out regularly)
    
    This setup would allow you to maintain the majority of your object
    heirarchy in a database and only loading it into memory when the
    data is needed. It gives you the random-access that you mentioned
    XML lacking, and an optimized search pattern that relational
    databases are well known for with all of the benefits of XML.
    
    A variety of these methods are used quite a bit in web development.
    Where you're pulling nontrivial data quite regularly. I doubt you'd
    consider the Microsoft website a trivial amount of data. It's
    written in XML/XSL although I think they use the XML features of
    their database.
    
    XML is a flat-text format designed for use with other tools. Oh
    yeah, another scheme would be an xml import/export with an SQL
    native format so you could use standard XML tools with your data,
    you'd just have to export it, use the tools and import it, a painful
    3 step procedure.
    
    > The only two exceptions I can think of are:
    
    I can think of quite a few more, but won't get into that now. I
    will say that I've used XML to store much larger amounts of data
    than 50 players or 25 mobs will require without a problem.
    
    > 3. You foolishly forget that prototypes become full products
    > against best intentions, and use XML in the prototype, intending
    > to replace it with proper DB access routines before using the
    > system - and then never get time to take them out, until it gets
    > really difficult to remove them, because now your whole DB is
    > stored as weakly structured XML.
    
    > I did number 3. Whoops.
    
    Sounds like you made a mistake and allowed it to take a tool from
    your toolbox. XML is not the end-all be-all, in fact it's a rather
    poor solution in many respects... in just as many areas it excells
    above all other data storage mechanisms. It simply depends on what
    you want to do.
    
    Another little something you'll discover is that not all XML parsers
    are equal in all areas. You may have to modify your programming
    style a little bit to get the best performance. Some parsers will
    give you the best performance doing single node selects, you'd have
    to know exactly what you want beforehand. Other ones do well by
    allowing you to select all the nodes and using an Iterator to sort
    thru them.
    
    I've done alot of research on java xml parsers (although hardly
    definitive) and I have a few issues with how some things are done.
    I could think of places which are used ALOT that should be optimized
    more. But that's a different thread entirely.
    
    -- Kwon J. Ekstrom
  • • Questions about ... XML as data format Adam
• R&D Matt Mihaly
• • R&D Dave Rickey
  • • R&D apollyon
    • • R&D shren
    • R&D Zach Collins {Siege}
    • • R&D Sean Kelly
      • • R&D Matt Mihaly
        • • R&D Sean Kelly
        • R&D Derek Licciardi
        • R&D Brian Bilek
        • • R&D Richard Aihoshi aka Jonric
          • • R&D Brian Bilek
            • • R&D Richard Aihoshi aka Jonric
              • • R&D Brian Bilek
          • R&D Damion Schubert
          • R&D Matt Mihaly
          • • R&D Brian Bilek
            • • R&D amanda@alfar.com
              • • R&D Brian Bilek
                • • R&D Koster, Raph
                  • • R&D Ron Gabbard
                    • R&D Amanda Walker
                    • R&D Frank Crowell
              • R&D Dave Rickey
              • • R&D Brian Bilek
              • R&D Matt Mihaly
              • • R&D Dave Rickey
            • R&D Richard Aihoshi aka Jonric
    • R&D Jessica Mulligan
    • R&D Damion Schubert
• Conversation logs? Robert Zubek
• • Conversation logs? Rudy Fink
  • • Conversation logs? Vincent Archer
  • Conversation logs? Shane Gough
• DGN: Elastic Advancement in MUDs? Jeff Lindsey
• • DGN: Elastic Advancement in MUDs? David B. Held
• Building histories off civilizations automatically adam Martin
• ADMIN: Virii and mail forgeries J C Lawrence
• Hi from the Dragon Empire's CLM Peter Tyson
• Linux gaming ( was Apple WWDC? ) Kevin Mack
• [TECH] Preferred LPC replacement? Jeff Bachtel
• • [TECH] Preferred LPC replacement? Damion Schubert
• Who `owns' conversation logs? Joshua Judson Rosen
• The Online Gaming Life for Me! Michael Tresca
• Boredom Ben Chambers
• • Boredom Michael Tresca
  • Boredom Matt Chatterley
• Law of Diminishing Marginal Utility [was Boredom] Ron Gabbard
• • Law of Diminishing Marginal Utility [was Boredom] Caliban Tiresias Darklock
• "MMOG" Bible Brian 'Psychochild' Green
• • "MMOG" Bible David Kennerly
• TECH: Single process v.s. multi process? Philip Mak
• • TECH: Single process v.s. multi process? Smith, David {Lynchburg}
  • TECH: Single process v.s. multi process? Bruce Mitchener
  • • TECH: Single process v.s. multi process? Bruce Mitchener
• In defense of "soloability" [was Law of Diminishing Marginal Utility] Clay
• • In defense of "soloability" [was Law of Diminishing Marginal Utility] apollyon
  • In defense of "soloability" [was Law of Diminishing Marginal Utility] Caliban Tiresias Darklock
  • In defense of "soloability" [was Law of Diminishi ng Marginal Utility] Koster, Raph
  • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Jeff Cole
    • In defense of "soloability" [was Law of Diminishing Marginal Utility] Damion Schubert
    • In defense of "soloability" [was Law of Diminishing Marginal Utility] John Buehler
    • • In defense of "soloability" [was Law of Diminishing Marginal Utility] amanda@alfar.com
      • • In defense of "soloability" [was Law of Diminishing Marginal Utility] John Buehler
  • In defense of "soloability" [was Law of Diminishing Marginal Utility] Michael Tresca
  • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Paul Schwanz
    • In defense of "soloability" [was Law of Diminishing Marginal Utility] Martin C. Martin
    • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Dave Rickey
      • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Vincent Archer
      • In defense of "soloability" [was Law of Diminishing Marginal Utility] Sanvean
      • In defense of "soloability" [was Law of Diminishing Marginal Utility] Matt Mihaly
      • • In defense of "soloability" [was Law of Diminishing Marginal Utility] F. Randall Farmer
        • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Matt Mihaly
      • In defense of "soloability" [was Law of Diminishing Marginal Utility] Michael Tresca
  • In defense of "soloability" [was Law of Diminishing Marginal Utility] Kwon Ekstrom
  • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Marian Griffith
    • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Yannick Jean
      • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Marian Griffith
  • In defense of "soloability" [was Law of Diminishing Marginal Utility] Ron Gabbard
  • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Sean Kelly
    • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Ron Gabbard
      • • In defense of "soloability" [was Law of Diminishing Marginal Utility] Sean Kelly
        • In defense of "soloability" [was Law of Diminishing Marginal Utility] Matt Mihaly
• Game shows Peter Tyson
• What keeps people interested in social muds? Martin C. Martin
• • What keeps people interested in social muds? Rudy Fink
  • • What keeps people interested in social muds? Martin C. Martin
    • • What keeps people interested in social muds? Joshua Judson Rosen
  • What keeps people interested in social muds? Ron Gabbard
  • What keeps people interested in social muds? Marc Bowden
  • What keeps people interested in social muds? Joshua Judson Rosen
  • • What keeps people interested in social muds? Matt Owen
  • What keeps people interested in social muds? lynx@lynx.purrsia.com
  • What keeps people interested in social muds? Richard A. Bartle
  • • What keeps people interested in social muds? Martin C. Martin
  • What keeps people interested in social muds? Richard A. Bartle
• New Beginings Drylar Levre
• • New Beginings Acius
  • New Beginings ceo@grexengine.com
  • • New Beginings Bruce Mitchener
    • New Beginings David B. Held
    • • New Beginings Kwon Ekstrom
      • • New Beginings David B. Held
        • • New Beginings Kwon Ekstrom
          • New Beginings Sean Kelly
      • New Beginings Lars Duening
      • • New Beginings David B. Held
        • • New Beginings Lars Duening
      • New Beginings Bruce Mitchener
      • • New Beginings David B. Held
        • • New Beginings Kwon Ekstrom
          • New Beginings Paul Schwanz
          • • New Beginings Zach Collins {Siege}
          • New Beginings Miroslav Silovic
        • New Beginings David B. Held
  • New Beginings Draymoor a Vin il'Rogina
  • New Beginings David B. Held
  • • New Beginings Kwon Ekstrom
    • New Beginings Bruce Mitchener
• [DGN] Creating a MUD Richard Krush
• • [DGN] Creating a MUD Acius
  • [DGN] Creating a MUD Caliban Tiresias Darklock
  • • [DGN] Creating a MUD Edward Glowacki
    • • [DGN] Creating a MUD Kwon Ekstrom
  • [DGN] Creating a MUD Edward Glowacki
  • • [DGN] Creating a MUD Fred Clift
    • • [DGN] Creating a MUD David Bennett
      • • [DGN] Creating a MUD fred@clift.org
  • [DGN] Creating a MUD Damion Schubert
  • • [DGN] Creating a MUD Taylor
  • [DGN] Creating a MUD Matt Mihaly
  • • [DGN] Creating a MUD Daniel.Harman@barclayscapital.com
• On the creation of constructive/social behaviours in online games! Marc Demesel
• [DGN] MUD Books James Edward Gray II
• • [DGN] MUD Books Scion Altera
  • [DGN] MUD Books Jeremy Noetzelman
  • [DGN] MUD Books Tand'a-ur
• Positive reinforcement for socializing [was In de fense of "soloability" ] Jeff Lindsey
• Character skill distribution and trade-offs Ron Gabbard
• • Character skill distribution and trade-offs Daniel.Harman@barclayscapital.com
  • • Character skill distribution and trade-offs Vincent Archer
    • • Character skill distribution and trade-offs Daniel.Harman@barclayscapital.com
    • Character skill distribution and trade-offs John Buehler
    • Character skill distribution and trade-offs Sean Kelly
    • • Character skill distribution and trade-offs Ron Gabbard
      • • Character skill distribution and trade-offs Travis Casey
        • Character skill distribution and trade-offs Rayzam
• Space partitioning, R-Trees? Dread Quixadhal
• • Space partitioning, R-Trees? Daniel.Harman@barclayscapital.com
  • • Space partitioning, R-Trees? Hans-Henrik Staerfeldt
  • Space partitioning, R-Trees? Crosbie Fitch