[MUD-Dev] Debugging techniques

[adam at treyarch.com]

On Tue, 28 Mar 2000, Marian Griffith wrote:
> On Tue 28 Mar, Kevin Littlejohn wrote:
> > It is _very_ handy for being able to change the world physics without
> > restarts - introduce new concepts (like weight, size, etc) on-line, tinker
> > with them, remove them again, without actually disturbing
> > players/builders/visitors.
> 
> I do not understand why this would be so important. Why not simply
> restart the mud after you made some extensive changes? Every other
> mud that I have played had, at some point in time, a test game up,
> that was used for new ideas. If they worked out they were incorpo-
> rated in the actual game, if not, they were discarded.  Seems much
> more sensible to me to do things that way.

It depends on the goals of the server.  Many of the folks here are interested
in making the ultimate "virtual sandbox", and this sort of incredible
flexibility is a primary goal of such an endeavor.  This also leads
towards a kind of mud that *I* would definitely play: nearly infinite
possibilities with free-user programming, but unlike most existing muds
of this sort, the mechanics of the world are actually very well defined.
User programming, then, becomes a matter of twiddling those mechanics, rather
than writing routines which simulate, through well-written text, whatever
it is that the user wants to achieve.  As far as I know, there are no
running muds that achieve this.  (Please correct me if I'm wrong!)

Now, if you're more interested in just making a good 'traditional' mud
and focusing on your game-level features, yeah - doing the above is WAY
more work than you need bother with.  I, for one, do all my development
on my desktop machine, and then when I have features that I'm ready to roll
into the server, rsync to the mud machine, recompile, and reboot.  (Thanks
to modern technology, a complete rebuild of my server takes about 15 seconds,
and it boots in about 3, on a mediocre K6-3/400.)  Certainly players don't mind
the reboots; in a way, it generates excitement when I come on and say, "alright
folks, reboot time..." because they know it means new features are coming
online.  Secondly, and much more importantly, it allows me to run a debugger on
my development version without interrupting the play of the main system.  (I
suppose someone is going to chime in here and say, "Well, if you would just
quit writing code with bugs in it...")

Which allows me to segue, perhaps not so smoothly, into this topic (and hence
the subject change):

- What techniques do listmembers use for debugging their servers?

This actually covers three levels, of course: code, scripting, and data.

The bottom level is code.  I assume that the core of most currently
running servers is C or C++.  I generally use DDD at home (*love* that
undo/redo) and text-mode gdb remotely.  Generally I try to avoid debugging
the main server and just use core dumps to check the cause of the occasional
crash that occurs.  If I notice that a certain character is bugged, I just
copy their player file over to my desktop machine and load them up there
to debug it.  There have been, however, several occasions where there were
bugs in the socket code which were *only* triggered by players typing certain
commands at a certain speed.  (In some cases, they were things that were
impossible for me to duplicate locally, because they required a little bit
of net lag to show up.)  In this case I haven't been ashamed to attach a
debugger to the running server and check it out.  If you're quick enough
at your breakpoints, people will just chalk the lost time up to lag. :)

The middle level is scripting.  The huge amount of time I spend supporting
scripting languages in my professional work (Revenant, Die by the Sword,
and Draconus all make heavy use of scripting) make me not want to bother
with it in my spare time.  I know that scripting is very popular among
listmembers, so I'm sure that someone will chime in here about the 'fun'
of writing your own in-game debugger.  (Note that I'm considering the
term 'scripting' to be inclusive of any special game language, which includes
byte-code compiled languages or even LPC.)

The top level is data.  My first experience with area creation was for diku
(SillyMUD to be exact), and it took me about five seconds to realize that the
data-debugging tools were totally inadequate.  I suppose there's two levels
here: one is actually aquiring the data (text files, an external editor, or
OLC) and the second is "tuning" the data, or making sure that everything works
the way you expected it to.

I use pure text files for my server, as I find them fast and easy to create,
and better yet, don't require supporting an editor or OLC.  (They also work
quite well under revison control.)  My error reporting is still quite limited:
it only lists the line number, the file, and prints the line itself.
Eventually it would be nice to point out the actual problem (like,
'unrecognized flag' or 'syntax error'), but due to the file format I use I
find it quite easy to determine the problem.

In fact, as it turns out, the difficulties I had with writing my first
diku area were not so much a lack of good debugging tools, but a problem
with the format being too obscure.  Mostly it's just rows of numbers, and
it's easy to forget which goes where or forget certain values.

I think I've shown examples of my file format before; it looks like this:

name = "longsword"
material = iron
weight = 5.2 kg
sharpness = good
quality = average

etc.  In almost all cases, the only "debugging" I have to do is fixing a
few mispellings.

This is particular true for rooms; on that diku area I spent at least four
hours trying to get all the rooms to match up properly (due to typos in
my to_room field).  Although I have a to_room field, I generally line up
the rooms by assigning them an x, y, z value, and then the server figures
out which rooms link up where.  Using this method I can write a complete
area and it will usually work properly the very first time I run it.

So I suppose you could say that I avoid data-entry-debugging altogether,
due to a file format that is simple enough that errors are rare and
are obvious and easy to fix when they do occur.  This wouldn't work for
just any server; I could easily envision a heavier simulation where the
data is quite simply very complex, and more intensive debugging tools are
necessary, and possibly creating it this way (in a text file) would be
out of the question.

The second area of data debugging is making sure that you got what you wanted
in the game.  Again, I try to make all the fields no-brainers.  On servers
where you enter numeric values that are in "mud units" that the builder
is just expected to be familiar with, swords that weigh as much as a house
are a common problem.  Fields which use measurements (weights, volumes,
distances, times...) are entered using whatever real world units the
builder wishes (for weight I support pounds, kilograms, ounzes, and grams)
and are then converted to my internal unit (which happens to be grams).

Even then, there's still debugging that must be done.  In this respect I
think that stock diku actually offers a lot of good tools; you can load
up the object, stat it, and then give it to one of your creatures and see
if they can use it in the way you expect.  (typical data debugging: "Oops!
That club is *way* too heavy for the troll chief to wield effectively.
I guess I'll bump up is strength and then lower the weight of the club.")

One possible tool that might be nice here is an evaluate function that does
some manual checking on an object to see what it's obvious uses and problems
are.  For example:

% load my.new.sword
You load the object 'my new sword'.
% builder-evaluate sword
Running builder evaluation on 'my new sword'.
Its quality score is computed at 2507, rating it in the top 23% of weapons.
It is a bit too heavy for most mortals to wield.
Its value (35000 gp) seems to be too low for its quality (sc: 2507).
The skill(s) it requires restrict it to use by: warriors paladins rangers
This item will be easy to repair and it is not expected that players will
ever find it breaking on them.
[etc]

Now, one could say that, as long as one is writing code to detect common
problems with items, one could also turn that code into a correction.
For example, as long as we have a good method to compute the value of an
item, why allow builders to specify at all?  As a builder, my answer would
be "special cases"; so perhaps, by default, the server will compute a value,
but the builder code override it if they chose.  Perhaps the worst example
is ungetable items, a common problem on muds that require a "take" flag on
items.  Obviously the easy fix here is to change the flag to be "no_take",
but even so the server should definitely warn the builder and make sure that
that is what they wanted.

Other debugging techniques?  Muds with free user programming should be
particularly concerned with this issue.

Adam





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