Strings & Memory Usage
ashen
ashen at pixi.com
Wed Apr 16 08:05:44 CEST 1997
: On Apr 14, 8:07pm, Greg Munt wrote:
: My approach was to break the design into two parts
: (a lot like an LP, I suppose): kernel and lib. The kernel
: handles all the nitty-gritty, the stuff that no one creating
: their own mud should need to know the intricacies of,
: while they can build their own lib to suit. IMO, this prevents
: the tragic proliferation of stock-muds too, once a number of
: from-scratch servers are released.
perhaps some people _should_ know the nitty-gritties of what
is driving their lib. anyone who does has certainly 'created their
own mud', a little more so than we who just rewrite libs. the
'tragic proliferation of stock-muds' also is my goal to avoid :)
by way of introduction, btw: i am John Greenawalt, 22,
CS major, 5 years LP lib experience, little driver experience,
and working with Dan Armstrong on his latest project.
i believe the best muds to be those with their own unique libs,
and those with their own drivers better yet. the admin of such
a mud will undoubtedly be more mature and clear-cut in their
goals, simply for having put their own work into the mud, beyond
changing descs around from a stock base.
: I'm at the point where I'm considering being a rat bastard and
: not releasing anything (not selling it, but making it the only one
: in existance), but that could just be because I'm discouraged
good for you - what is most important to be sharing is design ideas,
IMHO, as long as i make sure no one helps me cheat myself by
_giving_ me a mud to configure.
: It's _way_ to easy to hack something up and then have to patch
: it and hack it all over the place to make it do what you want, whereas
: if you'd started with an actual design, some goals in mind when you
-john (ashen at pixi.com)
More information about the mud-dev-archive
mailing list