April 2001

• Camelot Beta 3 Dave Rickey
• • Camelot Beta 3 Daniel.Harman@barclayscapital.com
  • • Camelot Beta 3 Vincent Archer
    • • Camelot Beta 3 Derek Licciardi
      • Camelot Beta 3 Darrin Hyrup
      • • Camelot Beta 3 Vincent Archer
        • • Camelot Beta 3 Dave Rickey
          • • Camelot Beta 3 Darrin Hyrup
    • Camelot Beta 3 Auli
• Room Searching Jared
• • Room Searching shren
  • Room Searching Travis Casey
  • Room Searching Eli Stevens
  • Room Searching Derek Licciardi
  • • Room Searching Adam Martin
  • Room Searching Hans-Henrik Staerfeldt
  • Room Searching Daniel.Harman@barclayscapital.com
  • Room Searching David Bennett
• Sims Online -- WAS: MUD-Dev digest, Vol 1 #301 - 15 msgs Zak Jarvis
• Mera '01 report Cassandra
• • Mera '01 report Jake Song
  • • Mera '01 report J C Lawrence
    • • Mera '01 report Jake Song
      • • Mera '01 report J C Lawrence
        • • Mera '01 report Cassandra
• Learning about MUDs (was: MUD-Dev digest, Vol 1 #301 - 15 msgs) Brian 'Psychochild' Green
• • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) McQuaid, Brad
  • • Learning about MUDs (was: MUD-Dev digest, Vol 1 #301 - 15 msgs) Derek Licciardi
    • • Learning about MUDs (was: MUD-Dev digest, Vol 1 #301 - 15 msgs) Travis Nixon
    • Learning about MUDs (was: MUD-Dev digest, Vol 1 #301 - 15 msgs) Brian 'Psychochild' Green
    • • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) Daniel.Harman@barclayscapital.com
      • • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) Koster, Raph
      • Learning about MUDs (was: MUD-Dev digest, Vol 1 #301 - 15 msgs) Jim S
    • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) Freeman, Jeff
    • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) Daniel.Harman@barclayscapital.com
    • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) Vincent Archer
    • • Learning about MUDs (was: MUD-Dev digest, V ol 1 #301 - 15 msgs) Timothy Dang
• www.innbetweenworlds.com Klimon, Ian
• MERA '01 followup: Success critera Zak Jarvis
• MUD-Dev digest, Vol 1 #303 - 17 msgs Dr. Cat
• • MUD-Dev digest, Vol 1 #303 - 17 msgs Baron, Jonathan
  • • MUD-Dev digest, Vol 1 #303 - 17 msgs John Buehler
    • • MUD-Dev digest, Vol 1 #303 - 17 msgs Baron, Jonathan
• ADMIN: HTML email, the reasons against J C Lawrence
• Need for a departure from reality? Matt Mihaly
• Broken Economies (was Learning about MUDs) geoffrey@yorku.ca
• • Broken Economies (was Learning about MUDs) Koster, Raph
  • • Broken Economies (was Learning about MUDs) Timothy Dang
    • • Broken Economies (was Learning about MUDs) Koster, Raph
      • • Broken Economies (was Learning about MUDs) Timothy Dang
        • • Broken Economies (was Learning about MUDs) Madman Across the Water
  • Broken Economies (was Learning about MUDs) Derek Licciardi
  • • Broken Economies (was Learning about MUDs) Vincent Archer
  • Broken Economies (was Learning about MUDs) Sellers, Michael
• Balancing Melee vs Ranged Combat in Games Which Model Space Daniel.Harman@barclayscapital.com
• • Balancing Melee vs Ranged Combat in Games Which Model Space Zak Jarvis
  • • Balancing Melee vs Ranged Combat in Games Which Model Space John Buehler
  • Balancing Melee vs Ranged Combat in Games Which Model Space Brian Hook
  • • Balancing Melee vs Ranged Combat in Games Which Model Space Jerrith
    • • Balancing Melee vs Ranged Combat in Games Which Model Space Brian Hook
      • • Balancing Melee vs Ranged Combat in Games Which Model Space Jerrith
        • • Balancing Melee vs Ranged Combat in Games Which Model Space Brian Hook
          • • Balancing Melee vs Ranged Combat in Games Which Model Space John Buehler
            • • Balancing Melee vs Ranged Combat in Games Which Model Space Brian Hook
              • • Balancing Melee vs Ranged Combat in Games Which Model Space John Buehler
                • • Balancing Melee vs Ranged Combat in Games Which Model Space Brian Hook
                  • • Balancing Melee vs Ranged Combat in Games Which Model Space John Buehler
                    • • Balancing Melee vs Ranged Combat in Games Which Model Space Travis Casey
                      • • Balancing Melee vs Ranged Combat in Games Which Model Space John Buehler
                    • Balancing Melee vs Ranged Combat in Games Which Model Space Ben Sizer
        • Balancing Melee vs Ranged Combat in Games Which Mod el Space Daniel.Harman@barclayscapital.com
      • Balancing Melee vs Ranged Combat in Games Which Model Space shren
      • • Balancing Melee vs Ranged Combat in Games Which Model Space Travis Casey
  • Balancing Melee vs Ranged Combat in Games Which Model Space shren
  • Balancing Melee vs Ranged Combat in Games Which Model Space Philip
  • Balancing Melee vs Ranged Combat in Games Which Model Space Hal Bonnin
  • • Balancing Melee vs Ranged Combat in Games Which Model Space Brian Hook
  • Balancing Melee vs Ranged Combat in Games Which Model Space Kwon Ekstrom
  • • Balancing Melee vs Ranged Combat in Games Which Model Space Travis Casey
  • Balancing Melee vs Ranged Combat in Games Which Model Space rayzam
• RE:The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Sellers, Michael
• Sv: Balancing Melee vs Ranged Combat in Games Which Model Space Nicolai Hansen
• • Sv: Balancing Melee vs Ranged Combat in Games Which Model Space Travis Casey
  • • Sv: Balancing Melee vs Ranged Combat in Games Which Model Space Kwon Ekstrom
    • • Sv: Balancing Melee vs Ranged Combat in Games Which Model Space Travis Casey
• ADMIN: Subject header maintenance (was: Broken currencies) J C Lawrence
• Broken currencies Matt Mihaly
• • Broken currencies Jim S
  • • Broken currencies Koster, Raph
    • Broken currencies Lars Duening
    • • Broken currencies Matt Mihaly
      • • Broken currencies Lars Duening
  • Broken currencies Brian 'Psychochild' Green
  • • Broken currencies Matt Mihaly
    • Broken currencies Timothy Dang
  • Broken currencies Phillip Lenhardt
  • • Broken currencies Matt Mihaly
    • • Broken currencies Phillip Lenhardt
      • • Broken currencies John Buehler
        • • Broken currencies Derek Licciardi
          • • Broken currencies Ben Sizer
            • • Broken currencies Adam Martin
              • • Broken currencies Ben Sizer
        • Broken currencies Matt Mihaly
      • Broken currencies Timothy Dang
  • Broken currencies Michael Dekker
  • • Broken currencies Miroslav Silovic
    • • Broken currencies Matt Mihaly
    • Broken currencies Timothy Dang
• [DGN] Balancing Melee vs Ranged Combat in Games Which Model Space Ananda Dawnsinger
• • [DGN] Balancing Melee vs Ranged Combat in Games Which Model Space Travis Casey
• Broken currencies Matt Mihaly
• The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Baron, Jonathan
• • The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Sellers, Michael
  • • The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Baron, Jonathan
  • The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Dave Rickey
  • • The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) F. Randall Farmer
  • The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Lee Sheldon
