[DGD] Could it work...
mtaylor
mtaylor at ntlworld.com
Mon Sep 17 02:53:01 CEST 2001
Thanks everyone for the help and comments :)
Well we're going to keep going with it all. I'm sure with a bit of work
we'll manage to overcome the need for more technical coding. We've managed
so far without the kernel I'm sure we can keep going. Positive spirit and
all :)
I do understand that there's probably a lot of technical work ahead to try
and emulate some of what the kernel does. Can I summarise what I think I
should be doing and then you could perhaps let me know if I'm on the right
track.
We are writing what we hope will be a large, fantasy based mud. Currently
there are two coders (me and my girlfriend). In the future it is likely that
two or three main coders would join us. Of course there will be builders
too. However unlike some muds I've seen out there we intend to quality
control all new code (from builders) which hopefully will reduce the number
of potential crashes. We don't really need much file handling because coding
will be done offline and uploaded to a test mud.
It seems the areas we need to work on are:
(1) Implementing r-limits. These need to be set on call-outs, receive
message, open and close.
Oh ... And I was wondering why you need to put them on open, close?
(2) Code for dumping the state and re-starting from a state dump.
I'm sure I've missed loads but I wasn't entirely sure why the kernel lib was
so important to use. The above does seem tricky but doesn't sound
impossible. With looking at the kernel I'm sure we can work it out seeing as
that's how we've coded the connection stuff etc. so far.
Or am I being dim?
Is it possible to have a decent mud running without using the kernel? What
do you think?
Anyway ... We're going to keep happily coding away ;) We should be only 2 -
3 months away from testing for the first time.
I do hope you'll all come and have a look when it's up :)
Matt
_________________________________________________________________
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list