[MUD-Dev] MMORPG/MMOG Server design

[ceo]

J C Lawrence wrote:
> 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.
 
> 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.

I've seen at least a couple of academics, and even practising
software engineers, give the advice:

  "Never leave a piece of code alone until its as generic as you can
  possibly make it."

I turned this concept over for a long time, but could never find a
good reason for it. I've tried it, repeatedly, and it seems to suck
(maybe I'm doing it wrong) :). I mention it because it seems to me
to represent the oppposite end of the spectrum to YAGNI.

I think the key point (to any unbelievers out there ;) is to
consider whether you work in an environment where you tend to know
well the problem space in advance of writing code. There are
industries where this is almost always true; friends in Financial
Services development go all wide-eyed and disbelieving when they
hear that there exist professional developers who actually DARE to
work in any other way :).

AFAICS, there are very few people in MMOG development who have such
a luxury (and they aren't working on anything "interesting").

However, let me suggest a Third Way (particular to MMOGs /
MUDs). This might not be a good idea (I've not tried it out much ):

  Architecture != Server Application != Game.
  Arch + Server App + Game == the development project

Say what? Sorry :). The point of these simple observations is that
they are the basis for seeing that there are mulitple simultaneous
valid views of the development - and, fortunately, there are things
we do actually know very well in each of them, but these things tend
to have little overlap. You should be able (unless you *really* know
nothing at all about server development - but you can address this
by doing some mugging up on the web, and searching MUD-DEV archives
for subject-lines containing "server" :) ) to design and implement
some small percentage of each of the three components first-time
round almost perfectly (very minor changes accepted).

If you then stop, take a step back, and try and rationalize each of
these bits in each of the other two components, it's time to take
the YAGNI approach. The advantage is that you are using YAGNI to
bridge between what are actually (or should be) exceptionally
well-defined and well-understood components; this means that you're
likely to be forced into a pretty decent result after only a few
iterations.

After that, you're on your own; <waves magic wand, and ignores the
hard parts>.

I'm hoping this can avoid iteration-itis. Waterfalls, spirals, etc
are all very well and good, but from what I've seen there's often no
simple answer (and no easy decision) to "when to stop?" in a nice,
big, complex - probably distributed - system.

Adam M


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