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

[Jon Leonard]

On Wed, Jan 07, 2004 at 02:52:37PM -0600, Peter Seebach wrote:
> In message <mailman.69.1073508367.371.mud-dev at kanga.nu>,
> mud-dev-request at kanga.nu writes:

>> Welcome to the MUD-Dev at kanga.nu mailing list!

> And a hearty welcome to you to, Mr. List Robot.  :)

And a welcome from some of the human readers, too!

> I don't know if this list does intro posts, so I'm pretending this
> is NEWS TECH.

> Hi!  I am a programmer who has taken to writing for a living; as
> such, I have a programming-project-shaped gap in my life.  I am
> considering trying to write a mud driver.

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

It's a fun one, though.

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

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.

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

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

> Why do I think I can do this?

I'm sure you can.  A MUD server isn't that huge a project, at least
until you start adding the game content part.

>   1.  I have written two or three "toy programming languages",
>   which is a good background for trying to implement a
>   programmable mud.

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

>   2.  I have experience with a broad variety of languages, most
>   relevantly Inform, which is a language custom-designed for
>   writing text adventures - and which gives a lot of good insights
>   into what kinds of language features are useful for expressing
>   those kinds of stories.

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.

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

>   4.  I've been playing various muds since AberMud 2, and I feel I
>   have a reasonable sense of what kinds of features they want, and
>   what kinds of mistakes they tend to make.

Very useful experience!

>   5.  I am insufferably arrogant, and I think I can do anything.

Who am I to disagree?

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

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