@@TITLE Supplementary Documentation@@

<h3>DGD Documentation</h3>

<p>Of course, you've already read the DGD documentation which comes
in "dgd/doc" (<i>haven't</i> you?), but just in case I'll do a
little overview.</p>

<ul>
  <li>Commercial: this file tells you about using DGD commercially.
  This is important only if you ever plan to make money off a DGD
  MUD. <a href="../Skotos/CommercialUse.html">Making money off a
  DGD server</a> is involved and requires licensing. However,
  making money off most flavors of LPMUD is forbidden entirely by
  the license, so this is more generous of Dworkin than you think.
  The exceptions are the GPL'd servers, pike and Shattered World.
  Neither is quite the same language as DGD, but either could be
  worth looking into.</li>

  <li>Extensions: this tells you how to modify DGD itself in some
  specific, pretty clean ways. Don't do this until you have a good
  grasp of everything you'll need for a MUDLib. Even then, you'll
  want to be on the mailing list since this stuff isn't guaranteed
  to work right and operates very differently than you might
  think.</li>

  <li>Introduction: an excellent introduction to the interface
  between DGD and any given MUDLib. This is an excellent
  programmer's introduction to what a driver and an auto object
  are, and how DGD uses them. As Par Winzell so eloquently
  describes this file: <i>Dworkin's documentation is like a good
  novel or classical textbooks: they are so dense with information
  that even after multiple readings and a high degree of
  proficiency with the system, a fresh read-through will yield new
  insights.</i></li>

  <li>Platforms: getting DGD compiled in the first place. You've
  already done that, right?</li>

  <li>editor: help on using DGD's built-in editor. You'll
  eventually want a better editing solution, but not necessarily
  coded into DGD or your MUDLib. In general, getting your editor
  entirely on the client side is best, building it into your MUDLib
  is next-best, and building it directly into DGD is worst. Feel
  free to ask Dworkin about this on the newsgroup, or just read
  through the archives and discover his opinions for yourself.</li>

  <li>parser: help on using DGD's built in parse_string facility.
  It's neat, it'll do good things, but it's not really relevant to
  a just-getting-started MUDLib. It'll let you build fine features
  later, but first you'll need to get stuff up and running.</li>

  <li>The kfun directory: up-to-date documentation on DGD's
  interface (via the auto object) to your program. This is roughly
  the same as documentation on OS system calls. Your MUDLib's auto
  object can override any, all or none of them.</li>

  <li>There's an LPC.html file with a <i>very</i> brief summary and
  no real information yet. It may be finished some day, but if you
  see nothing of use there, it's not a bad download. It's just that
  the file contains very little.</li>
</ul>

<p>Other good places to look are the Kernel Library code for simple
examples and interfaces, and of course <a href=
"http://phantasmal.sf.net">this web site</a>. You can read through
existing libraries like Phantasmal and Melville if you need more
examples of how to do things. Note that Phantasmal uses the Kernel,
while Melville does not.</p>