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

[Lars Duening]

On Jan 7, 2004, at 1:52 PM, Peter Seebach wrote:

> I am aware that this is not exactly an unusual hobby idea.

But as Jan said: it's a fun one, where one gets to write real code
(as opposed to boring business data massaging).

> My interests:

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

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?

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.

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

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.

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

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.

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

The Lima guys later then tried to simplify Mud development again by
introducing LPCscript - a simplified way of describing the mud's
objects (on a level similar to the examples you gave), but geared
specifically towards the Lima mud and implemented through code
written in LPC.

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

Cheers,
   Lars
--
Lars Duening; lars at bearnip.com
GPG Key: http://www.bearnip.com/lars/lars-duening.gpgkey
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev