October 1998
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Brandon J. Rickman
- Storytelling vs. Simulationist (Was Room descriptions) Adam Wiggins
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Adam Wiggins
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Caliban Tiresias Darklock
- Storytelling vs. Simulationist (Was Room descriptions) Peck, Matthew x96724c1
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Peck, Matthew x96724c1
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Caliban Tiresias Darklock
- Storytelling vs. Simulationist (Was Room descriptions) Caliban Tiresias Darklock
- Storytelling vs. Simulationist (Was Room de scriptions) Koster, Raph
- Storytelling vs. Simulationist (Was Room descriptions) Adam Wiggins
- Storytelling vs. Simulationist (Was Room descriptions) Travis S. Casey
- Storytelling vs. Simulationist (Was Roomdescriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room de scriptions) Koster, Raph
- simulation vs. storytelling is a fallacious distinction James Wilson
- simulation vs. storytelling is a fallacious distinction ApplePiMan@aol.com
- simulation vs. storytelling is a fallacious distinction James Wilson
- simulation vs. storytelling is a fallacious distinction ApplePiMan@aol.com
- [DESIGN] To kill or not to kill? (non-violent conflict) The Wildman
- [DESIGN] To kill or not to kill? (non-violent conflict) Richard Woolcock
- [DESIGN] To kill or not to kill? (non-violent conflict) Marian Griffith
- [DESIGN] To kill or not to kill? (non-violent conflict) The Wildman
- [DESIGN] To kill or not to kill? (non-violent conflict) Robert Woods
- [DESIGN] To kill or not to kill? (non-violent conflict) Marc Hernandez
- Quest engines Koster, Raph
- Quest engines ApplePiMan@aol.com
- Quest engines Michael.Willey@abnamro.com
- Quest engines Hal Black
- [Off-Topic] Patents (Was Storytelling vs. Simulationist) ApplePiMan@aol.com
- Psychopaths Ola Fosheim Grøstad
- Psychopaths Koster, Raph
- Storytelling patents (Storytelling vs. Simulationist) Ola Fosheim Grøstad
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- Spoofing (Psychopaths) Ola Fosheim Grøstad
- Spoofing (Psychopaths) Koster, Raph
- Spoofing (Psychopaths) Ola Fosheim Grøstad
- Spoofing (Psychopaths) Richard Bartle
- Spoofing (Psychopaths) Richard Bartle
- Spoofing (Psychopaths) Ola Fosheim Grøstad
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Adam Wiggins
- Terrain/Landmass & GIF/BMP Chris Gray
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Hal Black
- Terrain/Landmass & GIF/BMP John Bertoglio
- Terrain/Landmass & GIF/BMP Petri Virkkula
- Terrain/Landmass & GIF/BMP Caliban Tiresias Darklock
- Terrain/Landmass & GIF/BMP Niklas Elmqvist
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Marc Hernandez
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Chris Gray
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Dominic J. Eidson
- Current Projects Alex Stewart
- Current Projects Caliban Tiresias Darklock
- Current Projects Robert Woods
- Current Projects James Wilson
- Current Projects Peck, Matthew x96724c1
- Current Projects Robert Woods
- Current Projects T. Alexander Popiel
- Current Projects Travis S. Casey
- Current Projects Joel Kelso
- Current Projects The Arrow
- Current Projects Ryan Prince
- Current Projects Wilburn, E.J.
- Current Projects Michael.Willey@abnamro.com
- Current Projects David Bennett
- Current Projects chris@realm.zfn.uni-bremen.de
- Current Projects Andrew Wilson
- Current Projects Holly Sommer
- Current Projects Scatter
- Current Projects Michael.Willey@abnamro.com
- Current Projects Niklas Elmqvist
- Red Black Tree ? Valerio Santinelli
- Red Black Tree ? T. Alexander Popiel
- Red Black Tree ? Caliban Tiresias Darklock
- Red Black Tree ? T. Alexander Popiel
- Red Black Tree ? Caliban Tiresias Darklock
- Red Black Tree ? Ben Greear
- MUVE vs. MUD [was Current Projects] Alex Stewart
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Jon A. Lambert
- Laws of Online World Design Ling
- Laws of Online World Design Adam Wiggins
- Laws of Online World Design Michael.Willey@abnamro.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design manta@pobox.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design James Wilson
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Ola Fosheim Grøstad
- Laws of Online World Design Koster, Raph
- Laws of Online World Design J C Lawrence
- Laws of Online World Design Ola Fosheim Grøstad
- Laws of Online World Design Ola Fosheim Grøstad
- Laws of Online World Design J C Lawrence
- Laws of Online World Design Darrin Hyrup
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Darrin Hyrup
- Laws of Online World Design J C Lawrence
- Laws of Online World Design Hans-Henrik Staerfeldt
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Richard Bartle
- Laws of Online World Design Richard Bartle
- Laws of Online World Design Vadim Tkachenko
- MUVE vs. MUD [was Current Projects] Richard Bartle
- META: Review of FAQ's Bio Section Ling
- META: Review of FAQ's Bio Section Chris Gray
- META: Review of FAQ's Bio Section Benjamin D. Wiechel
- META: Review of FAQ's Bio Section Ling
- META: Review of FAQ's Bio Section J C Lawrence
- META: Review of FAQ's Bio Section Adam Wiggins
- META: Review of FAQ's Bio Section Michael.Willey@abnamro.com
- Advance book review Koster, Raph
- (CDMag) Sosaria Cracked: Why OSI's great social experiment is doomed J C Lawrence
- Ethics & Identity Scatter
- DNS adventure J C Lawrence
- DNS adventure Chris Gray
- DNS adventure Caliban Tiresias Darklock
- DNS adventure Adam J. Thornton
- DNS adventure Vadim Tkachenko
- DNS adventure J C Lawrence
- Trusting the Client (Laws of Online World Design) mark@erdos.Stanford.EDU
- Trusting the Client (Laws of Online World Design) Ola Fosheim Grøstad
- Trusting the Client (Laws of Online World Design) J C Lawrence
- Trusting the Client (Laws of Online World Design) Hal Black
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World Design) J C Lawrence
- Trusting the Client (Laws of Online World Design) Adam J. Thornton
- Trusting the Client (Laws of Online World Design) Marc Hernandez
- Trusting the Client (Laws of Online World D esign) Wilburn, E.J.
- Trusting the Client (Laws of Online World D esign) Jon Leonard
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World Design) Steve Sparks
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World Design) Steve Sparks
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- A Query Regarding Economies in a Text Environment Brandon A Downey
- A Query Regarding Economies in a Text Environment J C Lawrence
- A Query Regarding Economies in a Text Environme nt Koster, Raph
- Trusting the Client (Laws of Online World Design) Chris Gray
- Trusting the Client (Laws of Online World Design) J C Lawrence
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World D esign) Wilburn, E.J.
- Trusting the Client (Laws of Online World D esign) J C Lawrence
- [Tech] socket slowdown solved Chris Gray
- [Tech] socket slowdown solved J C Lawrence
- ADMIN: unsubscriptions J C Lawrence
- Trusting the Client (Laws of Online World Design) Chris Gray
- Network float format (RFC 1014) J C Lawrence
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Koster, Raph
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Elis Pomales
- Bruce Sterling on Virtual Community goals Darrin Hyrup
- Bruce Sterling on Virtual Community goals Bruce Mitchener, Jr.
- Bruce Sterling on Virtual Community goals Darrin Hyrup
- Bruce Sterling on Virtual Community goals Niklas Elmqvist
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Wilburn, E.J.
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Niklas Elmqvist
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Joel Kelso
- Bruce Sterling on Virtual Community goals Marc Hernandez
- Bruce Sterling on Virtual Community goals Bruce Mitchener, Jr.
- Bruce Sterling on Virtual Community goals Adam J. Thornton
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Marc Hernandez
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals ApplePiMan@aol.com
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Bruce Mitchener, Jr.
- Bruce Sterling on Virtual Community goals Adam J. Thornton
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- OT: TTYQuake Niklas Elmqvist
- OT: TTYQuake Adam Wiggins
- OT: TTYQuake Adam J. Thornton
- Trusting the Client (Laws of Online World Matthew R. Sheahan
- Trusting the Client (Laws of Online World Vadim Tkachenko
- Trusting the Client (Laws of Online World J C Lawrence
- FW: Book? Koster, Raph
- GameStorm Matthew R. Sheahan
- GameStorm J C Lawrence
- Trusting the Client (Laws of Online World Jon A. Lambert
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World D esign) quzah [sotfhome]
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World D esign) J C Lawrence
- Lengthy Palace study Koster, Raph
- Hacks/Diablo/etc (was: Trusting the quzah [sotfhome]
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- PDMud (was Bruce Sterling on Virtual Community goals) Darrin Hyrup
- PDMud (was Bruce Sterling on Virtual Community goals) Adam J. Thornton
- PDMud (was Bruce Sterling on Virtual Community goals) Hal Black
- PDMud (was Bruce Sterling on Virtual Community goals) Ola Fosheim Grøstad
- PDMud (was Bruce Sterling on Virtual Community goals) ApplePiMan@aol.com
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- Recursive look Ling
- Recursive look Holly Sommer
- Recursive look David Bennett
- Recursive look J C Lawrence
- Recursive look Marc Hernandez
- Recursive look Bruce Mitchener, Jr.
- Recursive look Michael.Willey@abnamro.com
- Recursive look The Wildman
- Recursive look Adam Wiggins
- Recursive look Koster, Raph
- Recursive look Ling
- Recursive look Adam Wiggins
- Recursive look Marian Griffith
- Recursive look Brandon J. Rickman
- Recursive look Marian Griffith
- Recursive look Brandon J. Rickman
- Recursive look Marian Griffith
- Recursive look Ola Fosheim Grøstad
- Recursive look Nathan F Yospe
- Recursive look Darrin Hyrup
- Recursive look Ola Fosheim Grøstad
- Recursive look Jon A. Lambert
- Recursive look Matthew R. Sheahan
- Recursive look Nathan F Yospe
- Recursive look Michael.Willey@abnamro.com
- Recursive look Chris Gray
- Recursive look Chris Gray
- evil - good realism Vladimir Prelovac
- evil - good realism S. Patrick Gallaty
- evil - good realism Adam Wiggins
- evil - good realism Wilburn, E.J.
- evil - good realism quzah [sotfhome]
- evil - good realism Jon A. Lambert
- evil - good realism quzah [sotfhome]
- evil - good realism Orion Henry
- evil - good realism Vadim Tkachenko
- evil - good realism J C Lawrence
- evil - good realism Chris Gray
- evil - good realism Brandon A Downey
- evil - good realism quzah [sotfhome]
- evil - good realism Vladimir Prelovac
- evil - good realism Vadim Tkachenko
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Hal Black
- PDMud (was Bruce Sterling on Virtual Community goals) Felix A. Croes
- PDMud (was Bruce Sterling on Virtual Community goals) Darrin Hyrup
- PDMud thread summary Jon Leonard
- PDMud thread summary Chris Gray
- PDMud thread summary Darrin Hyrup
- PDMud thread summary J C Lawrence
- PDMud thread summary Hal Black
- PDMud thread summary Vadim Tkachenko
- PDMud thread summary Darrin Hyrup
- PDMud thread summary J C Lawrence
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Darrin Hyrup
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Jon A. Lambert
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary J C Lawrence
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Jo Dillon
- PDMud thread summary The Arrow
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Chris Gray
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Darrin Hyrup
- PDMud thread summary Chris Gray
- PDMud thread summary Jon Leonard
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Steve Sparks
- PDMud thread summary Jo Dillon
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Jon Leonard
- PDMud thread summary Jo Dillon
- PDMud thread summary Jon Leonard
- PDMud thread summary Vadim Tkachenko
- PDMud thread summary Jo Dillon
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Vadim Tkachenko
- PDMud thread summary Darrin Hyrup
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Chris Gray
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Chris Gray
- PDMud thread summary Chris Gray
- PDMud thread summary James Wilson
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary James Wilson
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Chris Gray
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary James Wilson
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Chris Gray
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Chris Gray
- PDMud thread summary Chris Gray
- PDMud thread summary Alex Oren
- PDMud thread summary Alex Oren
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Bruce Mitchener, Jr.
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Holly Sommer
- PDMud thread summary Jo Dillon
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Jo Dillon
- PDMud thread summary Adam Wiggins
- PDMud thread summary Jo Dillon
- PDMud thread summary Chris Gray
- PDMud thread summary Chris Gray
- PDMud thread summary Alex Oren
- PDMud thread summary Chris Gray
- PDMud thread summary Alex Oren
- ADMIN: Unsubscriptions J C Lawrence
- DevMUD Event Language Hal Black
- DevMUD Event Language Jon Leonard
- DevMUD Event Language J C Lawrence
- DevMUD Event Language James Wilson
- DevMUD Event Language J C Lawrence
- DevMUD Event Language Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) J C Lawrence
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- PDMud (was Bruce Sterling on Virtual Community goals) James Wilson
- PDMud (was Bruce Sterling on Virtual Community goals) Jon Leonard
- PDMud (was Bruce Sterling on Virtual Community goals) ApplePiMan@aol.com
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- Crack.Com deceased, Golgotha source released (sorta) J C Lawrence
- Crack.Com deceased, Golgotha source released (sorta) Bruce Mitchener, Jr.
- Crack.Com deceased, Golgotha source released (sorta ) Koster, Raph
- Crack.Com deceased, Golgotha source released (sorta ) Marc Hernandez
- Crack.Com deceased, Golgotha source released (sorta) Adam J. Thornton
- Crack.Com deceased, Golgotha source released (sorta) Adam Wiggins
- Crack.Com deceased, Golgotha source released (sorta) J C Lawrence
- Crack.Com deceased, Golgotha source released (sorta) J C Lawrence
- Crack.Com deceased, Golgotha source released (sorta) Bruce Mitchener, Jr.
- Game Developers Conference Koster, Raph
- Crack.Com deceased Marc Hernandez
- OT, kinda, but yay :) Koster, Raph
- OT, kinda, but yay :) Jon Leonard
- OT, kinda, but yay :) Nathan F Yospe
- OT, kinda, but yay :) Jon Leonard
- OT, kinda, but yay :) Koster, Raph
- OT, kinda, but yay :) Steve Sparks
- OT, kinda, but yay :) Adam Wiggins
- OT, kinda, but yay :) Chris Gray
- OT, kinda, but yay :) Jo Dillon
- OT, kinda, but yay :) Adam Wiggins
- OT, kinda, but yay :) Jo Dillon
- OT, kinda, but yay :) Jo Dillon
- PDMud (was Bruce Sterling on Virtual Community goals) Petri Virkkula
- Crack.Com deceased, Golgotha source released , (sorta) Holly Sommer
- OT: slashdot Adam Wiggins
- OT: slashdot J C Lawrence
- OT: slashdot J C Lawrence
- Language support Koster, Raph
- PDMud, Gamora and Casbah Bruce Mitchener, Jr.
- PDMud, Gamora and Casbah Caliban Tiresias Darklock
- PDMud, Gamora and Casbah Niklas Elmqvist
- PDMud, Gamora and Casbah Jon Leonard
- PDMud, Gamora and Casbah Darrin Hyrup
- PDMud, Gamora and Casbah Niklas Elmqvist
- PDMud, Gamora and Casbah Adam J. Thornton
- PDMud, Gamora and Casbah ApplePiMan@aol.com
- PDMud, Gamora and Casbah Chris Gray
- PDMud, Gamora and Casbah Darrin Hyrup
- PDMud, Gamora and Casbah Niklas Elmqvist
- UO: Second Age Koster, Raph
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Bruce Mitchener, Jr.
- Golgotha as it applies to PDMud (was Crack.Com deceased, Golgotha source , released (sorta)) Niklas Elmqvist
- OpenMUD: bus-based communications James Wilson
- OpenMUD: bus-based communications Chris Gray
- OpenMUD: bus-based communications Niklas Elmqvist
- OpenMUD: bus-based communications Niklas Elmqvist
- OpenMUD: bus-based communications ApplePiMan@aol.com
- I wanna do it OO James Wilson
- I wanna do it OO Chris Gray
- DevMUD - thoughts.1 Chris Gray
- DevMUD - thoughts.1 James Wilson
- DevMUD - thoughts.1 Chris Gray
- DevMUD - thoughts.1 Chris Gray
- DevMUD - thoughts.1 James Wilson
- DevMUD - thoughts.1 Niklas Elmqvist
- DevMUD - thoughts.1 Chris Gray
- CVS and LXR bruce@portland.puremagic.com
- openmud or pdmud or devmud James Wilson
- openmud or pdmud or devmud Chris Gray
- openmud or pdmud or devmud Darrin Hyrup
- openmud or pdmud or devmud Hal Black
- openmud or pdmud or devmud Jon Leonard
- openmud or pdmud or devmud Adam J. Thornton
- openmud or pdmud or devmud Bruce Mitchener, Jr.
- openmud or pdmud or devmud Adam J. Thornton
- openmud: open issues James Wilson
- openmud: open issues Vadim Tkachenko
- openmud: open issues James Wilson
- openmud: open issues Vadim Tkachenko
- MUD verb handling (Was: DevMUD - thoughts.1) Chris Gray
- MUD verb handling (Was: DevMUD - thoughts.1) Adam J. Thornton
- MUD verb handling (Was: DevMUD - thoughts.1) The Arrow
- MUD verb handling (Was: DevMUD - thoughts.1) Jon Leonard
- MUD verb handling (Was: DevMUD - thoughts.1) Niklas Elmqvist
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Jon A. Lambert
- Missing the point: OpenMUD, Gamora, Casbah, etc. Niklas Elmqvist
- Missing the point: OpenMUD, Gamora, Casbah, etc. Darrin Hyrup
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Ola Fosheim Grøstad
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Ola Fosheim Grøstad
- Missing the point: OpenMUD, Gamora, Casbah, etc. Chris Gray
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Ola Fosheim Grøstad
- Missing the point: OpenMUD, Gamora, Casbah, etc. Chris Gray
- DevMUD module configuration Jon Leonard
- DevMUD module configuration James Wilson
- DevMUD module configuration Bruce Mitchener, Jr.
- DevMUD module configuration J C Lawrence
- DevMUD module configuration Chris Gray
- DevMUD module configuration Niklas Elmqvist
- DevMUD module configuration Vadim Tkachenko
- Inheritance model (was PDMud thread summary) Bruce Mitchener, Jr.
- Inheritance model (was PDMud thread summary) Cynbe ru Taren
- Why did it take years? Cynbe ru Taren
- Why did it take years? Adam Wiggins
- Why did it take years? James Wilson
- Why did it take years? Bruce Mitchener, Jr.
- Why did it take years? Niklas Elmqvist
- Why did it take years? Holly Sommer
- Why did it take years? J C Lawrence
- Why did it take years? Jo Dillon
- Why did it take years? Cynbe ru Taren
- Why did it take years? J C Lawrence
- Why did it take years? Adam Wiggins
- Why did it take years? Chris Gray
- Why did it take years? Erik Ostrom
- Gamora: Lessons learned? (fwd) Niklas Elmqvist
- Gamora: Lessons learned? (fwd) Niklas Elmqvist
- resource management (was: Missing the point) Felix A. Croes
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Bruce Mitchener, Jr.
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Niklas Elmqvist
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules Niklas Elmqvist
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules Robert Brady
- DevMUD: Inheritable modules J C Lawrence
- DevMUD: Inheritable modules Darrin Hyrup
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Adam J. Thornton
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules Cynbe ru Taren
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules Vadim Tkachenko
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Adam J. Thornton
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Thandor
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Thandor
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules J C Lawrence
- [DevMUD] driver implementation language Hal Black
- META/ADMIN: CVS for DevMUD security J C Lawrence
- META/ADMIN: CVS for DevMUD security Jon Leonard
- META/ADMIN: CVS for DevMUD security James Wilson
- DevMUD Objectives? Thandor
- DevMUD Objectives? Koster, Raph
- DevMUD Objectives? Ola Fosheim Grøstad
- DevMUD Objectives? Petri Virkkula
- DevMUD Objectives? Thandor
- DevMUD Objectives? Niklas Elmqvist
- DevMUD Objectives? Thandor
- DevMUD Objectives? Darrin Hyrup
At 01:45 AM 10/31/98 +1100, Thandor wrote:
>On Fri, Oct 30, 1998 at 01:54:38PM +0100, Niklas Elmqvist wrote:
>> I can easily envision popping in a couple of Diku-style modules (command
>> and DB handlers should suffice) into a DevMUD platform (which already uses
>> a generic TCP socket module, a parser and a few other things) and voila!
>> Instant Diku!
>
>I don't want an instant diku ... if I wanted one I'd run a diku. ;)
But I think the point he was making is, you COULD if you wanted to. And
any other Diku admin's could probably do the same thing and move their
codebase over without having to start over. Thus getting all the benefits
of the new server design, with the familiarity of the Diku operation.
>I'm just of the opinion that a simple system isn't necessarily a bad one. A
>system that does a limited number of things well is a whole lot more useful
>than a system that does everything only so-so, is it not?
The 'overall basis' for this project is that it would be made up of several
simple generic code modules, and put together in a way that gives the mud
admin and programmer as much flexibility as possible. Aside from the
kernel itself, almost all useful functionality will be module-based, and
abstracted enough that just about anyone could recode a module (or create a
new one) if they desired to do so. Another goal of this project was
education... to raise the 'state of the art' in mud development a bit. We
plan to document the progress of this design and implementation so people
who are paying attention should be able to follow along and pick up some
new skills along the way. And new mud admins/programmers will have a solid
base to begin hacking on.
>Maybe I'm the only one who doesn't like the idea of components I don't
>understand running the show - I'd kind of like to think that if there's
>something missing from the system that needs to go at a low level I'd be able
>to do something about it. I'd hate my mud to be at the mercy of the server
>"vendors", even if the vendors are reasonable people from the mud-dev mailing
>list. ;) When it comes down to it, I'd rather write something of my own from
>scratch than use something someone else has writen but I don't understand, at
>least if it's for something like a mud. After all, I think opening a mud to
>the public is a serious step and not something to do if you don't understand
>what you're doing.
There is no reason you should have to be in the dark about the compenents
of the game environment. Each should be simple, streamlined, designed for
a specific goal, and should have a source module that you could edit and
recompile yourself if you need to change something. Of course, the kernel
itself (which should be very tiny, not much more than a signal/event
handler, message handler, module manager, and thread manager) should
probably not need to be tweaked itself once the core is solid, but there
would be nothing keeping you from doing so if you really wanted to.
>I guess I'll just never have faith in someone else's work if I'm going to be
>the one that's going to look bad if things go wrong. If I have a hope of
being
>able to fix the problems, then that changes my mindset quite considerably. ;)
The point is not to keep people from getting involved in the mud, but to
make the interface such that anyone could add any kind of functionality in
a generic manner, which you could then put up on a library site somewhere
so others could benefit from your work. So, if you made a "D&D combat"
module, you could put that up for others to enjoy... if they wanted to. If
you don't want to use a module, you are not forced to do so. If you don't
like how it works, you can change it.
>> MUD codebases. That does not mean it must be more *difficult*. In fact,
>> "normal" people tend to think in terms of black boxes doing stuff and
>> sending it on to other black boxes (at least before they become
>
>Of course there has to be some degree of abstraction. But I'd like to be able
>to have enough understanding of the black boxes to be able to change the way
>they work should I need to. I doubt anything anyone can say will ever
convince
>me I'll never under any circumstances want or need to change the way any part
>of the system works.
The abstraction layer is more along the lines of keeping the low-level and
high-level code seperated by a logical barrier. That way,
newbies/non-programmers can come in and change things, using a simple set
of tools (perhaps the internal mud language) and not have to be aware of
the low-level details. However, skilled programmers could then go in and
modify the modules themselves, at as low of level as they feel is
appropriate. The kernel itself would be abstracting most of the really
low-level calls anyway, so the modules could rely on a set of
OS-independant abstracted interfaces to do their job.
>> Well, with a module-based system, you would *never* (at least not in a
>> perfect world) have to reboot your server even if you add changes. All the
>> functionality of the MUD is contained in the modules which are dynamically
>> loaded at run-time, so adding new stuff is as easy as recompiling the
>> module, unload the old one and load the new one into the executable.
>
>I realise that much. What I'm saying is that the fact it lets me avoid 30
>seconds downtime every few days isn't a compelling reason to bother with such
>a system. But if there's another reason to go for such a system, then hell
>yeah, I'll take this benefit.
In the commercial arena, you don't ever want a downtime... even a 30 second
one. That pushes people away... and after the reset, you can usually
expect at least 25% of those people will have found something else to do in
that 30 seconds of waiting time... thus losing some revenue. Of course,
this matters more in a pay-by-time system rather than a pay-by-month
system, but if you bave to reset your system a lot to make changes, it will
affect your playerbase since people don't like to wait for (or be
inconvenienced by) something they are paying for.
>> The *real* potential of MUD languages is that they add a whole new
>> dimension to the world. I take it you have not played much in a system
>> with a MUD-language? I am not trying to start a codebase war here, but
>> let's face it; a vanilla Diku server, even one with mobprogs installed,
>> has a pretty stale world. Sure, mobs move around and repop, doors can be
>> opened and closed, you can search for hidden entrances and stuff, but
>> that's about it. Having guards attack fighting players in the city forces
>> the implementors (at least people with source access!) to write special
>> functions to handle this in a language (C) not designed for the problem
>> domain.
>
>I'll admit my bias is towards what I know and love - diku. From what I've
read
>on this list, it's kind of like a dirty word, but for whatever reason I like
>it. *shrug* But I'm not a fool, I can see the at times huge flaws it has, and
>want something better.
Well, thats a good attitude to start with. ;)
>I don't find interactions with the environment in any mud to be particuarly
>interesting, after a certain point. Lets face it - the AI you can implement
>given the constraints of the mud environment and the hardware it runs on is
>pretty limited. In many ways, I find the more that you try to cover that fact
>up, the more you notice how poor the interaction is. Hence making mobs
>"smarter" has never been something I've aspired to do.
The beauty of the system we are proposing in DevMUD is that the admin can
decide just how extensible they wish it to be. If they don't want online
coding, they don't allow that. If they want a programmer to modify
something in the game, the programmer only needs to worry about one module,
or writing some internal language code.
The other major advantage of an internal programming language is that when
changes are made, bugs won't crash the server. The VM can catch exceptions
and pass them back to the coder with some debug information, and not affect
the rest of the players. To me, this is one of the biggest advantages,
since even with the plug-in modules, if there is a bug, they can easily
cause the server to go down in flames.
>> With a good MUD-language, a *lot* of life can be breathed into a stale
>> world. I am sure that a lot of the LP folks out there have some tremendous
>> examples of this, but I'll just go on to tell you that MUD-language
>> programmed quests can so be much more than the "find the mobile" or "kill
>> that guy" quests so common on hardcoded MUDs. How about having to track
>> down a criminal in a large city by asking people, bribing guards,
>> following leads and so on? How about redesigning the laws of physics in
>> the whole world or in a specific area? And what about the issue of
>> implementing the Mage2Mage spell design language so that you can attach
>> small snippets of code to objects (activating the fire-essence of this
>> brimstone might allow me to channel more fire magic, for example)? All
>> this is possible, and much more.
>
>Yes, but you can do that with diku if you want to hack the code hard
enough. I
>guess it comes down to what I touch on later - will the mud language make my
>life easier? That's what *I* want from a mud language - I'd be interested to
>hear what other people are looking for.
Well, from personal experience I can say that a mud with online coding
capability is much more flexible (and thus has the potential for being much
more interesting) than a hardcode mud. Now, I can say this because my
primary server is hardcode (and has been running for a decade now)... it
runs great and does what its meant to do, but I don't think it is perfect
by any means. I've also worked on servers with an in-game language, and if
set up right, they can do things I wouldn't imagine trying to do in
hardcode. Not to mention, online coding can relieve some of the
programmer's burden, since one (or rarely more) programmer is generally not
as productive as a team of online scripters with a mission, and together
they are a lot more productive. It allows you to do things like have the
main mud programmer work on low-level aspects of the game core, while the
game staff (GMs, etc.) develop the world and write the mob AI, code quests,
create custom coded magic items, et al. Both 'teams' working independently
and efficiently. In a hardcoded mud, anything not available to the objects
in the game by way of flags or other settings requires the coder to get in
there and start changing things, which means more potential bugs and at
least some downtime. Some hardcode muds have triggers and event scripts
and such, but those are another kind of online programming, just a basic form.
>In a very well maintained system, then I think yes it could save work. But
>only having hard code at least puts everything in one place, and
maintained by
>a relatively small number of people. I think that helps to reduce needless
>duplication of code. I could be wrong, I'm just speculating again...
It also means that the whole game (players and staff) has to wait for the
programmer to do code anything special that needs to be added to the game.
If the programmer is sick, or busy with work, or otherwise cannot devote
their time to the mud, the rest of the game suffers or has to 'make due'
without the change. The alternative allows the game staff (and/or players)
to extend the game system themselves, and eliminate the 'single point of
failure' problem predominant in group environments when a team has stop
everything while they wait for one person to do something.
>> Well, the virtual machine of the MUD-language will not be built into the
>> DevMUD platform. They will be provided in modules, and you could probably
>> add as many VMs as you like to the game. So if you want a language for a
>> text-based MUD, you go to the module central and download a VM for this
>> (if you can't find one, then you can probably write one on your own).
>> Actually, there is nothing to stop us from using the same general-purpose
>> VM module and then just implement different compilers to support a wide
>> range of languages. The VM would be the back-end and the compilers the
>> front-end (a lot could probably be shared among these compilers as well),
>> so you use different language syntaxes but they are all compiled to the
>> same bytecode.
>
>I think we have a difference of semantics here. I'm refering to DevMUD as
>pretty much the main module set - bootstrap, config, parser, network, virtual
>machine. And others I've no doubt neglected to mention. I think you're
talking
>about the DevMUD "core" so to speak. I assume that the plan is to release
>DevMUD with some sort of game language, as it would defeat the purpose to
just
>release a DevMUD core and make everyone write everything else from scratch.
Thats pretty much it. The core/kernel of the system will be very tight,
streamlined, and simple. Its whole duty will be just servicing the modules
in the environment. Without the modules, the kernel will not be very
useful. All the tangible functionality will be built into the modules
themselves, and the choice of which modules are used and how they are
combined will determine the appearance of the mud itself. There will be
some modules that are probably used by everyone... network i/o for example,
but the choice of parser (if any), database (if any), internal language
compiler (if any), and other interface or environment modules (if any) will
be completely up to the person setting up the mud, and can be changed
without notice at any time.
>So the game language/virtual machine is a major part of the system, even
if it
>can be replaced by another, different but equivalent, part.
In my opinion, the VM should be part of the core system, but it doesn't
have to be, if you don't have any use for it. Like if you want to use the
'diku mud plug-in' you wouldn't really have to have a VM to service it,
although it could be useful.
>> For that matter, if you have a dislike for MUD-languages, there is nothing
>> to force you to add the VM module to your server. The language is just
>> another module in the MUD operating system.
>
>I don't dislike them. I want a mud language. I just want one that's going to
>be worth the effort to learn - preferably one that doesn't force me to write
>my own compiler to achieve that.
Ideally, I'd like to see a mud-language which is designed to act sort of
like stage directions for the actors in the mud... with some problem
solving capabilities too, of course. It should be simple to understand,
written in a human interpretable language, and tailored specifically for
doing things in the mud. This way I could give this to my game staff and
have them handle the monster AI, quests, and some parts of the mechanics
without really having to be programmers.
I expect we'll probably end up with several mud-languages, each with their
own goals and styles, yet all sharing the same virtual machine. So, we
could have the 'actor language' above along with an 'implementor language'
for hardcore programmers to use to do more sophisticated programming with,
and perhaps add a simple 'player language' for their own things, etc. All
on the same mud server, and completely invisible to the players.
>> Okay, you will probably receive some kind of response here from certain
>> people that we want "an application server not a mud server!" ;)
>
>Then you've no longer got a mud OS at all ... and you may as well base your
>kernel on the linux kernel or something. ;)
We've been looking into that idea. Using a real OS microkernel as a basis
for the server core. I've looked at several myself, for example. Muq uses
the same concept, although I think their microkernel is custom, not based
on an existing microkernel.
>> I will not argue with you here, as I also want to target MUDs. However, I
>> believe we can widen the perspective a little and say "internet game
>> servers". And we are not saying that you could take just any module and
>> pop it into a DevMUD system. We are saying that you could take just any
>> DevMUD module and pop it into a DevMUD (maybe this is what you meant?).
>> If the new module is ignored by the rest of the modules in the system,
>> that's fine. But we want to be able to write generic network I/O modules,
>> storage systems, parsers and event managers so that they don't have to be
>> written *again*. Sure, we all like to tweak these things, but would it not
>> be nicer if they were available for download and would work through the
>> principle of plug-and-play, allowing you as a MUD developer to pour your
>> creativity into areas which would make your MUD different?
>
>Plug and play mud? Hmm, the natural evolution of "a stock mud with snippets",
>is it not? Internet game server is a pretty large scope. That ranges pretty
>much from a quake server to net-tamagotchi. Neither of which really come
close
>to being muds. Personally, I don't think being a little more specialised than
>that is going to hurt.
Why worry about it? If we leave the details of the game up to what modules
are connected to it, what is there keeping us from running a quake like
game next to a net-tamagotchi, next to a generic text frp, next to a full
blown 3d virtual immersion game? Nothing but the imagination of the people
putting the server together, and how much custom code they want to write. :)
>What I was referring to with the taking modules was that I recall someone
>saying something about people being able to take the DevMUD telnet module
(for
>example) and write some non-mud related program around it. I'm saying that
>while if that works out to be possible, then that's all well and good, but I
>don't think it should even come close to being a design goal.
The modules themselves should be independent but the server kernel supplies
an API layer that allows them to communicate if needed. That way, anyone
could write any kind of module they like and use that to communicate with
the rest of the modules in there. If they want to make a non-mud based
game, thats up to them. We're primarily aiming at the MUD world, but that
doesn't mean we should exclude anyone else. We're just providing the
workbench and the tools, and its up to others to use them, or make new
tools if they don't see one they need.
>And who's saying that stuff like storage systems can't make my mud different?
>If my mud's storage system consisted of /dev/null it'd be pretty
different. :)
>Seriously though, I can imagine tweaking the parser module and storage system
>module as part of the customisation process. Network I/O and event manager
are
>harder to imagine, but still a possibility. Maybe I'm not thinking generic
>enough?
You should be able to customize any module you like, however you want to do
so. But in most cases, most things I would expect people to change would
be more suited for their own modules than changes to the low-level modules
or server core itself.
>> Of course, there is nothing to stop a module implementor for targeting his
>> module for a specific type of game servers. However, I believe it is
>> important that there is a possibility to write very general-purpose
>> modules.
>
>Thinking about it again, it's probably a requirement to try to be as generic
>as possible with the low level stuff. After all, I'm guessing that stuff is
>going to get writen that is dependent on the idiosynchrisies of other
modules,
>effectively forcing you to use X if you want to use Y. The only thing worse
>than being forced to use X is being forced to use X and X doesn't do what you
>need.
Yes, the system is supposed to be generic as possible, but the way the
module system is invisioned, modules should be self-contained (as much as
possible) and if they do require another module for support, then that
module serves a purpose that you do need, otherwise you wouldn't need the
original module. We don't want to see server bloat based on over-use of
module inheritance / module dependancies. At least, none of the code
modules should suffer from this, but there is no way to keep other
developers from making poor choices.
>> AFAIK, there has been no general discussion of supporting *both* text and
>> graphics in one game. However, the mud development operating system (ie
>> DevMUD :) should certainly *not* restrict developers to what kind of a
>> game they want to make.
>
>Maybe I was misinterpretting that then. My mistake. Though I think no matter
>what you do, you're going to restrict developers somewhat. It's chosing how
>much restriction is reasonable that's the challenge.
Most things in life require decisions... any time a decision is made, you
are imposing a restriction of some kind. Ideally, the restriction is a
beneficial one, but not always. The goal is to try to make the decisions
that offer the best tradeoff of restriction vs benefit. Software
development is no different.
>> Well, that's the cost of being on the bleeding edge! I know *I* don't
>> understand half of the discussions on this issue. However, I think we can
>> agree that most of the discussions have been in relation to the DevMUD
>> driver which should be (everybody) *lean* and *mean*. That means using all
>> the talent of people on this list and taking advantage of their expertise
>> in different areas. So far, I've just been able to bring up designs which
>> have been scythed down, so I am not sure how much help I've been... (No,
>> I'm not bitter... Not much, anyway :)
>
>hehehe. Well, I'm glad you say half the stuff is over your head, I don't feel
>quite so stupid now. ;)
I don't think any of us really understand all the concepts that have been
thrown around in here. I always learn new things based on what I read
here, links people post, etc. Thats why part of the goal is to document
the project as an educational experience, such that anyone who wishes to
can learn how every aspect of the game works, and why. And by going
through the archives, they can find out the history of how things ended up
they way they did.
>Maybe it's a good thing. I'm a worrier though. What if someone goes ahead and
>implements their brilliant design, that only they understand. What happens
>when they lose interest in DevMUD? Who want's to try to decipher what the
heck
>they did to fix any bugs there? You go too far out on the bleeding edge and
>you cut yourself, you know.
Thats why we're working together... it isn't a single person's design or
concept. Its a group project with many contributors. If someone bows out,
their work will remain credited, but the team will make up for the loss by
spreading the load or someone else will step up to replace them.
Hopefully, we can maintain the group cohesiveness long enough to get a
basic server toolkit together, a running test server with a simple world,
and then people can break off to work on their own extensions.
Changes will be documented, so there should be no need to try and decipher
what one person does. Of course, any 3rd party modules may not follow this
design goal, but we can't worry about them.
<whew!> long post.
>- Shane King/Thandor.
Best,
Darrin - DevMUD Objectives? Travis Casey
- DevMUD Objectives? Darrin Hyrup
- DevMUD Objectives? Chris Gray
- DevMUD Objectives? Chris Gray
- DevMUD Objectives? Hal Black
- DevMUD Objectives? Thandor
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Chris Gray
- Why modules? (Was: Inheritable modules) Chris Gray
- Why modules? (Was: Inheritable modules) Thandor
- Why modules? (Was: Inheritable modules) James Wilson
- Why modules? (Was: Inheritable modules) Adam J. Thornton
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Thandor
- Why modules? (Was: Inheritable modules) James Wilson
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Thandor
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) J C Lawrence
- MUD-Dev's DevMUD: a word of caution Greg Munt
- MUD-Dev's DevMUD: a word of caution Cynbe ru Taren
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Chris Gray
- MUD-Dev's DevMUD: a word of caution ApplePiMan@aol.com
- MUD-Dev's DevMUD: a word of caution Jon A. Lambert
- MUD-Dev's DevMUD: a word of caution Chris Gray
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Cynbe ru Taren
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Adam J. Thornton
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution James Wilson
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Niklas Elmqvist
- MUD-Dev's DevMUD: a word of caution The Arrow
- MUD-Dev's DevMUD: a word of caution Thandor
- DevMUD: Module message passing The Arrow
- DevMUD: Module message passing Vadim Tkachenko
- Why mudules and some other questions. Ben Greear
- Why mudules and some other questions. Vadim Tkachenko
- Reminiscing Jon A. Lambert