[MUD-Dev] Object Architecture [Longish]

[David B. Held]

From: "Draymoor a Vin il'Rogina" <draymoor at cloud9.net>

> I'm going with a largely OOP approach to my mud. C++ with windows
> c-style multithreading, c-style function pointers (I'm looking for
> a better way, though), and Windows SDK Winsock 2.

You should really check out www.boost.org.  In particular, the
boost::function library is extremely flexible, and essentially
offers closures in C++.  You can create pointer-to-function,
pointer-to-member-function, functors, and basically any callable
entity with it.

> One of my main goals in my implementation is to isolate the usage
> of pointers as much as possible to within the basic classes that
> have to work with them to avoid null pointer crashes.

You also should check out the boost::smart_ptr library.  It has
checked dereference, to help you catch null pointer access, and will
handle resource deallocation for you (assuming no cycles, of
course...but then, there is a cyclic_ptr in the file archives, if
you know you will produce cycles).  I have been porting
Loki::SmartPtr to Boost, which is a policy- based smart pointer
designed by Andrei Alexandrescu.  It is both more complicated and
lighter-weight than the current Boost smart pointers.  For now,
though you should use boost::shared_ptr and boost::intrusive_ptr
(you might need to get them from CVS, as intrusive_ptr was added
recently, and probably not to the latest release).

>       NSMLParser - Nirvana Standard Markup Language, rather than
>       learning XML, I decided to make my own. I recognise this as
>       a mistake ;)

Not necessarily.  If it's sufficiently like XML, that's really the
important thing, IMO.  I invented my own XML-like language, and it
works just fine for my needs.  The key, however, is writing the
parser.  I use Spirit++ (spirit.sourceforge.net), which is an
awesome C++ parser generator that is truly a revolution in library
design.  The power and elegance make it a joy to use, but being a
template-heavy library, you *will* wait on compile times. ;)
Hopefully, the next generation of compilers will be aware of the
increasing use of template technology, and optimize template
compilation speeds (many compilers use naive algorithms for dealing
with templates...there is much room for improvement).

> I have not yet started the actual world code. I'm trying to figure
> out how to handle the NSML currently. Any comments/input here
> would be appreciated.  Especially criticism :)

I hope my criticism is helpful, but one thing that bothers me is how
many of us are working on similar projects.  Correct me if I'm
wrong, but it seems there are at least a few of us that are working
on a MUD that is:

    * written in C++
    * uses persistence in the form of XML or a DB
    * roomless system
    * event queueing
    * departure from Diku (level-less, class-less, whatever)
    * greater realism (read: more simulation?)

And it seems the only reason we are all working on it individually,
is so that we have complete control over our "vision" of how things
ought to be. ;) Maybe we should consider not inventing the next
wheel three or four times, and maybe just do it once.  Or maybe it
is the subtle differences that are too great to allow collaboration.

Dave


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev