<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Debugging techniques --> <!--X-From-R13: <nqnzNgerlnepu.pbz> --> <!--X-Date: Fri, 31 Mar 2000 12:57:26 -0800 --> <!--X-Message-Id: Pine.LNX.4.10.10003311043430.20773-100000#aeowyn,treyarch.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: Marcel-1.53-0328160951-0b0Ky&5#catling,demon.nl --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Debugging techniques</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:adam#treyarch,com"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00809.html">Previous</a> | <a href="msg00811.html">Next</a> ] Thread: [ <a href="msg00793.html">Previous</a> | <a href="msg00765.html">Next</a> ] Index: [ <A HREF="author.html#00810">Author</A> | <A HREF="#00810">Date</A> | <A HREF="thread.html#00810">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Debugging techniques</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: Mud Dev Mailing list <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI> <LI><em>Subject</em>: [MUD-Dev] Debugging techniques</LI> <LI><em>From</em>: <<A HREF="mailto:adam#treyarch,com">adam#treyarch,com</A>></LI> <LI><em>Date</em>: Fri, 31 Mar 2000 12:21:49 -0800 (PST)</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> 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#kanga,nu <A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00754" HREF="msg00754.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></STRONG> <UL><LI><EM>From:</EM> Marian Griffith <gryphon#iaehv,nl></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00809.html">RE: [MUD-Dev] Richard Garriot's 'X' project</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00811.html">Re: [MUD-Dev] Richard Garriot's 'X' project</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00793.html">RE: [MUD-Dev] Object and class hierarchies -- are they really necessary?</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00765.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00810"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00810"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00786" HREF="msg00786.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Wed 29 Mar 2000, 04:20 GMT </LI> <LI><strong><A NAME="00791" HREF="msg00791.html">Re: [MUD-Dev] Object and class heirarchies -- are they reallynecessary?</A></strong>, adam <a href="mailto:adam#treyarch,com">adam#treyarch,com</a>, Thu 30 Mar 2000, 04:00 GMT </LI> </ul> <LI><strong><A NAME="00785" HREF="msg00785.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Kevin Littlejohn <a href="mailto:darius#connect,com.au">darius#connect,com.au</a>, Wed 29 Mar 2000, 03:39 GMT </LI> <LI><strong><A NAME="00793" HREF="msg00793.html">RE: [MUD-Dev] Object and class hierarchies -- are they really necessary?</A></strong>, Christopher Allen <a href="mailto:ChristopherA#Skotos,net">ChristopherA#Skotos,net</a>, Thu 30 Mar 2000, 04:00 GMT </LI> </ul> </ul> <LI><strong><A NAME="00810" HREF="msg00810.html">[MUD-Dev] Debugging techniques</A></strong>, adam <a href="mailto:adam#treyarch,com">adam#treyarch,com</a>, Fri 31 Mar 2000, 20:57 GMT </LI> </ul> <LI><strong><A NAME="00765" HREF="msg00765.html">Re: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Phillip Lenhardt <a href="mailto:philen#funky,monkey.org">philen#funky,monkey.org</a>, Tue 28 Mar 2000, 21:34 GMT </LI> </ul> </ul> <LI><strong><A NAME="00677" HREF="msg00677.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Dr Richard A. Bartle <a href="mailto:richard#mud,co.uk">richard#mud,co.uk</a>, Tue 21 Mar 2000, 21:45 GMT </LI> <LI><strong><A NAME="00682" HREF="msg00682.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Wed 22 Mar 2000, 00:25 GMT <UL> <LI><strong><A NAME="00685" HREF="msg00685.html">RE: [MUD-Dev] Object and class heirarchies -- are they really necessary?</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 22 Mar 2000, 01:59 GMT </LI> </UL> </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>