[MUD-Dev] Re: DevMUD: Inheritable modules
Adam J. Thornton
adam at phoenix.Princeton.EDU
Fri Oct 30 13:40:44 CET 1998
I very much like the idea of doing the core of the server in ANSI C with
POSIX functions, and implementing (as a module, of course) an OO scripting
langage for actual world development on top of it.
That's mostly because I understand C a lot better than I do C++; this is
basically a personal aesthetic judgment on my part. However, I think the
core will tend to be smaller, cleaner, and easier to read if we stick with
C.
Then we have the problem of what belongs in the core. My candidates are:
Networking primitives (however, leave authentication et al at a higher
level, whether in C or the MUD language) (what I've done in the system I'm
working on is to have a per-connection value that represents what
crypto/authentication mechanism that connection uses, so that's really a
protocol design issue), and the notion of connection and thread-or-process.
I think there ought to be a one-to-one thread-to-connection mapping (there
may of course be non-connection oriented threads going on, but each
connection presumably requires its own thread, unless we want to make the
I/O model nonblocking, which I think will get unwieldy for large numbers of
players). Also message queues of some sort to handle the data that each
connection is transporting.
So basically the core (in my idea of it) would not do much except handle
connections, broker them, and multiplex/demultiplex the data going through
them. This is going to be kernel-like, so it's not really that important
to be able to dynamically load it or unload it--I can't imagine a MUD that
did not provide these services. And I think this bottom layer would be a
couple thousand lines of C: quite small.
Adam
--
adam at princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
More information about the mud-dev-archive
mailing list