From: d8andjo@dtek.chalmers.se (Johan Andersson)
Newsgroups: rec.games.int-fiction
Subject: Re: Interactive Fiction and TinyGames
Date: 29 Sep 92 14:39:48 GMT
Distribution: rec.games.int-fiction
Organization: Chalmers University of Technology, Sweden
In-reply-to: goodridg@husc8.harvard.edu's message of 28 Sep 92 09:52:54 GMT

In article <1992Sep28.055255.15902@husc3.harvard.edu> goodridg@husc8.harvard.edu (Andrew Goodridge) writes:

> MUDs and their later derivatives were originally built to be, "Multi-User
> Dungeons", adventure games that several people could play at once.

Right. MUDs are logical followers of the single user text adventures in a
networked environment.

> This ideal, this goal, on the whole, has failed miserably.

Not entirely correct.

> What they HAVE become
> are chat lines, conferencing setups, and social clubs.

Wrong. This is certainly not true for most LP, DIKU or Aber muds.

> It matters to me because I run one of the longest-running TinyGames,

TinyGames are a subset of the MUDs available and (in)famous for being
social chatlines more than adventures. I help in running the original LPmud,
called Genesis and it is not a social club. Do not make generalizations that
are not valid. 

> I'm not asking for an indepth discussion on MUSH or MUCK or MUSE programming
> code, but of the IDEAS and CONCEPTS one comes up with when one has the 
> ability to have several people play a game at once,

I think such a discussion is actually valid within the scope of this group
and not one of the rec.games.mud* groups. Please correct me if I'm wrong.

The reason modern MUDs are not up to the standards of the Infocom games is
that the programmers at Infocom were obviosly better programmers than the
entire Internet mudcrowd.

It should be said though that coding a game of interactive fiction, in 
which many _independant_ players can play at the same time, is a much
tougher problem than implementing the state machines of the old Zork games.

THE fundamental problem is that of game time. In a single user game,
time can jump, i.e. 'sleep -> You sleep two hours, you awake'.

This is simply not possible in a multi, independant, user setting. The
only possible timesystem is in fact realtime. The compromises this forces
in realism to make the game playable is significant. A simple example is
movement, crossing a huge field ought to take time, but forcing the
player to wait in realtime is rather bad for playability.

Another problem is that of parsing. A modern mud is extendible, some in
a very flexible manner. It is often extended by 100++ people working more
or less independant. The old solution with a centralized parser simply does
not work in such a setting. This is one reason why MUDs does not have
parsers as elegant as Infocoms.

The modern extendible MUDs are not more than three years old and they are
rapidly evolving. In one or two years time they will have surpassed the
old text adventures, but by then they might be moving into the field of
virtual worlds and virtual reality just as the adventures got graphical
interfaces. 

/Johan
--
Johan Andersson           | "You don`t have conversations with microprocessors
Chalmers, Sweden          | you tell them what to do, and then you helplessly
Email:                    | watch the disaster when they take you literally."
d8andjo@dtek.chalmers.se  |	Sah`ot in David Brins "Startide Rising"