[MUD-Dev] Re: Bruce Sterling on Virtual Community goals

Jon Leonard jleonard at divcom.slimy.com
Mon Oct 19 23:14:23 New Zealand Daylight Time 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 mailing list