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
Ola,
I think you made some good points about the statically linked model, and
some even better points about doing a lot of hard thinking and design ahead
of time. However, setting up all these straw men to burn down does not do
justice to your otherwise good comments.
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.
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".
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).
3. You could also use this to take care of something that several people have
mentioned about keeping the client connections alive between reboots, instead
of having a seperate program. There's at least two ways to do it, dynamic
loading is one of them.
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.
> - 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.
> - 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)
> - 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. I am not one of
them, but I guess some people have use for it. And apparently the folks from
UO think it is cool to put a babelfish in everyone's ear so that people from
all around the world can play and talk with one-another. I think that's cool.
I'm not going to do it for my mud, so I don't particularly want any more than 8
bits for a text character. I can see how, for instance, Korean people might
like it, to see all of the beautiful oriental characters of their native
language in the game.
> 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.
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 do agree, however, that some planning needs to be done. Perhaps we need
a problem statement, or a statement of purpose for DevMUD.
> Anyone who has tried to develop a framework to be used by others (I have)
> will probably discover that it is extremely hard, and once it is done, even
> if you do document it, almost all users will give up understanding the
> underlying foundation and settle for some slight modifications of the
> surface instead. DevMUD does have a better chance than most frameworks, but
> only if it involves potential users throughout the process... :-/ Which
> suggests: involve as many developers as possible, at least in reviews, don't
> push them away, but set up a huge todo-list instead :-)
Agreed, a great idea. We need a big TODO file in CVS that everyone can add
to. Or perhaps a family of TODO files for better organization (TODO.features
TODO.modules, plus individual TODO files in each module's home for that module)
> 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)
But this does come back to a VERY important point that you made, which has
not yet been satisfactorily answered: What ARE the design goals of DevMUD??
No one wants to pin it down and say what it should do and what it should not.
I think that the core design is very important, but perhaps it would help
to have the purpose pinned down so we can discuss the merits of the core
architecture in the context of the purpose of DevMUD.
I'll make an attempt. I humbly submit my vision (feel free to revise):
-------------------------
DevMUD is a toolbox of modules that one can use to develop a new MUD, or
combine to run a complete MUD.
The modules that compose the DevMUD Toolbox would be modules that relate to
MUD operation. The goal of these objects is to produce an abstract interface
to functionality useful to a MUD. Some examples of low-level functionality
would be: a peristent database storage module, a client communication module,
spatial models, code interpreter/virtual machine, an event handler, etc.
Higher level modules would depend on these lower level modules for
functionality.
The DevMUD Toolbox will also contain these high level modules to illustrate
how modules can be put together to form a complete, fully functional MUD.
The DevMUD specification will dictate the module interface and protocol for
module dependency.
The goal of DevMUD is to provide a springboard for MUD developers to design
new MUD engines, without becoming mired down in the details of individual
components. Because the DevMUD toolkit supplies usable low-level modules, the
MUD designer can simply use these modules, then concentrate on MUD design,
rather than become an expert in databases, networking protocols, compilers,
and any other area already implemented in a module. The motivation for writing
DevMUD is to advance an unrealized future in MUD development as inspired by
the MUD-Dev mailing list.
The success of DevMUD will be judged not only by the quantity and variety of
MUDs developed which use at least one module from the DevMUD toolkit, but
also by how many modules from the toolkit are used by these endeavors.
In Summary, DevMUD is composed of three parts:
1. The Specification: A specification for an interface of DevMUD modules.
2. The Glue: A means for linking such modules together while honoring the
specification.
3. The Toolbox: A set of modules conforming to this interface specification,
at least one subset of which will be a fully-functional MUD.
-------------------------
I've consciously tried to leave out implementation details, so that the
implementation is driven by the design goals, not visa-versa. These are my
goals for DevMUD, I'm interested in what other people envision. 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).
Once we settle on the goals for DevMUD, we can offer some more details.
Hal - Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- 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
- 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
- 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 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