[MUD-Dev] Re: Bruce Sterling on Virtual Community goals
Jon Leonard
jleonard at divcom.slimy.com
Mon Oct 19 23:14:23 CEST 1998
[> > = me, Jon Leonard]
On Mon, Oct 19, 1998 at 10:50:45PM -0600, Chris Gray wrote:
> >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.
>
> Nod. An important one for me was NAWS (Negotiate About Window Size), which
> lets the server know how big the window of the client is. I also did
> BINARY, SUPGA and ENDOFRECORD because they are pretty trivial. Also the
> IAC stuff for escaped things.
Sounds like your implementation is a lot more feature complete than mine.
Mine just didn't break the rules. I'll make it available as an example
anyway. As you pointed out, two examples doesn't hurt anything.
> >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.
>
> So, you're thinking it could have either some hard-coded scenario
> stuff, or could have it soft-coded in an internal MUD language? I guess
> that's do-able. Haven't most systems that started out without an
> in-MUD language eventually added one, just to gain the flexibility?
Yeah, that's what I'm thinking. Maybe everyone will wind up with an
in-MUD language, but if this is a learning/expirimental tool, it'd be
worth showing why that can be the right way to go, and what is lost
in terms of simplicity by doing that.
I think there's also a lot of room for tradeoffs in terms of what gets
hardcoded and what gets softcoded. (Gcc is a MUD! Some softcoding
required.) A hardcode implementation that kept track of rooms, objects
in rooms, and so forth would be good to poke at, but it sacrifices
flexibility.
Jon Leonard
More information about the mud-dev-archive
mailing list