Dworkin's Game Driver


DGD, Dworkin's Game Driver, is an LPMud server written by Felix A. "Dworkin" Croes. DGD pioneered important technical innovations in MUDs, particularly disk-based object storage, full world persistence, separation of concerns between driver and mudlib, runtime morphism, automatic garbage collection, lightweight objects and LPC-to-C compilation.

History

DGD's first public release was on August 12, 1993.
The first publicly available MUD to use DGD was PaderMUD, in December 1993.
The original primary development MUD for DGD was The Pattern, referencing The Chronicles of Amber. It was taken offline sometime before February 1997.
During the 1994-1995 academic year, DGD was a core element in a master's thesis at the Katholieke Universiteit Leuven. As part of the thesis work, a deterministic mechanism for handling arrays and mappings passed between objects was devised.
In December 1995, exclusive rights to commercial use of DGD were acquired by BeeHive Internet Technologies, Inc., which sold an exclusive license to ichat in January 1996. ichat used DGD to establish the first Yahoo! chatrooms. ichat then became Acuity Corporation, which sold a sublicense to Skotos in February 1999. Skotos used DGD to create a series of online games. Acuity Corporation was later acquired by Quintus Corporation. In March 2001, the exclusive license was terminated due to the bankruptcy of that company.
In 2002, DGD was used for academic research into persistent distributed object systems.
In August 2005, DGD's commercial use rights were assigned back to Dworkin B.V., Croes's company.
On February 3, 2010, DGD 1.4 was released as open-source software.

Features

Unlike other LPMud drivers, DGD has many powerful features specific to it that make it stand out as a game driver. These feature include persistence, Dynamic Recompilation, and statedumps, which allows a fully persistent system—no reboots and no reset system. A never-ending game world could be created.

Persistence

DGD supports persistence as a driver feature in ways that many languages simply can't. Using Dynamic Recompilation, coders never have to save objects to disk, reboot or recompile the logic for the objects, and then reload the objects from disk. Because DGD is also disk-based it can be persistent by swapping much of its unused memory to disk. Persistence is powerful and allows for behavior not experienced in most games. Some possibilities include...
Not destroying objects left on the ground
Not ever destroying NPC's nor randomly creating them en masse with zone resets
State is not lost on reboot, except for the connection state of the player.

Statedumps

Statedumps are dumps of the state, or memory, to the hard disk, similar to how a computer dumps its memory to hard disk when it goes into hibernation. The driver can start from a statedump and have the game be exactly in the same state it was before reboot, minus network connections. This is why it is possible to reboot and easily maintain persistence of the way things were before the reboot. It also allows for a concept called virtual uptime, where while the game is actually down but when it comes back up it is still the same as it was before. This virtual uptime means the game has never reset itself in any way and all changes are persistent between real downtime.

Dynamic Recompilation

The dynamic recompilation feature allows one to recompile the logic of a master object during runtime, automatically upgrading all instances to the new version. Inherited objects cannot be recompiled in this way, they must instead be destructed and then compiled again. This will leave inheriting objects referring to the old version of the object, so they must in their turn either be recompiled, if possible, or destructed and compiled again in order to refer to the new version. Because of the restriction against recompiling inherited objects, it makes sense to separate inheritable objects from others, which is also done by the DGD Kernel Library.
The recompilation mechanism is essential for persistent but evolving systems. Combined with statedumps, a reboot would only be necessary to update the driver and would probably be a transparent change to admins and users alike.

Disk-based Transparent Swapping

The DGD driver transparently swaps all the objects in memory to disk based on parameters that can be tuned by the admin of the game. The disk-based nature of the game allows one to never have to write code to load or save objects to and from the disk by oneself. The most commonly used objects are generally kept in memory to negate any non-trivial swapping cost and things are put to disk automatically based on when they were last accessed. This is also a powerful feature because it doesn't make the coders of the game responsible for what is in memory, which can dominate a lot of development time for any game programmer.

Mudlib support

s available for DGD include: