[MUD-Dev] MMORPG/MMOG Server design
J C Lawrence
claw at kanga.nu
Sat Feb 22 10:59:56 CET 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-archive
mailing list