• The Monad (was: Broken Economies) shren
• • The Monad (was: Broken Economies) Matt Mihaly
  • • The Monad (was: Broken Economies) John Buehler
    • • The Monad (was: Broken Economies) Matt Mihaly
• A User's Guide to TCP Windows J C Lawrence
• Balance J C Lawrence
• Economic & Derek Licciardi
• • Economic & Matt Mihaly
  • • Economic & Timothy Dang
• Money supply in game economies (formerly Broken economies) Matt Mihaly
• • Money supply in game economies (formerly Brokeneconomies) geoffrey@yorku.ca
  • • Money supply in game economies (formerly Brokeneconomies) Matt Mihaly
    • • Money supply in game economies (formerly Brokeneconomies) Timothy Dang
  • Money supply in game economies (formerly Broken eco nomies) Koster, Raph
  • • Money supply in game economies (formerly Broken eco nomies) J C Lawrence
    • • Money supply in game economies (formerly Broken eco nomies) Matt Mihaly
      • • Money supply in game economies (formerly Broken economies) Adam Martin
  • Money supply in game economies (formerly Broken economies) Timothy Dang
  • • Money supply in game economies (formerly Broken eco nomies) Freeman, Jeff
• [DGN] Balancing Melee/Ranged Combat Kwon Ekstrom
• Room Searching - how about doors? Gavin Doughtie
• Tracking Hulbert, Leland
• • Tracking Mordengaard
  • • Tracking Sanvean
  • Tracking Ryan P.
  • • Tracking Shawn L Johnston
