[DGD] My first release

Shentino shentino at gmail.com
Mon Dec 18 21:30:33 CET 2006


Basically, I'm exposing the nuts and bolts of objectness.  I'm trying
to strike a happy medium between flexible and bulletproof.

For instance, I have a catchall property registry where you can
specify the names, permitted types, and inheritance schemes for any
number of properties.

This allows you to define, *at runtime*, what constitutes a legal type
for a property, and even have it automatically inherit defaults from
ancestors.  Almost as good as hard coding it, but you can change it at
runtime.

Generally though, I provide a toolbox of parts and daemons and let the
end user or mudlib developer decide how to put them together.  I'm not
rigid at all.  The design is modular too...I really am not fond of
huge source files.

In my second AUTO object, I also include some safety checks that
forbid the following, and generate decent errors:

* using call_other from a destructed object
* deleting the source file for an object that still exists (with a
cute "Text file busy" error)
* calling an undefined function with call_other

I also have ObjectD log the creation, destruction, and compilation of
every object.  By doing this, and also writing a custom processor in
AWK, I was able to write a clone log checker that showed you exactly
which objects were outstanding.  This makes it easy to clean up object
leaks.

I also decided to split up my object class in Common into dec and def
files (next release will separate variables).  I find that, given the
huge mass of code that supports "object", it helps to keep things
neat.


As for the game objects themselves (swords, wolves, and whatnot),
they're supposed to be arranged in a strict hierarchy...with every
object being contained either by another object, or by an unclonable
root.

I'll need to make a few changes, so don't bother saving any statedumps yet. :P



As far as who would make the best use of it...well, whoever it is
should have creativity, and be comfortable with a lack of systemic
structure.



More information about the DGD mailing list