[MUD-Dev] MMORPG/MMOG Server design

J C Lawrence claw at kanga.nu
Sat Feb 22 10:59:56 New Zealand Daylight Time 2003


On Sat, 22 Feb 2003 08:56:59 -0500 
Derek Licciardi <kressilac at insightbb.com> wrote:

> To be able to afford and complete it, define the implementation
> interfaces such that your subsystems can be replaced with more
> robust/scalable versions.  

<prepares to chant>
  You Aren't Gonna Need It: 
    http://c2.com/cgi/wiki?YouArentGonnaNeedIt

  Worse is Better: 
    http://www.dreamsongs.com/WorseIsBetter.html
    http://www.naggum.no/worse-is-better.html
                      
  Good Enough is Best: 
    http://mired.org/home/mwm/good-enough.html

  Refactoring: 
    http://c2.com/cgi/wiki?WhatIsRefactoring

  KISS:
    http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork
<breathes>

The general approach I'd recommend is to never write code, or
design, as if its the last iteration (ie YAGNI).  Instead design
just enough for what you need, write just enough code to do what you
want, and expect to come back to it again and again as your project
rolls forward.  It seems counter-intuitive (but i know I'm going to
need XXX and I might as well do it while I'm here!), but in practice
it pans out rather well.  One of the nicer advantages of this
approach is that you tend to have a much clearer view of the problem
space (and the code) on revisits then you have on initial approach
-- its a way of getting much of the advantages of the three pass
rule at the micro-level.

> Admit to yourself and your team that it is at least a two pass code
> implementation.(likely more) 

Three is the usual for me.

> The hard part is keeping an eye on the true game vision and not
> painting yourself into a box while achieving a smaller milestone.

I find scenarios useful for this.  Paint out a number of play
scenes, what the context is, what's in the environment, what the
various active entities do etc and how the play goals are
accomplished.  From there align that with the base principles of
your project, "Players must be able to...").  Collect these -- stick
them in a Wiki.  Review them and add to them frequently.  Whenever a
new feature is considered, paint a scenario for it, and review it
against all your extant scenarios AS IF YOu WERE A PLAYER (players
have different goals and purposes than you do, so justify your
actions as a player in terms of player goals) and against your list
of base principles.  Keep those scenarios even if the feature that
created them is discarded -- they provide useful guidelines of what
not to do as well.

The XP world seems to call these UserStories, tho they have a
slightly different definition:

  http://c2.com/cgi/wiki?UserStory

And then rolls those into the PlanningGame:

  http://c2.com/cgi/wiki?PlanningGame

--
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list