November 1998

• ADMIN: Unsubscriptions J C Lawrence
• ScryMUD [CUSTOM] Code release. Ben Greear
• Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
• • Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
  • • Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
• DevMUD: CVS Tree is ready. Are your sources? J C Lawrence
• DevMUD considerations and the Halloween article J C Lawrence
• • DevMUD considerations and the Halloween article Jon Leonard
  • • DevMUD considerations and the Halloween article Adam J. Thornton
    • DevMUD considerations and the Halloween article J C Lawrence
  • DevMUD considerations and the Halloween article Chris Gray
  • • DevMUD considerations and the Halloween article Jon Leonard
    • • DevMUD considerations and the Halloween article David Bennett
      • DevMUD considerations and the Halloween article Alex Oren
  • DevMUD considerations and the Halloween article Chris Gray
  • • DevMUD considerations and the Halloween article Marc Hernandez
  • DevMUD considerations and the Halloween article Chris Gray
  • • DevMUD considerations and the Halloween article Vadim Tkachenko
    • DevMUD considerations and the Halloween article Jon Leonard
  • DevMUD considerations and the Halloween article Alex Oren
  • • DevMUD considerations and the Halloween article Alex Oren
    • • DevMUD considerations and the Halloween article Ola Fosheim Grøstad
  • DevMUD considerations and the Halloween article Chris Gray
