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