• Online Games get an overview Koster, Raph
• [DGN] Money supply in game economies (formerly Brok en economies) Daniel.Harman@barclayscapital.com
• [DSG] Concrete idea behind currency (was: The Monad and Broken Economies) Paul Schwanz
• Majestic (was The Sims Online) Matt Mihaly
• • Majestic (was The Sims Online) Baron, Jonathan
  • • Majestic (was The Sims Online) Matt Mihaly
    • • Majestic (was The Sims Online) Baron, Jonathan
      • Majestic (was The Sims Online) Sellers, Michael
      • • Majestic (was The Sims Online) Matt Mihaly
• Majestic (was The Sims Online) Matt Mihaly
• Identity and Economies [was Money supply in game economies (formerly Broken eco nomies) ] Joe Andrieu
• Virtual Suicide (Was: Money supply in game economies) Dave Rickey
• • Virtual Suicide (Was: Money supply in game economie s) Daniel.Harman@barclayscapital.com
  • • Virtual Suicide (Was: Money supply in game economies) Dave Rickey
    • • Virtual Suicide (Was: Money supply in game economie s) Daniel.Harman@barclayscapital.com
      • • Virtual Suicide (Was: Money supply in game economies) Dave Rickey
• The Sims Online (was MUD-Dev digest, Vol 1 #301 - 15 msgs) Baron, Jonathan
• Distributed Muds Jim Craig
• [DSG] Money supply in game economies (was: Broken Economies) Paul Schwanz
• TECH DGN: (was Broken currencies) Nathan F.Yospe
• [DESIGN] Economic & Marian Griffith
• • [DESIGN] Economic & Derek Licciardi
  • • [DESIGN] Economic & Marian Griffith
    • • [DESIGN] Economic & John Buehler
      • [DESIGN] Economic & Travis Nixon
      • • [DESIGN] Economic & Travis Casey
        • [DESIGN] Economic & Matt Mihaly
        • • [DESIGN] Economic & Travis Nixon
          • • [DESIGN] Economic & Matt Mihaly
• Author Unknown (was: Money supply in game economies) Emil Eifrém
• TECH: Distributed Muds Emil Eifrém
• • TECH: Distributed Muds Jim Craig
  • • TECH: Distributed Muds Frank Crowell
    • TECH: Distributed Muds Colin Coghill
    • • TECH: Distributed Muds Vincent Archer
      • • TECH: Distributed Muds Derek Snider
        • • TECH: Distributed Muds Vincent Archer
          • • TECH: Distributed Muds J C Lawrence
            • TECH: Distributed Muds Derek Snider
            • • TECH: Distributed Muds J C Lawrence
              • • TECH: Distributed Muds Bruce
                • • TECH: Distributed Muds J C Lawrence
                • TECH: Distributed Muds Vincent Archer
                • TECH: Distributed Muds Derek Snider
                • • TECH: Distributed Muds J C Lawrence
                  • • TECH: Distributed Muds Derek Snider
                    • • TECH: Distributed Muds Brian Hook
                      • • TECH: Distributed Muds Derek Snider
                        • • TECH: Distributed Muds Brian Hook
                  • TECH: Distributed Muds Adam Martin
• Shattered World's economy John W Pierce
• • Shattered World's economy Erik Jarvi
• [BIZ] Advertising sprawl (yahoo) J C Lawrence
• • [BIZ] Advertising sprawl (yahoo) Frank Crowell
  • [BIZ] Advertising sprawl (yahoo) Lars Duening
  • • [BIZ] Advertising sprawl (yahoo) Vincent Archer
    • • [BIZ] Advertising sprawl (yahoo) Dave Rickey
      • • [BIZ] Advertising sprawl (yahoo) Matt Mihaly
        • [BIZ] Advertising sprawl (yahoo) Vincent Archer
        • [BIZ] Advertising sprawl (yahoo) shren
        • • [BIZ] Advertising sprawl (yahoo) John Buehler
        • [BIZ] Advertising sprawl (yahoo) Ian Macintosh
      • [BIZ] Advertising sprawl (yahoo) Daniel.Harman@barclayscapital.com
    • [BIZ] Advertising sprawl (yahoo) Matt Mihaly
    • • [BIZ] Advertising sprawl (yahoo) Caliban Tiresias Darklock
      • • [BIZ] Advertising sprawl (yahoo) Matt Mihaly
        • • [BIZ] Advertising sprawl (yahoo) J C Lawrence
          • • [BIZ] Advertising sprawl (yahoo) Travis Casey
      • [BIZ] Advertising sprawl (yahoo) Daniel.Harman@barclayscapital.com
      • • [BIZ] Advertising sprawl (yahoo) Matt Mihaly
        • [BIZ] Advertising sprawl (yahoo) Vincent Archer
  • [BIZ] Advertising sprawl (yahoo) Matt Mihaly
• RG Interview Cassandra
• NEWS DGN Wired News article about EQ Zak Jarvis
• [DESIGN] Economy goals (was: Broken currencies) Vincent Archer
• • [DESIGN] Economy goals (was: Broken currencies) shren
  • [DESIGN] Economy goals (was: Broken currencies) Freeman, Jeff
  • • [DESIGN] Economy goals (was: Broken currencies) Derek Licciardi
    • • [DESIGN] Economy goals (was: Broken currencies) Vincent Archer
      • • [DESIGN] Economy goals (was: Broken currencies) Freeman, Jeff
        • [DESIGN] Economy goals (was: Broken currencies) Adam Martin
• Curtailing the 'Super-Rich Effect' Bob McFakename
• • Curtailing the 'Super-Rich Effect' Lynx
  • • Curtailing the 'Super-Rich Effect' Matt Mihaly
    • • Curtailing the 'Super-Rich Effect' Bob McFakename
      • • Curtailing the 'Super-Rich Effect' Matt Mihaly
        • • Curtailing the 'Super-Rich Effect' Phillip Lenhardt
          • • Curtailing the 'Super-Rich Effect' Matt Mihaly
          • Curtailing the 'Super-Rich Effect' Travis Casey
  • Curtailing the 'Super-Rich Effect' Mordengaard
  • Curtailing the 'Super-Rich Effect' Michael Tresca
  • • Curtailing the 'Super-Rich Effect' shren
  • Curtailing the 'Super-Rich Effect' Trump
  • • Curtailing the 'Super-Rich Effect' Daniel.Harman@barclayscapital.com
    • • Curtailing the 'Super-Rich Effect' Dave Rickey
    • Curtailing the 'Super-Rich Effect' Michael Tresca
• Movie grosses Matt Mihaly
• • Movie grosses Brian 'Psychochild' Green
  • • Movie grosses Koster, Raph
    • Movie grosses Matt Mihaly
  • Movie grosses Myschyf
  • • Movie grosses Matt Mihaly
• StarPeace (was Money supply in game economies) Michael Dekker
• • StarPeace (was Money supply in game economies) Ling Lo
  • • StarPeace (was Money supply in game economies) shren
• TECH: Distributed Muds Bobby Martin
• • TECH: Distributed Muds Adam Martin
  • TECH: Distributed Muds Bruce
  • • TECH: Distributed Muds Vincent Archer
    • • TECH: Distributed Muds Chris Gray
      • • TECH: Distributed Muds Brian Hook
        • • TECH: Distributed Muds Nick Walker
          • • TECH: Distributed Muds J C Lawrence
          • TECH: Distributed Muds Derek Snider
          • • TECH: Distributed Muds Brian Hook
            • • TECH: Distributed Muds shren
            • TECH: Distributed Muds J C Lawrence
            • • TECH: Distributed Muds Brian Hook
              • • TECH: Distributed Muds J C Lawrence
              • TECH: Distributed Muds Derek Snider
              • • TECH: Distributed Muds J C Lawrence
                • • TECH: Distributed Muds Derek Snider
                  • • TECH: Distributed Muds J C Lawrence
                    • • TECH: Distributed Muds shren
                      • TECH: Distributed Muds Eli Stevens
                      • • TECH: Distributed Muds John Buehler
                        • • TECH: Distributed Muds Kevin Littlejohn
                          • • TECH: Distributed Muds John Buehler
                • TECH: Distributed Muds Ola Fosheim Grøstad
                • • TECH: Distributed Muds Chris Gray
                  • TECH: Distributed Muds Derek Snider
                  • • TECH: Distributed Muds J C Lawrence
                    • • TECH: Distributed Muds Derek Snider
                      • • TECH: Distributed Muds J C Lawrence
                        • TECH: Distributed Muds Matthew D. Fuller
                        • • TECH: Distributed Muds Derek Snider
                          • TECH: Distributed Muds Vincent Archer
              • TECH: Distributed Muds Ola Fosheim Grøstad
            • TECH: Distributed Muds Christopher Kohnert
            • • TECH: Distributed Muds Derek Snider
              • • TECH: Distributed Muds Chris Gray
                • • TECH: Distributed Muds Derek Snider
                  • • TECH: Distributed Muds Caliban Tiresias Darklock
                    • • TECH: Distributed Muds Derek Snider
                      • TECH: Distributed Muds Jon Lambert
                      • • TECH: Distributed Muds Derek Snider
                        • • TECH: Distributed Muds Caliban Tiresias Darklock
                          • • TECH: Distributed Muds Jon Lambert
                            • • TECH: Distributed Muds Matthew D. Fuller
                              • • TECH: Distributed Muds Owen
                                • TECH: Distributed Muds Jon Lambert
                              • TECH: Distributed Muds Caliban Tiresias Darklock
                              • • TECH: Distributed Muds shren
                          • TECH: Distributed Muds Jon Lambert
                        • TECH: Distributed Muds Caliban Tiresias Darklock
                        • • TECH: Distributed Muds Jon Leonard
                          • • TECH: Distributed Muds Bruce
                          • TECH: Distributed Muds Kevin Littlejohn
                          • TECH: Distributed Muds Bruce
                    • TECH: Distributed Muds J C Lawrence
                    • • TECH: Distributed Muds Chris Gray
                      • • TECH: Distributed Muds J C Lawrence
                        • • TECH: Distributed Muds Chris Gray
                          • • TECH: Distributed Muds J C Lawrence
                            • TECH: Distributed Muds Kwon Ekstrom
                            • • TECH: Distributed Muds Chris Gray
                              • TECH: Distributed Muds Bruce
                              • • TECH: Distributed Muds Chris Gray
                                • • TECH: Distributed Muds Bruce
                                • TECH: Distributed Muds Kwon Ekstrom
                                • • TECH: Distributed Muds Bruce
                                • TECH: Distributed Muds Neil Brown
              • TECH: Distributed Muds J C Lawrence
              • • TECH: Distributed Muds Caliban Tiresias Darklock
                • • TECH: Distributed Muds J C Lawrence
                  • • TECH: Distributed Muds Bruce
                    • TECH: Distributed Muds Caliban Tiresias Darklock
                  • TECH: Distributed Muds Derek Snider
                  • • TECH: Distributed Muds J C Lawrence
                    • • TECH: Distributed Muds shren
                      • • TECH: Distributed Muds John Buehler
                • TECH: Distributed Muds Steven Fleischaker
                • • TECH: Distributed Muds Jon Lambert
                  • • TECH: Distributed Muds Daniel.Harman@barclayscapital.com
                    • • TECH: Distributed Muds Chris Gray
                      • • TECH: Distributed Muds Daniel.Harman@barclayscapital.com
                  • TECH: Distributed Muds J C Lawrence
                  • TECH: Distributed Muds Caliban Tiresias Darklock
                • TECH: Distributed Muds Christopher Kohnert
                • • TECH: Distributed Muds J C Lawrence
                • TECH: Distributed Muds Chris Gray
                • • TECH: Distributed Muds J C Lawrence
                  • • TECH: Distributed Muds Chris Gray
                • TECH: Distributed Muds Kwon Ekstrom
      • TECH: Distributed Muds Bruce
      • • TECH: Distributed Muds Vincent Archer
        • • TECH: Distributed Muds Brad Roberts
          • • TECH: Distributed Muds Vincent Archer
• [DESIGN] Economic & Currency Solutions Phillip Lenhardt
• Curtailing the 'Super-Rich' Effect Bob McFakename
• • Curtailing the 'Super-Rich' Effect Daniel.Harman@barclayscapital.com
  • • Curtailing the 'Super-Rich' Effect Jim S
• TECH: Flash Crowds and overflow control Gavin Doughtie
• • TECH: Flash Crowds and overflow control Marc Bowden
  • • TECH: Flash Crowds and overflow control Vincent Archer
    • • TECH: Flash Crowds and overflow control Koster, Raph
      • • TECH: Flash Crowds and overflow control J C Lawrence
        • • TECH: Flash Crowds and overflow control Marc Bowden
  • TECH: Flash Crowds and overflow control Justin Rogers
• BUSINESS: I need Online Gaming Revenue Projections. F. Randall Farmer
• [DESIGN] Economic & Currency Solutions Vincent Archer
• • [DESIGN] Economic & Currency Solutions Timothy Dang
  • [DESIGN] Economic & Currency Solutions Taylor Daynes
  • • [DESIGN] Economic & Currency Solutions Vincent Archer
• ADMIN: Moving... J C Lawrence
• UO and eBay figures Koster, Raph
• MUD for sale Chris Gray
• • MUD for sale Caliban Tiresias Darklock
  • MUD for sale Dave Rickey
  • • MUD for sale Bruce
    • • MUD for sale Chris Gray
      • MUD for sale Kevin Littlejohn
• ADMIN: The move and current status J C Lawrence
• Virtual Suicide (Was: Money supply in game economies) Martin Burke
• TECH: Java ARMI Bobby Martin
• TECH: AmigaMud DB questions Bruce
• • TECH: AmigaMud DB questions Chris Gray
  • • TECH: AmigaMud DB questions Bruce
    • • TECH: AmigaMud DB questions Chris Gray
      • TECH: AmigaMud DB questions Jon Lambert
• Kuro5hin: What can games teach us about human-computer interaction? J C Lawrence
• Review of Galactic Emperor: Succession in LumTheMad's Forums Christopher Allen
• • Review of Galactic Emperor: Succession in LumTheMad's Forums Ling Lo
  • • Review of Galactic Emperor: Succession in LumTheMad's Forums J C Lawrence
• [BIZ] New EQ Expansion Daniel.Harman@barclayscapital.com
• Twisted Python J C Lawrence
• [TECH] Distributed MUD Kwon Ekstrom
• • [TECH] Distributed MUD Jeremy Noetzelman
  • • [TECH] Distributed MUD Kwon Ekstrom
  • [TECH] Distributed MUD J C Lawrence
• EQ: what makes a zone interesting? Frank Crowell
• • EQ: what makes a zone interesting? J C Lawrence
  • EQ: what makes a zone interesting? shren
  • • EQ: what makes a zone interesting? J C Lawrence
    • EQ: what makes a zone interesting? Elia Morling
• Imaginary Realities - April 2001 David Bennett
• [BIZ][TECH] worlds.com gets patent bruce@puremagic.com
• • [BIZ][TECH] worlds.com gets patent Jessica Mulligan
  • • [BIZ][TECH] worlds.com gets patent Bruce
    • • [BIZ][TECH] worlds.com gets patent Frank Crowell
    • [BIZ][TECH] worlds.com gets patent Kwon Ekstrom
    • • [BIZ][TECH] worlds.com gets patent John Robert Arras
    • [BIZ][TECH] worlds.com gets patent Jon Lambert
    • • [BIZ][TECH] worlds.com gets patent John Buehler
  • [BIZ][TECH] worlds.com gets patent Frank Crowell
  • [BIZ][TECH] worlds.com gets patent Travis Nixon
  • • [BIZ][TECH] worlds.com gets patent Marian Griffith
  • [BIZ][TECH] worlds.com gets patent John Buehler
  • • [BIZ][TECH] worlds.com gets patent Dave Rickey
  • [BIZ][TECH] worlds.com gets patent Derek Licciardi
• called shots Josh Rollyson
• • called shots Matt Mihaly
  • called shots Mordengaard
  • called shots Ling Lo
  • called shots shren
  • • called shots John Buehler
    • called shots Kwon Ekstrom
    • • called shots Travis Casey
  • called shots Travis Casey
• TECH: Distributed Muds J C Lawrence
• • TECH: Distributed Muds Brad Roberts
  • • TECH: Distributed Muds J C Lawrence
• TECH: Distributed Muds Dominic J. Eidson
• TECH: reliablity (was: Distributed Muds) Bruce
• • TECH: reliablity (was: Distributed Muds) Derek Snider
  • • TECH: reliablity (was: Distributed Muds) Bruce
    • • TECH: reliablity (was: Distributed Muds) Derek Snider
      • • TECH: reliablity (was: Distributed Muds) Alex
        • • TECH: reliablity (was: Distributed Muds) shren
          • • TECH: reliablity (was: Distributed Muds) Ola Fosheim Grøstad
          • TECH: reliablity (was: Distributed Muds) Derek Snider
  • TECH: reliablity (was: Distributed Muds) Ola Fosheim Grøstad
  • • TECH: reliablity (was: Distributed Muds) John Buehler
    • • TECH: reliablity (was: Distributed Muds) Ola Fosheim Grøstad
      • • TECH: reliablity (was: Distributed Muds) John Buehler
    • TECH: reliablity (was: Distributed Muds) Kwon Ekstrom
    • TECH: reliablity (was: Distributed Muds) Derek Licciardi
    • • TECH: reliablity (was: Distributed Muds) Ola Fosheim Grøstad
      • • TECH: reliablity (was: Distributed Muds) John Buehler
        • • TECH: reliablity (was: Distributed Muds) Ola Fosheim Grøstad
          • • TECH: reliablity (was: Distributed Muds) John Buehler
              Ola Fosheim Grostad writes:
              > John Buehler wrote:
              
              >> Oh, I think I get it now. There are no component design tenants.
              >> The size of a component is up to you, and the abstraction distance
              >> from the raw functionality that you are accessing is up to you.
              
              > Uhm, but if so then there is no such thing as component design...?
              > Sure you can tweak OO and structured programming and what not to fit
              > your needs, but...
              
              There was a component design methodology that *we* were using, but
              component technology does not require a specific design methodology by
              a given organization. We used small components and a mechanism to
              graphically wire together those components to make bigger components.
              We didn't want to try to build high quality big components. They're a
              real challenge to build.
              
              > Again, I do see that components make sense in some areas, just not
              > in the MUD core. Except maybe if you have a frozen design and need
              > to speed up development using an incremental strategy (as opposed to
              > an evolutionary one).
              
              I think we need to talk about the specifics of a MUD core. I see some
              standard tasks and some nonstandard ones inside of a MUD. Those that
              are standard can use existing components. Those that are nonstandard
              can be incorporated into custom components.
              
              > Isn't it true that the further you go towards pure components, the
              > closer you get to the waterfall model (which was specification
              > based!) and structured programming? That's how I see it anyway.
              
              To me, the waterfall model suggests an inflexibility in the entire
              process. Define all your specifications, give them to your engineers
              and they build the software. We found out very quickly that
              specifications must be given room to breathe. But the 'breathing
              process' must be very carefully structured, and that's part of what
              the precise contract and component development methodology attack.
              Imagine fast versioning of specifications and implementations instead
              of just doing in-place modifications of both whenever you felt you
              needed to. The fast versioning approach means that you recognize the
              fact that you're diddling with the contract and the implementation.
              If there is code out there still thinking that it's working with the
              old contract, you'll get immediate feedback when you try to run your
              application. That, instead of the code running, but running
              strangely.
              
              The COM mechanism for dealing with contracts is to use GUIDs, which
              embody every element of a contract that can be expressed. That's
              because they're just identifiers. But the important point is that it
              represents more than just a function signature. It represents the
              behavior that the function (or set of functions) is required to
              deliver. Change the contractual behavior and the GUID changes.
              Software looking for the old GUID from the new component will get
              upset when the new component blinks innocently, wondering what the
              client is talking about.
              
              >> And you would be creating a component as soon as you construct that
              >> module. You don't call it a component, but it is. And you won't
              >> be managing the contracts that relate to it very strictly, and that
              >> will burn you whenever you blink or lose concentration while
              >> working with it.
              
              > And that can't happen with components? :)
              
              Not when you follow a strict component methodology. That methodology
              is intentionally focused on this problem. Make contracts a first
              order member of your design and manage them carefully. If you open a
              specification and dink around with it, it automatically gets
              versioned, producing new GUID (a new contract identifier). Voila,
              nobody implements that contract unless you manually go and ensure that
              specific components do. Given the proper testing tools, you can't
              even check that component back into the public population of
              components until it passes the tests that verify that it behaves
              according to the new contract. This was the stuff that we were
              working on and working towards. They're still at it from what I
              understand.
              
              > (I do use invariants and produce code to check them where possible.
              > Unfortunately I don't get to program a whole lot, but when I do...)
              
              And these are the tools of a diligent engineer. The testing
              methodology that we were after was intended to ensure that an
              engineer, diligent or not, would produce a high quality component.
              Engineers who start out diligent will be able to crank components out
              far faster than those who do not. As it should be.
              
              >> The first component does general collision detection. Then when
              >> you only want an area spell that affects level 40 dwarves, you
              >> construct a new contract and a new component. Fortunately, you
              >> have a general purpose collision detection component that you can
              >> use for the lion's share of the work (through aggregation or
              >> delegation, not code reuse).
              
              > So now you have a less efficient design with additional methods you
              > could otherwise have avoided. With lots of interdependencies, it
              > will become pure hell to specify useful pre and postconditions, not
              > to mention reading and updating them :). You may of course reduce
              > what is covered by the pre/post conditions, but then they become
              > less useful.
              
              I would have assumed that additional preconditions on the existing
              contract would have worked just dandy. That produces a new contract,
              of course, but one that should be easily implemented using the
              existing component. I don't see the introduction of additional
              methods at all. But I may be missing something.
              
              > To cut down the searchtime you basically need to let the spatial
              > datastructure "know" more about the objects and structures that
              > contain information about them. (for instance, by storing avatars
              > and other objects in separate sets, knowing somehow that objID x is
              > a dwarf is an avatar or possibly knowing intimately about other
              > datastructures that is maintaining information about objects) But
              > the more units know about each other the less component based the
              > design becomes...
              
              This is a design issue. Did the engineer who came up with the
              contract for collision detection permit culling? Does it maintain its
              own internal data structures or does it have a means of traversing
              foreign data structures? Do I pass in the structures or does it
              maintain a reference to the component holding the avatars and such?
              
              There are so many scenario permutations that are possible that we
              could go around on this forever. You can postulate an inappropriate
              contract and I can postulate an appropriate one. Because collision
              detection is a generic problem, I can easily see this component being
              fairly open to accessing a number of different schemas that contain
              object location and dimension information.
              
              >> To obtain an interface requires a call and a simple lookup to
              >> retrieve a pointer. To make a method call, a pointer dereference
              >> and a procedure call are the overhead. To the best of my
              >> knowledge, it's the same overhead as C++ (actually COM was required
              >> to being compatible with Microsoft C++). If you go with
              >> fine-grained components, you can accumulate significant call
              >> overhead. If you go with coarse-grained components, the call
              >> overhead is limited. Which is, of course, the same equation as for
              >> any pile of code.
              
              > Except that with components the idea is that everything should pass
              > explicitly through a clean-cut interface. In practical decent C++
              > code you do use a lot of inlined methods and templates and try to
              > reduce the number of virtual ones. Wherever you know what class you
              > are calling you don't really have to go for a virtual one anyway...
              > I like shallow class hierarchies.
              
              All software is governed by precise contracts. This is simply a
              statement of fact because computers are Turing machines. Specific
              things happen as a result of running software. Component
              methodologies insist that engineers figure out what that behavior is
              and write it down in the form of a contract document (well, actually,
              we come up with the contracts, then implement them...). How chunks of
              code are embodied is up for grabs. Using COM, we are limited to
              embodying contract implementations as either a function call or as a
              COM interface. There is nothing about precise contracts and
              components that says that an implementation cannot accomodate
              inlining. As for templates, there's a way of dealing with
              parameterized types without duplicating code.
              
              For what it's worth, we also liked shallow class hierarchies. As in
              no depth. We didn't do contract inheritance. We did do contract
              construction from base contracts, but that's different.
              
              JB
        • TECH: reliablity (was: Distributed Muds) Kwon Ekstrom
