[MUD-Dev] NEWS TECH: Re: Welcome to the "MUD-Dev" mailing list

[Peter Seebach]

In message <20040108091522.GB23740 at slimy.com>, Jon Leonard writes:

>>   1.  I want a driver that is as game-generic as possible.  I do
>>   not want to impose concepts more specific than "players who
>>   interact with a game" on potential users.

> In practice, it helps a great deal to specify the goal a little
> bit more.  Some MUDs are essentially social, free-building spaces.
> Some are more of a traditional game, in terms of advancement or
> inter-player conflict.

> In the former, you can ignore play balance issue and concentrate
> on the quality of the building tools.  In the latter, the tools
> are sharply restricted in order to make play balance possible.
> I'm not sure that it's even possible to write a system to do both
> simultaneously.

> Depending on your plan for clients, you may want to add some
> hardcoded support.

I am looking a little more closely at advancement, but one of the
things I want to be able to do is write text adventures on it, even
though those aren't at all multi-user.

I certainly intend to have enough security in the game that players
can be prevented from touching stuff.

>>   2.  I want to make reasonable use of existing tools; for
>>   instance, if I stick with C as my implementation language, I'll
>>   use pthreads, stdio, and other likely tools, rather than
>>   hand-coding my own scheduler and buffering.

> Reuse is good!  Though in practice I'd avoid pthreads (since
> thread-per-connection works suprisingly poorly), and use
> read/write on sockets instead of wrapping them in stdio.  But
> those choices are certainly doable.

Well, I reserve the right to change my mind about a thread per
connection; I might switch to, say, a thread which handles all the
I/O, and does the traditional select() dance.

As to stdio, my initial thinking is just that I probably can't
improve on the buffering work that stdio already has.  If I use
stdio, it all magically works, and I don't need to do any of it.  ;)

>>   3.  The resulting mud will be released under a very
>>   non-restrictive license.  I am a programmer, not a lawyer, and
>>   I am not going to write my own license; I am currently leaning
>>   towards Artistic.

> Sounds good.  The history on Diku and LPmud licensing has
> certainly led to a lot of headaches.

Exactly my feeling.  Most mud developers are worse lawyers than they
are programmers.

> Very much so.  Extending one of those languages to support some
> persistent storage and network sockets my be your best course of
> action.

Well, I called them "toy" languages for a reason.

> This may be less useful than you'd hope, since the nature of
> storytelling changes with the number of simultaneously-involved
> players.  With 2, the system needs to be aware of real-time
> issues.  With more than about 10, keeping the players in some sort
> of cohesive group is also impractical.  But aside from the
> storytelling aspects, it should be applicable.

Well, in particular, I've learned that a language's syntax can be
AWFUL, and the language can still be worth having if it's
well-suited to the target.  That means that my language design will
be focused on making common mud-like tasks (make an object with a
description) as convenient as possible.

>>    3.  I know C, especially Unix-targeted C, well enough not to
>>    make all sorts of weird newbie mistakes.

> I'll still warn against thread-per-connection.  I can't think of
> any other common mistakes that are specific to the application.
> (and relevant at this level of design -- there are plenty of
> common game balance errors.)

As noted, it's easy enough to change later.

>>  I'm interested in learning more about the state of the art, and
>>  seeing what kinds of ideas people have.  I might well be
>>  persuaded that one of the existing mud-level languages, such as
>>  LPC, is the best option, but I am thinking seriously about
>>  trying to do a language targeted specifically at muds.

> You'll probably want to look at both the LPC servers and Cold with
> an eye to what you'd do differently (and why).

Yeah, that's been about my thinking.  I looked at LambdaMOO, and the
obvious first thing I want to do differently is that I want
everything's source to be in files I can get at through the
filesystem.

I am currently playing around with the trivial syntax questions of
what declarations look like.  This is something I think will make a
big difference in practical usability.

I am currently leaning towards using directories for namespace, with
something similar to Java's "import" statements to allow the use of
shorter names.

I've decided to give every builtin *anything* a _ prefix.  This is a
little annoying, but it gives a nice promise to users: You can name
object members/properties, or functions, whatever you want, and
never, ever, clash with the system.

Little snippets of example code, just because this is how I like to
first toy with a language:

  squid </standard/food> {
    name "a squid";
    food_value 23;
  }

  variablesquid </standard/food> {
    name "a squid";
    food_value {
      if (condition) {
        return 23;
      } else {
        return 17;
      }
    }
  }

  squidshop </standard/room> {
    contents [ <#squid>, <#variablesquid> ];
    description "You are in a squid shop.";
    east {
      if (obj_in_array(<#squid>, self)) {
        return "No one leaves while there's still a squid.";
      }
      return </world/city/mainstreet#west>;
    }
  }

Note that quoted strings, numbers, and {code blocks} are all just
object values.

The astute reader may recognize a structure similar to Inform's
"with" clause here, only without the incredibly ugly comma/semicolon
syntax.

Note the gratuitous use of URL-style file/#object references.

-s
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev