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
On Sun, 1 Nov 1998, Ola Fosheim Grøstad wrote:
> Niklas Elmqvist wrote:
> > Secondly, I can easily see a quite large portion of the members of this
> > list becoming involved in the project since it *should* cater to just
> > about any kind of MUD developer/designer.
>
> Which IMHO is a bad idea (I guess I have said that a couple of times now)
> from a system development point of view, especially if you are going to
> break new ground.
I hear what you're saying. However, I am not sure that we *cannot* make
this distinction like you are saying. The way I see it, DevCore (I like
that name, btw) should be able to raise the abstraction level of MUD
development from OS-level to a common-ground platform level. That there
later will be modules built on top of this by DevMUD members for people to
use and look at is almost a secondary goal to me (at least at the moment).
> Anyway, I believe evolutionary/participatory/usercentered were the buzzwords
> of the 90's... I've never seen anyone argue that one should skip preanalysis
> and avoid defining goals etc.
Right. It's probably been too little of that.
> Well, it is practical to actually find the major problems instead of jumping
> on the first one which looks cool and which is so remote to the final system
> that there are no strong opinions about it. If you avoid discussing the
> conceptual "objectsystem" only because it will lead to a heated debate then
> the project is already off tracks. Actually, recovering from a heated
> situation early in the project can be very good in the long term. Bring up
> all the conflicts you can early on. It's good for the group to confirm that
> it can handle such situations. (Besides, it is a good idea to resolve
> conflicting views before members have invested too much pride in them).
Well, as stated by other list members (Chris, methinks), the participants
of this list are quite experienced MUD developers which can be expected to
already *know* the key abstractions of a MUD server. We should of course
take advantage of this. Then again, it is still imperative that we
rigourously define these so that it is clear what we all want.
> > Whoa! Grumpy today, are we? You are being more than a little unfair, I
> > would say. I, for one, am *very* interested in design and analysis,
> > especially in the context of OO, and I am sure that other DevMUD
> > supporters are as well. Trust me, I *know* the importance of good design
> > and thinking before you code -- I've been in the situation of not having
> > done that and being stuck with the results.
>
> OO as a methodology generally means you have (assume) a domain. OO is
> useless without something to model. At least by the scandinavian school
> (which I assume you cherish?). Americans tends to think in terms of abstract
> datatypes, which I don't think OO, as developed, is entirely suitable for.
> (other more symbolic approaches look more promising)
I couldn't answer which school I cherish since I'm self-taught as of yet!
:)
> > The way I see it, DevMUD is a sort of kernel or development platform for
> > MUDs. It is *NOT* a MUD in itself! It is not even a codebase! Therefore,
> > we have quite different design goals than a fully fledged MUD. Our mission
> > (at least at this point, other things will follow later) is to make sure
> > that we create a powerful-enough server platform to allow for just about
> > any feature developers want to add.
>
> Oaahhhhh :'( You started so nicely with "OUR MISSION IS", sounded like a
> vision coming, but then you followed up with "everything" which basically
> means "nothing". :(
Right. I'll rephrase to one I *think* has meaning: "Our mission is to make
sure that we create a powerful-enough game server platform to allow game
developers to implement just about any game feature in it." Happy? (I
presume not, of course.)
> So, the current context and goals are thus (combining various input,
> avoiding technical implementation):
>
> - DevMUD will do everything
> - DevMUD requires no programming skills
> - DevMUD allows developers to replace things they don't like on all
> levels with no external sideeffect
> - DevMUD should cater for commercial needs
> - DevMUD is developed for recreational reasons only
> - DevMUD is fully public domain
> - DevMUD assumes nothing about I/O
> - DevMUD assumes nothing about lag
> - DevMUD supports janpanese (and arab? (right to left)) users
> - DevMUD supports graphical clients
> - DevMUD supports text clients
> - DevMUD does not assume any entities (not even connection, user,
> avatar, item?)
> - DevMUD does not optimize for anything
> - DevMUD will support both spatial and room models
> - DevMUD is built using components provided by a wide variety of
> collaborators who don't assume anything beyond their own work.
Again you seem to be lost in the distinction between DevMUD and DevCore
(this might be because of the earlier name confusion, of course). We are
*not* speaking about a MUD server! DevMUD (actually, DevCore -- sorry
about this) is a MUD server platform (or, even better, a game server
platform).
Nevertheless, this is good. While I don't agree with many of your
conclusions here on the basis that I would say that we have touched upon
them, it uncovers a lot of our blind spots. You are also right in saying
that we may have been a bit too generic. Thank you.
Okay, I'll have a shot at defining the high-level assumptions. Not much in
the way of a formal analysis, but it's a start! Please fill in (or
remove?) more items here, keeping in mind that we're trying to do
conceptual analysis. And remember, these apply to DevCore, not necessarily
to DevMUD...
DevCore high-level goals:
- create a state-of-the-art game server platform (advance an unrealised
future...)
- provide fertile soil for building internet games
- efficiency
Design philosophy:
Lean and mean.
Target audience:
- MUD developers
- commercial game developers
Main functionality:
- game logic is dynamically loaded in native code modules
- the core is like an API for modules
- the core provides ways of inter-module communication, probably using
plain C bindings (function pointers), which can be used to
negotiate higher-level protocols
- multi-threading (modules request threads from core)
- event manager (modules pass their events here in the safe knowledge
they eventually will be executed)
- module manager/bootstrapper (takes care of the loading and unloading of
modules)
Technical decisions:
- Dynamic loading of modules
- easy replacement of game logic (avoid downtime, important for
commercial developers at least)
- effortless extension and/or modification
- C bindings will be used as the "glue" between modules
> > Of course, it is certainly useful to try to view DevMUD from the context
> > of different game types
>
> It should be mandatory. (but a lot of work)
Agreed. We need to look into this.
> 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*
Well... There problem is that there *are* already a lot of that kind of
servers around. I would like to think of DevMUD as the "next generation"
of MUD servers.
> Ola
-- Niklas Elmqvist (d97elm@dtek.chalmers.se) ----------------------
"The trouble with being a god is that you've got no one to
pray to."
-- Terry Pratchett, Small Gods - Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
- 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
- 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