• TECH: prefetching/madvise (was: Distributed Muds) Bruce
• • TECH: prefetching/madvise (was: Distributed Muds) Matthew D. Fuller
• TECH: Distributed Muds J C Lawrence
• • TECH: Distributed Muds Scion Altera
• Re:called shots Eric Lamy
• Where are we now? Greg Munt
• • Where are we now? Ronan Farrell
  • • Where are we now? Matt Mihaly
    • Where are we now? Greg Munt
    • • Where are we now? Ronan Farrell
      • • Where are we now? Adam Martin
        • • Where are we now? Bryce Harrington
        • Where are we now? Deidril
        • • Where are we now? Bryce Harrington
        • Where are we now? Elia Morling
      • Where are we now? Matt Mihaly
      • • Where are we now? McManus, Susan
  • Where are we now? Matt Mihaly
  • Where are we now? Kwon Ekstrom
  • • Where are we now? Brian Hook
    • • Where are we now? Kwon Ekstrom
      • • Where are we now? Michael Tresca
        • • Where are we now? S. Patrick Gallaty
          • • Where are we now? Greg Munt
            • • Where are we now? S. Patrick Gallaty
      • Where are we now? Matt Mihaly
  • Where are we now? Koster, Raph
  • • Where are we now? Greg Munt
    • • Where are we now? Matt Mihaly
      • • Where are we now? Greg Munt
        • • Where are we now? Matt Mihaly
  • Where are we now? Bruce
  • • Where are we now? Ola Fosheim Grøstad
    • • Where are we now? Koster, Raph
      • • Where are we now? Richard A. Bartle
        • Where are we now? Ola Fosheim Grøstad
  • Where are we now? Bruce
  • • Where are we now? Greg Munt
    • • Where are we now? Koster, Raph
      • • Where are we now? rayzam
  • Where are we now? Madman Across the Water
  • • Where are we now? Bryce Harrington
    • • Where are we now? Madman Across the Water
      • • Where are we now? Freeman, Jeff
• TECH: DBM vs BDB speeds (was: AmigaMud DB questions) Bruce
• • TECH: DBM vs BDB speeds (was: AmigaMud DB questions) Jon Lambert
  • • TECH: DBM vs BDB speeds (was: AmigaMud DB questions) Bruce
• fault tolerance and character files Steven Fleischaker
• • fault tolerance and character files Kwon Ekstrom
  • • fault tolerance and character files Bruce
    • • fault tolerance and character files Kwon Ekstrom
    • fault tolerance and character files Vincent Archer