Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!newsfeed.fast.net!uunet!dca.uu.net!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: Multi-player IF (was Re: AI in IF)
Message-ID: <GJFr7C.FzE@world.std.com>
Date: Mon, 10 Sep 2001 07:23:35 GMT
References: <7d26d66b.0109030448.59339a1a@posting.google.com> <tpo1rm6remoq36@corp.supernews.com> <GJF98p.1BI@world.std.com> <tpo5cjqltsha85@corp.supernews.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 85
Xref: news.duke.edu rec.arts.int-fiction:92422

David A. Cornelson <dcornelson@placet.com> wrote:
>Sean Barrett wrote:
[use MUDs]
>> The technology is not the problem.
>> The game design is the problem.
>I'm an author and game designer. I think attempting to code a mud to do
>multiIF has certain technnological aspects that make it an attractive
>choice, but in reality, would never fly as a valid multi-player-IF
>technology. If it did, we would have likely adopted it for that purpose
>already. Muds have been around for a long time. No one to date has submitted
>a game to the annual comp, or any IF comp that I know of, that is played via
>mud server.

Technically, nothing in my post literally advocated using a
programmable MUD for this situation--although I certainly
think that's a viable technique; my point is that we keep
rehashing these technological "issues" and nobody ever
confronts the game design issues, and I think that's just
going down a similar path as "I want to write an adventure
but I have no clue what game I want to do so I'll start
by writing a new IF development system"...

But to respond to your point as if I had so advocated them:
The fact that nobody has submitted a MUD-based multi-player IF game
to the comp is probably because it wouldn't play well as a comp game
where everyone has to judge it independently.

The fact that nobody's released a multi-player IF-ish game *period*
using a MUD technology implies that either there's little interest
in writing a MUD-based multi-player IF game, or it's really hard to
write one.

Since I'd argue it's really hard to write a multi-player IF game
*period*, independent of technology, your "if it did" evidence
works just as well for me as it does for you. It's not a disproof
of the technology; it proves that even if you have the technology
in hand, the design problem is a doozy.

>I think technology is exactly the problem. The underlying system doesn't
>necessarily matter, but the interface, or language to author a game on top
>of _whatever_ technology has to match almost identically, the
>systems/languages we already use. So either TADS, Hugo, or Inform would need
>to be the language that was used to create the multip-player-IF game code.
>
>If I have to hop into a c++ compiler to write multi-player-IF and worry
>about pointers and crap, it simply ain't going to happen. I suspect many
>other IF authors are similarly disinterested in c++ interfaces to muds or
>other technologies.

All well and good, but if I were advocating using a mud, I'd be advocating
a programmable mud--as I said:

>>Please let's not spend lots of time focusing on the
>>technology problems; they're pretty effectively solved
>>on any of the programmable MUD systems out there

Inform and WinFrotz are both written in C, but Inform games
are not. When I say "programmable MUDs", I'm referring to
a similar class of MUD systems--systems which provide an
interpreted programming language with adventure-oriented OO,
Tads-like no-pointers, full polymorphism, garbage collection,
etc. And, unlike Inform, Tads, and Hugo, all of them already
provide a multiplayer world model.

I can name five such systems off the top of my head, seeing
as I co-administered a MUD using one for four years, I wrote
another one myself, I consulted on the design of a third,
I wrote a pre-compiler for a fourth, and I beta-tested a
fifth.

See http://www.ccs.neu.edu/home/dougo/mud/ and look at
LPC, MOO, and COOLMUD, (those are the three on that page I have
some familiarity with); I'm not sure how many of the other
things there are both muds and programmable. Others that were
relatively well-known in the past included TinyMUCK and Ubermud.

If somebody wants to go hack sockets into Inform and make
a great multiplayer IF game, let them at it. But can't we
skip the discussions of "how do we keep the machines in
synch" and "how do we show other players what's going on
correctly" when those sorts of problems have been adequately
solved at least ten times already by MUD-system authors?
They are not the hard part of the problem, IMNAAHO.

SeanB