• Designgoals for CoolComponentCore (Was MUD-Dev's...) Chris Gray
• Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Hal Black
• • Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
    Hal Black wrote:
    > On Sun, Nov 01, 1998 at 01:54:13PM +0100, Ola Fosheim Grøstad wrote:
    > > On the technical decisions "made":
    > >
    > > - DevMUD will have dynamic loadable modules because it is cool (and because
    > > it is used in mainframes, it looks like Java, it is used in Windows as a
    > > replacement for a sucking memory model, because it is used for OS device
    > > drivers, plug'n'play and that makes it a good idea)
    >
    > A nice straw man, but you neglected to mention any of the reasons that people
    > have posted that they want dynamically loaded modules. Please allow me to
    > reiterate.
    
    I didn't list the negative sides either. I basically tried to see the
    underlying reasons for decisions being "made" ad-hoc. (but yeah there was a
    nasty twist to it)
    
    > 1. Dynamically loading a module is one way to avoid a huge cache miss (both
    > writing and reading) for all the state in all other modules which would be
    > caused by shutting down and restarting the whole mud (unless you have some hack
    > to make your data stay there while you reload). This could cost a substantial
    > amount of time depending on the mud (not all muds have a small memory footprint
    > and loading time) and the frequency at which it is used (some coders will
    > reload modules in their test server more than once a month - maybe 20 times an
    > hour if they were changing a lot of different modules). Maybe none of this is
    > worth dynamic loading to YOU. That doesn't mean that it isn't valuable to ME.
    > Or that it is a viewpoint worth scorn as a "cool feature".
    
    There are lots of other problems. For instance, what are you going to do if
    invariants change. Meaning: you have to either limit yourself or write two
    versions in the update. Meaning: yet more room for human error and
    nondeterminism. This won't be a likely problem if you go for something a
    human gamemaster could calculate, but if you go for a more complex
    system... I think one should list the extra problem one buys oneself. If
    for no other reason, they have to be adressed at some point. I usually try
    to minimize the situations I have to consider and put that load on the
    development system. (I don't really jump at massive multithreading for the
    same reason)
    
    > 2. If a suitably large toolkit of modules existed, people less of the computer
    > geeky and more of the creative variety would be able to download modules and
    > put them together without a compiler (linker).
    
    I agree, but then the focus is not really to make a commercial foundation.
    Which I assumed it was. And it assumes (even binary) interoperability which
    is hard to do. Example if your fighting module assumes hitpoints and my
    avatar has health and energy instead, then you need some kind of adapter.
    This is the type of issues one has to address when discussing resuable
    modules... If you try to analyze existing muds within the plugin framework
    then I am sure you can identify a number of such issues which one would be
    better off knowing about before the designed foundation is frozen.
    
    > Now, dynamic loading might not be the only way to do these things, but it seems
    > to me to be a straightforward way, and that is at least worth consideration.
    
    I think Chris Gray pretty much said it. To rephrase in my own words:
    volunteers needs a carrot and whether it is rational or not is perhaps not
    the issue... I've realized that if you remove dynamic modules then there
    will probably not be a DevCore, but that doesn't mean that one shouldn't
    specify the problems involved...
    
    > > - DevMUD will have a Virtual Machinelanguage because it is cool (everybody
    > > does it)
    >
    > If there's going to be some in-game programming language (which a lot of
    > people seem to think would be a good thing to have), there is going to be
    > something like a virtual machine, even if it's a simple interpreter.
    
    Or a statemachine/graph (abstract syntax three). Another problem is with
    making the virtual machine the portable mechanism (as opposed to selecting
    an existing language syntax), you have to do it right the first time. VM
    efficiency is clearly dependant on language-semantics and hardware... The
    main VM advantage is exchanging objectcode between different hardware
    platforms, not a major issue to my projects. ( I don't know enough about
    this, but I assume that a graph is less platform sensitive in terms of
    efficiency (all objects and references))
    
    > > - DevMUD will use the eventmodel because it is cool (scalability is
    > > paramount)
    >
    > I'd like to use an event-based execution model, because it maps well to MUD
    > execution (as opposed to that of, say linear algebra or bovine cracking)
    
    I didn't say it was a bad idea? But the extra cost has not been discussed.
    If one wants to use reusable (third party) modules then it probably is a
    good idea (because you avoid some of the technical interfacing issues)
    
    > > - DevMUD will use 16 bit chars because it is cool (it is an international
    > > effort as well)
    >
    > I guess I can't disagree with that assesment. Some people think it is cool
    > to have slashes and dots through and around their vowels.
    
    You can do'em with 8bits too. Actually I think UNICODE is a good idea, but
    the extra problems has not been discussed. One problem is bandwidth and
    storage (could be solved by increasing complexity), another problem is
    look-up-tables, yet another problem is reuse of libraries (regexp and lex
    for instance).
    
    > > Maybe you should consider renaming the project CoolComponentCore? (or
    > > GeekCore?) Ah well, I think I'll stick to PhotonCore (fast'n'light ;-)
    >
    > Hmm, name calling, and a slightly veiled ad hominem.
    
    Actually, I think one should be honest about ones motives. Cool and Geek
    seems to play a rather important role in general on mud-dev, and I have no
    problems with cool features and geek culture in their own right. If that is
    to be the context, then so be it. Just make sure you say so...
    
    > Additionally, we have an underlying contradiction here. On one hand, you argue
    > that one can't design the core without first having a plan for what the mud
    > should do, and on the other, you say that static is better than dynamic.
    
    I've basically argued for commercial/efficient as the bottomline, and in
    this context I haven't yet found the advantages of dynamic that could
    outweigh what I see as disadvantages. Basically because I can do everything
    that can be done with dynamic, with static, as seen from the players point
    of view. Then again, I haven't said that you shouldn't go for dynamic.
    Just that you won't get it for free and that you need something better than
    cool features to guide design.
    
    > > I am honestly not sure if the generic approach is worth it. Perhaps a good
    > > shiny surface which slight modifications on would look good and have a real
    > > impact on the world is better for the muddingcommunity... *shrug*
    >
    > What generic issues would you remove? Bind it to text-only clients?
    > Room-based only? No virtual machine? (not rhetorical, I'd really like to
    > know)
    
    I can't answer that as I am not the one to drive the DevCore project. I
    think the actual vision and goals is something those _involved_ with the
    project should work with. Not only to guide design, but also to make it
    more likely that cooperation will work out. (I don't agree with those that
    say that talking is bad, depends on what you are talking about. One really
    need someone to collect statments, ideas and write readable summaries
    though.)
    
    You might want to try IPA for the most important aspects, a rather verbose
    notation technique in which you record the design rationale (state issues,
    positions and arguments). I believe it roughly follows this pattern:
    
    Issue 1: main mechanism for supporting collaboration/reuse
    *Position 1: using dynamic loadable modules (*=selected position)
    +argument 1:
    +argument 2:
    -argument 3:
    Issue 1.1: interfacing
    etc...
    Position 2: templates and libraries
    
    (I wouldn't use it for minor issues though)
    
    [... a vision ...]
    
    > Hopefully
    > I have made this specific enough so that Ola won't say I am asking for
    > "everything" (I was careful not to mention world peace in the vision
    > statement).
    
    Bravo, jolly good start. (I'd like to see more on the context it is going to
    operate in, but...) Now, if just someone would volunteer to go through the
    threads and collect statements and wishes and proposals and integrate these,
    point at conflicts etc... That's the "trying" part.
    --
    Ola
  • • Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Jon Leonard
    • • Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
• Flamebite of the day Vadim Tkachenko
• META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
• • META: DevMUD, MUD-Dev, and (list) futures Jon Leonard
  • • META: DevMUD, MUD-Dev, and (list) futures James Wilson
    • META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
  • META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
• DevMud RFC #1 - Was DevMUD considerations and the Halloween article James Wilson
• My vision for DevMUD Jon Leonard
• • My vision for DevMUD Niklas Elmqvist
  • • My vision for DevMUD Jon Leonard
  • My vision for DevMUD Thandor
  • • My vision for DevMUD Robert Woods
    • • My vision for DevMUD ApplePiMan@aol.com
      • My vision for DevMUD Thandor
    • My vision for DevMUD Jon Leonard
    • My vision for DevMUD Adam J. Thornton
    • • My vision for DevMUD Jon Leonard
      • • My vision for DevMUD Adam J. Thornton
        • My vision for DevMUD Caliban Tiresias Darklock
        • • My vision for DevMUD ApplePiMan@aol.com
          • • My vision for DevMUD James Wilson
            • • My vision for DevMUD ApplePiMan@aol.com
              • • My vision for DevMUD James Wilson
                • • My vision for DevMUD Jon A. Lambert
                  • My vision for DevMUD Darrin Hyrup
                  • • My vision for DevMUD Jon Leonard
                    • • My vision for DevMUD J C Lawrence
                      • • My vision for DevMUD ApplePiMan@aol.com
                  • My vision for DevMUD ApplePiMan@aol.com
        • My vision for DevMUD ApplePiMan@aol.com
        • • My vision for DevMUD Jon A. Lambert
          • • My vision for DevMUD Hal Black
            • • My vision for DevMUD ApplePiMan@aol.com
      • My vision for DevMUD Jon A. Lambert
  • My vision for DevMUD Chris Gray
  • My vision for DevMUD Chris Gray
  • • My vision for DevMUD Ben Greear
    • • My vision for DevMUD Jo Dillon
      • • My vision for DevMUD Ben Greear
• DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) Jon Leonard
• • DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) James Wilson
• DevCore Project Management Ola Fosheim Grøstad
• • DevCore Project Management Adam Wiggins
  • • DevCore Project Management Ola Fosheim Grøstad
  • DevCore Project Management Simon Duggan
  • • DevCore Project Management Jon Leonard
  • DevCore Project Management Chris Gray
  • DevCore Project Management Darrin Hyrup
• Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Chris Gray
• Drama Theory Ling
• Moral license (My vision for DevMUD) Ola Fosheim Grøstad
• • Moral license (My vision for DevMUD) ApplePiMan@aol.com
  • • Moral license (My vision for DevMUD) Ola Fosheim Grøstad
• Fwd: My vision for DevMUD Jon Leonard
• DevMUD Prototyping Niklas Elmqvist
• Altima... Thandor
• Fwd: My vision for DevMUD Darrin Hyrup
• Tim O'Reilly's "Open Letter to Microsoft" ApplePiMan@aol.com
• • Tim O'Reilly's "Open Letter to Microsoft" Adam Wiggins
• [DevMud] quick question... Franklyn Colebrooke, Jr.
• signal to noise... Andrew Wilson
• "knights and merchants" - NYTimes review James Wilson
• ADMIN: DevMUD posting authority promotions J C Lawrence
• A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
• • A Small Conceptual Object System For MUDs Emil Eifrem
  • • A Small Conceptual Object System For MUDs Mark Gritter
    • A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
    • • A Small Conceptual Object System For MUDs Jon A. Lambert
• Random Quest Generation chris@realm.zfn.uni-bremen.de
• • Random Quest Generation Chris Gray
  • Random Quest Generation Michael.Willey@abnamro.com
  • Random Quest Generation J C Lawrence
  • • Random Quest Generation J C Lawrence
• Quick socket question Dr. Cat
• • Quick socket question Jon Leonard
  • Quick socket question Ben Greear
  • Quick socket question Chris Gray
  • Quick socket question J C Lawrence
  • • Quick socket question J C Lawrence
  • Quick socket question Adam Wiggins
  • Quick socket question Petri Virkkula
