[MUD-Dev] Re: MUD Design doc (long)

[J C Lawrence]

On Mon, 14 Dec 1998 10:03:50 +0200 
Thinus Barnard<thinus_barnard at bigfoot.com> wrote:

> I am sure that it does not need to be codebase specific. You can
> do different HOWTOs for the core parts of a MUD. Say HOWTOs on the
> following:

> Networking and sockets: Just a basic explanation of what routines
> you need. Say you need a NewCnct routine that informs the library
> that a new connection has been established and a new player object
> should be created and a login handled. Then you need a routine for
> when an error occurs, a routine for when a connection is dropped
> and a routine to send a message to the socket. This document can
> then also take a look at what pitfalls to avoid, general problems
> with sockets, binary approach, etc.

An excellant idea that is absolute murder to do in practice without
great self discipline in yourself and all the other code
maintainers.  (Don't imagine for a second that commercial code shops
haven't faced and lost to the same problems).  It is too easy to fix
or extend the current code and not update the design docs
accordingly.  That's why maintenance programmers are so scorned and
get (sometimes) get paid the big $$$.

  It is already tough enough to get code maintainers to keep the
comments updated with the code -- you think they are going to keep a
secondary and physically unrelated document up to date as well
without threats of bodily harm?

It is exactly this problem that most of the literate programming
tools and standards were evolved to solve: essentially specially
formatted and tagged comment strings embedded in the code which a
standard tool can extract and create useful documentation from
(Knuth IIRC did one of the early ones, extracting TeX documents from
the subject source).  There are quite a few such.  The only
requirement then is that code maintainers (and the original
developer) keep the comments up to date with the code -- a far more
reasonable demand than that they maintain the source, the comments,
and the design doc, human nature being what it is.

I actively dislike such code documentation tooks as I find they make
the code too difficult to read as _code_, and not very easy to read
as _documentation_ without extracting the documentation from the
code. YMMV.  I prefer embedding large blocks of discussionary
comments in the code which attempt to explain what is going on and
why at an algorithmic/design level, and then let the revision
control system comments track the minor stuff (context diffs are a
wonderful friend).

> Command handling: How to implement commands in your mud. When and
> where should a command be handled? 

This assumes that you have a central command processor, and implies
that commands process within a larger inherited command or process
context.  Neither is necessarily true.  Murkle, for instance, rune
commands as independently scheduled stand-alone independent threads
with no synchronisation between threads and precious little
inherited process environment (specious argument as to whether they
even *have* a process environment).  As such commands are not
handled, they are run as autonomous competing processes.

  $ fgrep fprintf *.c &

> Should NPCs and players have different command sets? 

Should there actually be *ANY* distinguishing features between NPC's
and players other than the source of their actions?  There are good
reasons for both approaches and reasonable design methods to salve
most of each other's problems.

> What about free text commands? Some questions to address in a
> command handling doc. Can also be more specific with a design of a
> command handling system with the focus on how easy is it to use
> and add new commands, how easy is it to customize commands and how
> much can code duplication be reduced.

A well defined inheritance model can do wonders as can a good
grammar, which brings up the questions:

  Central grammar and vocabulary?

  Standardised grammar at all?  

  Per-object dynamic vocabulary?

  Rules for genating precedence and grammar rules with dynamic
vocabularies?

  Is grammar a dynamically inherited structure across objects?

  Single/multiple inheritance with what precedence rules?
  
> Timing: The first time you need a timing system will probably be
> for combat.

Combat for me is still largely an untimed system.  It also doesn't
work they way I'd like (see the lsit archives for very extensive
threads on my various thoughts on combat systems).  

Roughly the common models break down to:

  1) Timed action 
  2) Timed rounds with action limits per round
  3) No time controls 

In #1 each player action (eg "bash buffa") takes a preset length of
time, and prevents the player character's motions/actions during
that time.

