DGD

'DGD (Dworkin's Game Driver aka Dworkin's Generic Driver)' is an object-oriented programmable MUD engine which is primarily used together with a mudlib to host online roleplaying games.
Although it is classed within the LPMud family, the DGD driver was written from the ground up and is not really a direct descendant from LPMud. Dworkin, the author, enforced a rather bare bones approach to the construction of the Driver, as it never was meant to only be a MUD driver (hence the 'generic' part of the name). Unfortunately, the lack of decent mudlibs has retarded its use.

Contents

Powerful Features

Statedumps

: 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.

External links

Powerful 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 anyway 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.
DGD has the following MUDlibs:

★ Phantasmal can be found at phantasmal.sourceforge.net

★ Skotos 2.0 created by Skotos Tech

★ Melville

★ 2.4.5

★ Gurba

★ LPMOO

External links

★ Dworkin's Game Driver

★ Noah Gibb's DGD Documentation