• ScryMUD [CUSTOM] Released under GNU General Public License Ben Greear
• • ScryMUD [CUSTOM] Released under GNU General Public License Chris Gray
• Quick socket answer Dr. Cat
• Rebol Ling
• Spell components, chemistry, and the like... quzah [sotfhome]
• • Spell components, chemistry, and the like... Chris Gray
  • • Spell components, chemistry, and the like... quzah [sotfhome]
  • Spell components, chemistry, and the like... JavaAl@aol.com
  • Spell components, chemistry, and the like... Adam Wiggins
  • • Spell components, chemistry, and the like... quzah [sotfhome]
  • Spell components, chemistry, and the like... Nathan F Yospe
  • Spell components, chemistry, and the like... quzah [sotfhome]
  • • Spell components, chemistry, and the like... Hal Black
    • • Spell components, chemistry, and the like... Ling
      • • Spell components, chemistry, and the like... Caliban Tiresias Darklock
        • Spell components, chemistry, and the like... Ben Greear
        • • Spell components, chemistry, and the like... Caliban Tiresias Darklock
        • Spell components, chemistry, and the like... quzah [sotfhome]
        • • Spell components, chemistry, and the like... Caliban Tiresias Darklock
          • • Spell components, chemistry, and the like... quzah [sotfhome]
          • Spell components, chemistry, and the like... Hal Black
          • • Spell components, chemistry, and the like... Peck, Matthew x96724c1
          • Spell components, chemistry, and the like... Nathan F Yospe
  • Spell components, chemistry, and the like... Ben Greear
  • Spell components, chemistry, and the like... JavaAl@aol.com
  • Spell components, chemistry, and the like... Chris Gray
  • • Spell components, chemistry, and the like... Nathan F Yospe
  • Spell components, chemistry, and the like... Adam J. Thornton
  • Spell components, chemistry, and the like... Franklyn Colebrooke, Jr.
  • • Spell components, chemistry, and the like... Emil Eifrem
    • • Spell components, chemistry, and the like... Nathan F Yospe
• ADMIN: Attributions J C Lawrence
• AMIN: Unsubscriptions J C Lawrence
• OO Design Question Brad Leach
• • OO Design Question J C Lawrence
• Chemistry [Warning, scientific content] Peck, Matthew x96724c1
• MUD clients, testing Chris Gray
• • MUD clients, testing Scatter
  • • MUD clients, testing J C Lawrence
• JOB: Project manager and scaling/networking guru needed for game project J C Lawrence
• More module ideas Mark Gritter
• The Innerworld Project Niklas Elmqvist
• META: FAQ's bios. Ling
• Mage 2 Mage 0.89 J C Lawrence
• Game library notes J C Lawrence
• World Building Page Ling
• ScryMUD [CUSTOM] Code release 1.8.1 Ben Greear
• DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
• • DIS: Client-Server vs Peer-to-Peer J C Lawrence
  • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
    • • DIS: Client-Server vs Peer-to-Peer J C Lawrence
      • • DIS: Client-Server vs Peer-to-Peer Ling
        • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
          • • DIS: Client-Server vs Peer-to-Peer Ling
            • • DIS: Client-Server vs Peer-to-Peer Nathan F Yospe
              • • DIS: Client-Server vs Peer-to-Peer Ling
            • DIS: Client-Server vs Peer-to-Peer J C Lawrence
            • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
              • • DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
                • • DIS: Client-Server vs Peer-to-Peer Marc Hernandez
                  • • DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
                    • • DIS: Client-Server vs Peer-to-Peer Marc Hernandez
                      • • DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
                        • • DIS: Client-Server vs Peer-to-Peer Mik Clarke
                        • DIS: Client-Server vs Peer-to-Peer Adam Wiggins
  • DIS: Client-Server vs Peer-to-Peer Jon Leonard
  • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
    • • DIS: Client-Server vs Peer-to-Peer Greg Underwood
  • DIS: Client-Server vs Peer-to-Peer Greg Underwood
  • • DIS: Client-Server vs Peer-to-Peer Marc Hernandez
    • • DIS: Client-Server vs Peer-to-Peer Greg Underwood
    • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
    • • DIS: Client-Server vs Peer-to-Peer Greg Underwood
• Ruminations on CVS and developing in the Bazaar Ben Greear
• • Ruminations on CVS and developing in the Bazaar Chris Gray
  • • Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
  • Ruminations on CVS and developing in the Bazaar J C Lawrence
  • • Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
    • • Ruminations on CVS and developing in the Bazaar J C Lawrence
• Ruminations on CVS and developing in the Bazaar Petri Virkkula
• DevMUD: List data, subscription, and the rest J C Lawrence
• • DevMUD: List data, subscription, and the rest J C Lawrence
• Atention SSH/Java-developers (MindTerm update) J C Lawrence
• ScryMUD/Hegemon code Release Ben Greear