#2 is a little different.  Players submit the actions that their
characters are going to perform in the next "round", where a round
is a known and predefined length of time.  At the end of the round
all the various actions by the various players are resolved against
each other (the action and round resolution logic can be quite
complex -- see the combat package threads in the list archives) and
the final results computed and reported before the next round starts
and the players again submit their intended actions.  It is common
with round systems for player characters to operate under a quota
system, where each of their proposed actions has a quota value and
their total must not exceed some maximum.  See Jon Lambert's posts
on his (IIRC) round based combat system for some interesting design
notes on this area.

#3 is where I've been heading, while mixing in generous dollops of
#1 and #2.  Loosely, each character does whatever he can as fast as
he can with the limiting factor being the execution time of his
various actions and the speed with which he can submit them.
Arguments about fairness are of course rife with this approach.

> Also for weather, seasons, scheduling of mud events, etc. How to
> implement a system that can handle all these timing issues and
> still be flexible enough to add custom timing routines?

There are two definitions of time:

  -- in-game in-world time
  -- real time

They are typically not synonymous, and their ratio need not be fixed
and need not be explicitly depended on.  This is an early design
decision which affects a very large range of other bits of the game.

In fact, you don't actually need to define that there *is* a
universal in-game in-world time.  A side effect of the system I'm
working with for Murkle is that the rate of time passage is
individual and dependent on what is happening about that character
at any instant.

Yes, this means that the following is possible:

  > stats
  You are 10 days old.
  > stats bubba
  Bubba is 10 days old.
  > stats boffo
  Boffo is 10 days old.
  ...play the game for a while...
  > stats
  You are 50 days old.
  > stats bubba
  Bubba is 30 days old.
  > stats boffo
  Boffo is 168 days old.

I don't however see this as a problem

> Combat system: This will be more specific. The combat system will
> integrate with the timing system. 

Ahem.  It *may* integrate with the timing system.  It doesn't have
to.

> The combat system must determine what amount of damage is done,
> what messages to display to the different characters involved in
> the combat, what attibutes is necessary for weapons and for
> armour, etc. 

Not so fast.  No, the combat system does not need to decide what
messages are displayed, and it is easy to argue that in fact it
*NEVER* should be involved with presentation layer concerns like
message texts.  

Another approach is to have the individual character objects receive
messages (message in the programming/massage-passing-architecture
sense) from the combat system and then derive from there how or if
to present present that data to their players.  The combat system is
a set of mechanics that controls how combat is processed.  You can
muddle the presentation layer in there, but it is exactly that, a
muddle, and that approach removes significant flexibility.

Further, the details of the machanics of armour and weapons really
are not the concern of the combat system either.  That's data
computation stuff, not process mechanics.  Think "algorithms", and
"process flow", not "how does the plate mail affect the war axe?"

> This will differ a lot from mud to mud. Maybe a few different
> systems can be discussed in this doc.

Aye, we've hit many of them here in this list and haven't come
anywhere near to exhausting the field.  I *still* haven't come up
with a combat system I think is usefully playable.

> Skill system: Also very specific. There will be several designs
> dealing with classes, races, skills, spells, levels, experience,
> etc. The core of a few systems can be listed to give an insight to
> the different types of approaches.

Skill trees, single or multi-rooted, or skill webs, or a hodge-podge
of intersecting trees and webs, or simple linear progressions of
names sets with current state being an amalgamation of all the
scalars.

> Player object: What should all go into the player object?  Should
> it be very different than your NPC object? Should you have a
> different login object and a different player object? What
> physical statistics do you need for a player object?

Other levels of seperation enclude:

  login account from player character
  player character's family/clan/regiment from individual player character
  player character from character body
  
I, for instance, seperate the account from the character from the
body/bodies it controls.  I also don't distinguish at all between
NPC's and player characters.  The bodies of course are all the same
between them..

> NPC object: How to do guards. How to do mobiles. How to do AI.

Are guards really a special case?  Are mobiles any different than
NPC's?  Are NPC's really any different from any other object?  

Why?

There's a fairly obvious difference between an inanimate and
uninteresting rock in a game, and a ferocious dragon.  But, at the
code and design level, need there be any difference between that
dragon and a magical intelligent sword?

> PS: Another example of a design doc can be found at
> URL:http://www.cd.chalmers.se/project/so2403/so2403_toc.html

Ahh, good one.

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...