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
Niklas Elmqvist wrote:
>
> 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).
What you have gotten to so far is not far from UNIX with shared memory...
That's silly.
> 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.
Well. The reason for me jumping in and wasting a lot of your and mine time
is the same reason for why a carpenter probably have trouble not telling you
that you could risk ruining your house when you try to do it all by
yourself. :( Although I am sure that the list members have a lot of
experience, I am also quite sure that that experience is quite different!
And what people think is a good idea is also quite different... If you
don't get a grip on this early on, then you risk some unpleasant problems
later. Agreeing on a discussion which relates everything to a common
reference end-system could make some of these problems surface.
This is probably not enough, but it is at least a start. Studying systems
development might not teach me what you should do, but it does at least give
me some ideas about what is risky and how to somewhat reduce that risk. (You
don't want to end up like Multics, do you?)
> I couldn't answer which school I cherish since I'm self-taught as of yet!
> :)
Ok, I don't think you are alone there. Anyway, I'm sure you'll get enough
of that stuff at Chalmers.
> > 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.)
No, but I guess I could be somewhat happy if you tell me how you are going
to make sure that this happens...
> > 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).
No, I have never lost that distinction. However I don't think it is a good
idea to make that distinction hard and forget about the context. Why?
Because then you'll never be able to make rational decisions. Everybody
want something without limitations, but ah, there are only a few cases where
"less is more". Typically, not imposing constraints and avoiding decisions
leads to a huge machinery which does almost nothing... IMO
Making a framework is the most difficult thing you could do... A plugin
approach for a world where you basically WANT lots of interdependencies and
interaction is ahh... a challenge. Plugins for Netscape or a raytracer is a
lot easier.
> 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!
Analysis doesn't have to be rigid and formal. In fact, the most popular
techniques seems to be quite informal. (drawing pictures with entities and
conflicts for instance) The output from the preliminary analysis should of
course be somewhat structured...
[a good start snipped]
> > > 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.
May I propose that you find an existing MUD which is typical for the kind of
MUDs that DevCore should support? You probably want a system which almost
everybody "knows". Then see how this fits in the "plugin" approach.
1. Try to pinpoint the most important objects and their relation.
2. Sketch plugins. (combat,rooms,connections etc)
3. Identify where objects will be born and where they die.
4. Identify which plugins needs what info, and who changes what object.
5. Figure out where the bottlenecks will be.
6. Think about what you need to make the plugin approach work for this
particular system
Even though I think Bruce's survey would be even better, this approach does
at least help you identify some fundamental problems which you otherwise
could miss out on. (assuming that throwing out "plugins" is not an otption)
> > 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.
Good, something which belongs in the formulated vision. I am sure there is a
lot of intuition around about what is wrong with the current generation
(beyond plugins), getting that down on paper (err) should be worthwhile.
--
Ola
- 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
- 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