[MUD-Dev] Re: Analysis and specification

Ben Greear greear at cyberhighway.net
Mon Jun 15 22:41:50 CEST 1998


> 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.

I'm still young, dumb, and happy, so I've got only general notes, use
cases at best.  I just code my way into a corner, and then delete my way
out!  Seriously, I'm not yet convinced that any kind of formal design docs
would help me all that much.

Let me rephrase that.  I can't seem to agree with myself over what the
final picture should be, so I'm designing a base system (driver I guess
you'd call it) and I'll go from there.  Of course, using good OO and
designing for the unknown is the one steady goal.

On coordinates, how does that help you notify neighbors of events?  I
currently am breaking the universe into sectors just to make finding
neighbors easier.  Hrm, maybe 3 ordered lists on each x,y,z coordinate.
Then you could find nearest with out too much work, although your
incrimental work (keeping such very large lists in proper state) 
might kill you.

Ben





More information about the mud-dev-archive mailing list