[MUD-Dev] Re: Analysis and specification

Shawn Halpenny malachai at iname.com
Mon Jun 15 15:10:12 New Zealand Standard Time 1998


On Fri, Jun 12, 1998 at 08:57:44PM +0100, Greg Munt wrote:
> I decided to give up waiting for someone to add some more to this thread
> before I responded. I note with interest (and dismay) that the number of
> posts in this thread are scarce.

That's because I am (and have been for the past 2.5 years) busy working on my
design dox...

> Is the topic just not interesting enough, do you not feel knowledgable
> enough to comment, or do you not think analysis has any part to play in a
> one-person development team? (If the last one is true, you're very, very
> wrong.*)

Very interesting and I am a solo-developer.  My two cents:

Initially, I'd started with a ROM knock-off and got progressively more
unhappy with how hampered I was by the design.  At that point my append-only
files of ideas began and I decided to completely write from scratch.
When the files became unwieldy/unmanageable/crufty I decided to do it right
and draft a "formal" design specification.  Currently, I've got it broken into
two major parts:  design for the kernel and design for the world itself.

The kernel D-doc details the main components:  DB, event handling, internal
scripting language, networking, internal object representation, parser.
It:
    - gives a clear indication of what the entire system is supposed to do
    - lists any currently foreseen restrictions and limitations
    - defines what the function of each subsystem is
    - details how the object security model works
    - lists and defines subsystem interactions
    - describes public interfaces
    - gives algorithms for portions of each component 
    - etc.

The world D-doc details how the game universe works:
- base object templates (designing these is akin to very low level building)
    - containers, buildings/rooms
    - affects
    - wounds
    - the default "intelligent" NPC behaviors
    - etc.
- object interaction
    - coordinate spaces
    - movement
    - how the economy works
    - weather
    - communication
    - combat and object damage systems
    - skill system
    - etc.

ATM, the kernel doc is incomplete.  A sizeable portion of the idea files
will end up in the world doc, but I'm holding off on that until the
kernel doc is complete.  Once the kernel doc is complete, I'll implement
the spec and work on the world doc.  When the world doc is done, I'll create
the base universe.  It's possible to work on parts of the world doc even
if the kernel doc is unfinished.

Some things that help the design process:
- Track all design elements that have been rejected along with the list
  of reasons why each was unacceptable (no point designing in circles).
- Maintain a section devoted solely to open questions:  things that
  haven't been resolved yet but for which a solution is required for
  some element of the current design.  Revisit this often.  
- Having the Design Patterns book
- Be prepared to scrap a design when it becomes unworkable.  I had put
  quite a bit of work into a combination coordinate/room-based
  geography, but it got cumbersome and kludgy for doing what I thought
  should be fairly simple things (like notifying objects about area
  affects) and I decided to drop it in favor of a completely coordinate-
  based system.

Let's add to this list.

--
Shawn Halpenny

I know that you believe you understand what you think I said, but,
I am not sure you realize that what you heard is not what I meant.  




More information about the MUD-Dev mailing list