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

[Peter Seebach]

In message <CC2ED80B-4577-11D8-A8F5-0003938094E8 at bearnip.com>, Lars
Duening wri tes:

>>   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.

> Having a game-generic driver is a good idea, but you still have to
> specify it a bit more. Will it support text-games? Text and some
> graphics? Whatever the mud-implementor wants? Is the driver going
> to implement game mechanics?

I'm probably leaning towards text, but I suppose someone could
implement curses-like stuff.  Graphics are outside the scope of my
design.  My plan is to explicitly exclude game mechanics from the
driver.

> Is the intermediate language going to be compiled into bytecode
> and then interpreted, or (via C) into machine code? Can the game
> objects be modified at runtime, and if yes, by whom with what
> level of expertise?

I expect to do bytecode and interpret, and yes, runtime
modification.

> One thing I have noticed over the last years of working on LDMud
> is that the demands of the Mud implementors require more and more
> a generic scripting language with a few Mud-specific constructs,
> than the other way around. If I had the time to implement
> everything my users are wishing for, I'd end up with the
> equivalent of Python (Perl, Ruby, pick your poison) with LPC
> syntax and a MUD module.

It depends, I think, a lot on what you're doing.  I'm leaning in the
direction of a language with some of the feel of Inform; I find that
language incredibly convenient for expressing the kinds of things I
want to do in muds.

> Of course! Threads are overrated though - they make life a bit
> easier if you want to have the communications module run
> asynchronously from the main game engine, but having, for example,
> a separate thread for each player won't buy you much (feel free to
> prove me wrong!). And they are a pain to port across platforms.

I think you're probably right... but I have absolutely *no* interest
in non-Unix platforms.  I have my limits.  :)

> I'd go for the two- or three-clause BSD license - to the point and
> easy to understand. After all, it's just a mud driver.

Either that or Artistic is fine by me.

>>  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.

> IIRC LPC started out as improvement over the languages targeted
> specifically at muds, as the latter put too many restrictions on
> what could be done (dynamic descriptions come to mind).

Well, my idea is to do a properly complete and flexible language,
but to give it syntax that's a little friendlier to mud writers.

> ...hmm, having a driver support both levels of language complexity
> might actually be a useful thing...

Indeed.  Well, that's what I like about inform:

  Object "a paperclip"
    with  description "It's just a regular paperclip."
    ;

  Object "a complicated paperclip"
    with  times_described 0;
    description [i;
      print "You've looked at this... [narrator pauses,
             counts...] ";
      for (i = 0: i < self.times_described: ++i) {
        print i, " ";
      }
      print "times. Are you bored yet?^";
      self.times_described++;
      rtrue;
    ]
    ;

As complicated or as simple as you want.  I like this; it is for
stealing.  Functions, strings, whatever; it's all just objects, and
a property can be any kind of object.

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