Introduction to &dgd;</> <SECT1> <TITLE>What is &dgd;?</> <PARA>&dgd; is an &lpc; driver. In brief, this means that it provides facilities that allow people to execute &lpc; code, much in the same way that a Java virtual machine provides facilities for the execution of Java. &dgd; also provides people with the ability to connect to it, most often to some sort of virtual environment built with objects written in &lpc;.</> </> <SECT1> <TITLE>What does &dgd; stand for?</> <PARA>&dgd; stands for Dworkin's Generic Driver, being named after its author and developer -- Dworkin (Felix Croes). This originally was Dworkin's Game Driver but was changed (at the suggestion of Robert Leslie, author of LPMOO).</> </> <SECT1> <TITLE>What makes &dgd; different?</> <PARA>&dgd; differs firstly in that it wasn't derived from a version of Lars Pensjö's original &lpc; driver. It is a complete rewrite of the driver by Dworkin from the ground up. In this way it has managed to get rid of a lot of <EMPHASIS role="italic">baggage</> and legacy code which other &lpc; drivers still possess to some degree.</> <PARA>Another important difference is that &dgd;'s default set up is to be disk based rather than memory based, unlike other &lpc; drivers. This means you can load a huge number of &lpc; objects without &dgd; taking up a lot of memory.</> <PARA>&dgd; also possesses (at driver level) the ability to perform a state dump, that is, to <emphasis role="italic">dump</> the state of all loaded objects to a file and restart the driver with them exactly as they were (with the exception of active <acronym>TCP</> connections being closed during this process).</> <PARA>Finally, &dgd; allows changes in object &lpc; code to be realised in already existing objects by recompiling in situ, rather than having to destruct, recompile and then recreate the object. In this functionality &dgd; moves away from traditional &lpc; driver practice towards persistent database backed drivers such as <ULINK url="http://web.cold.org/">Cold</> and <ULINK url="http://www.moo.mud.org/"><acronym>MOO</></>.</> </> <SECT1> <TITLE>What can I do with &dgd;?</> <PARA>Pretty much anything. The most common application for &dgd; is still running muds, but there is no reason why it couldn't be used (with appropriate &lpc; objects) as a httpd for example. &dgd; itself contains nothing specific to any application, only certain kernel functions (kfuns) which Dworkin felt necessary to &lpc; object coding, compiling and management, and multiple connections.</> <PARA>This minimalistic philosophy and lack of application specific code allow you to create any look and feel you choose through building around basics written into the <LINK linkend="qanda-auto">auto</> and <LINK linkend="qanda-driver">driver objects</>. A classic example of making &dgd; appear to be something other than an LPMud using this methodology is the <LINK linkend="mudlibs-lpmoo">LPMOO simulation</> by Robert Leslie.</> </> </>