November 1998
- ADMIN: Unsubscriptions J C Lawrence
- ScryMUD [CUSTOM] Code release. Ben Greear
- Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
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.
> Well, the way I see it, those are technical prototypes of some important
> aspects of DevMUD. It is quite important to ensure that the technical
> foundation upon which the project rests is a stable one. All major
> projects do this -- it is vital.
Actually, the first thing you do is to narrow in on the technical options,
usergroups, problemspace... Then you do a needsassesment and generally
collect relevant information, including the context the system is going to
operate in. Then you figure out what the real problems are. (maybe no
computersystem is needed at all, maybe management are trying to solve a
social problem with a computersystem) Then you see what problems and areas
are so uncertain that you need to go for the more expensive prototyping
approach, which doesn't have to involve a computer at all. After this you
enter the process which aims at design... Not that prototyping early on is a
bad idea if somebody wants to do it for free. It can be a very good idea,
sometimes you won't know until you have tried.
> If you've paid attention to current software engineering teachings in this
> area, you may be aware of the concept of 'iterative development'. This
> means that the development process is divided into smaller sub-projects
> (or iterations) in which *all* the phases of analysis, design and
> implementation are present. This is what experienced software
> engineers recommend as the 'best' approach to software development. What
> you are describing is essentially 'waterfall development', where we first
> sit around doing analysis, then we do design, and *then*, when we've
> mapped out every little detail and thought about every little
> complication, we hand it over to the programmers to code. This doesn't
> work very well (at least not for large projects) as per the famous axiom
> of battle plans never surviving for more than a few moments into the
> battle.
Actually it all depends. Waterfall works very well if the domain is
wellknown, or if the schedule is tight (it might not work, but it's the only
way to go). I don't think waterfall works well when it comes to endproducts
that are going to be used interactivly, but then again it is generally the
strategy used by game companies I think. (Followed by an iterative balancing
cycle). MUDs have a longer lifecycle so straight waterfall may not be
appropriate. Anyway, waterfall, iterative etc are just FORMAL models. They
don't describe what actually happens. There is usually a little bit of
everything, it is still valid to use the terms when one discuss the process
though. Just like bottom-up vs top-down.
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.
> design. I am merely saying that it is *not* practical to try to anticipate
> every little problem we might encounter.
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).
> The best approach is to find a
> middle way between these two alternatives and use iterative development. A
> layered system like DevMUD should lend itself rather nicely to this
> method.
DevMUD as discussed isn't layered. Layered means one layer is dependant on
the one below. Meaning: lower layers are more general, more lowlevel, more
reusable. Higher levels are closer to the domain. "Plugins" is not a
typical mechanism for implementing layers. (inheritance is). It could be
done of course, anything that can simulate a turing machine can do
everything. Simulating a turing machine is easy, but not terribly efficient.
> 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)
> 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". :(
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.
On the conceptual decisions made:
- Uhm.... unspecified eventmodel?
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)
- DevMUD will have a Virtual Machinelanguage because it is cool (everybody
does it)
- DevMUD will use the eventmodel because it is cool (scalability is
paramount)
- DevMUD will use 16 bit chars because it is cool (it is an international
effort as well)
Maybe you should consider renaming the project CoolComponentCore? (or
GeekCore?) Ah well, I think I'll stick to PhotonCore (fast'n'light ;-)
> 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)
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 :-)
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*
--
Ola - 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
- 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