[MUD-Dev] Re: Bruce Sterling on Virtual Community goals
Jon Leonard
jleonard at divcom.slimy.com
Mon Oct 19 18:22:01 CEST 1998
On Mon, Oct 19, 1998 at 05:37:55PM -0600, Chris Gray wrote:
> [Jon Leonard:]
>
> >Even if there isn't interest, figuring out a base feature set would be
> >useful, and I'd extract parts of my own server to match. (I have a fully
> >RFC compliant telnet server, which I could disentangle from the rest of my
> >code, for example.)
>
> Hmm. That's just what I'm working on now. Stole the code from earlier
> stuff. Do you handle all of the RFC's, including things like LINEMODE?
> I was planning on cleaning up my stuff when done and offering it as an
> example of telnet handling. Two examples are likely better than one!
The RFC allows a compliant implementation to respond "No, I don't do that."
to options it doesn't feel like supporting. I used this freedom a lot.
The version I have properly keeps track of who is responsible for echoing
characters, and declines to do anything with the other options. I rely
on line-mode being the default in local echo, and my server makes no
attempt to use character mode (I do use server echo for password entry).
> >If there isn't a clear idea of what would be a useful base to extend on,
> >that says something very interesting about the future of MUD design.
>
> Perhaps that a lot of those writing servers from scratch are doing it
> mostly for fun? Either that or are doing commercial projects where the
> use of outside code might present legal problems?
> :-)
The for fun aspect I'll certainly buy.
Legal aspects of reusing code definitely contributed to my starting over
from scratch. That's why I recommend a very flexible license for such
code. I put my MUD socket example code in the public domain for a reason.
(Yes, I really don't mind if people take that chunk of code and strip my
name off of it, etc.)
I'm envisioning stuff where the only reasons not to use it are:
1) It's not doing what you want.
2) Starting from scratch is more fun.
3) You already have something better for your purposes.
I don't think there's an available MUD server like that yet.
> I'd be game to do an in-MUD programming language component, but I betcha
> few people would like the language (mostly strongly typed, syntax not
> at all like C, etc.)
My Lisp-like language would probably be as unpopular as your language.
I think a better approach would be to figure out what kind of primitives
a language might need from the rest of the server. That lets us have
several different languages (possibly simultaneously), as tastes will
vary.
I don't think a single monolithic server would be flexible enough for
what most of us are interested in. I'd build a mix and match collection
of components for things like internal language. Some successful MUDs
don't have internal languages at all, and that's a model we should support
too.
Jon Leonard
More information about the mud-dev-archive
mailing list