An Introduction To DGD
What is DGD?
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.
What does DGD stand for?
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).
What makes DGD different?
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 baggage and legacy code which other LPC drivers still possess to some degree.
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.
DGD also possesses (at driver level) the ability to perform a state dump, that is, to 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 TCP connections being closed during this process).
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 Cold
What can I do with DGD?
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.
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 auto and driver objects. A classic example of making DGD appear to be something other than an LPMud using this methodology is the LPMOO simulation by Robert Leslie.
- 20 Jan 2005