[MUD-Dev] MMORPG/MMOG Server design

[J C Lawrence]

On Sun, 23 Feb 2003 03:49:41 +0000 
ceo  <ceo at grexengine.com> wrote:
> J C Lawrence wrote:
>> On Sat, 22 Feb 2003 08:56:59 -0500 Derek Licciardi
>> <kressilac at insightbb.com> wrote:
 
> 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've been given the same advice, and to an extent recommend and follow
it.  To an extent.  When writing new code I try and genericise it as
much as I can without giving myself extra work.  I do this for two
reasons: when I understand the problem in utterly generic problems I can
be confident that I actually understand the problem, and generic code
*tends* to be easier to write and smaller once you get the right
genericy level.  In the cases where the generic version is smaller,
faster, simpler I write that, otherwise I write the tightly bound
version because that's smaller, faster, simpler.  However I deconstruct
down to the point where I feel I can make that an educated choice.

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

Aye, 12 years ago I worked in areas like that.

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

I suspect we won't for years yet.

> 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

Internally I tend to view it as:

  Requirements == The Dream (It was a nice dream, warm, fuzzy, and..)

  Architecture == The Vision (Follow me men, here's the plan!)

  Implementation == Childbirth (It was fun to start, uncomfortable but
                                exciting to develop, painful and bloody
                                to birth, and scary as heck for the
                                future)

Which translates rather well to architecture/server/game, revealing that
its really just a naming of the standard three planning divisions.

Much of our personal understanding of each of those steps is strobed.
We've snapshot singular experiences or point understandings (an incident
with an old fart engineer, an off comment by an excellent manager, an
insight from a hobby horse project) that we try and string together into
something well tell ourselves in a cohesive whole, and in isolation they
work rather well.  Its when you put them together, in a real world that
the glue comes out of the joints.

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

Only if you predefine your audience rather exclusively.  Doing that
across your three components is non-trivial.  We might like to think its
all easy stuff, and in truth it is (I'd likely gag and stumble on some
of the game points), but it requires both a breadth and a depth of
understanding that is all too rare.  Think: How many engineers have you
dealt with who just have absolutely no sense of architecture or overall
pattern to a project?  Sadly, for me, its been the majority.

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

I've found YAGNI valuable in the opposite direction: from the trivial
components on up.  It encourages in me a clearer understanding of which
bits actually are skeleton, are factually essential (and not just
wanted/liked), and a much better understanding of what the dependency
graph is for the desired functionality (as versus the implementation).

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

*poof*

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

Given that specifications in research projects (anything in a field
which contains significant mysteries) will creep by definition, and that
feature compleat is a function of the learning curve in defining a
project which in turn is a function of the learning curve of researching
the space...means you're dealing with human perception and second
guesses.  <shrug>  Or am I merely being too cynical again?

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