Multi-user Interactive Fiction
Mark Engelberg
compare with MUD programming languages like MOO, and wondering if
there isn't the possibility of creating a hybrid language. Consider
the following:
TADS and INFORM take advantage of the fact that all objects, verbs, etc.
are known at compile time. By prohibiting dynamic allocation of new
verbs and objects, an elegant, flexible parser can be built, and
rich text for all known possibilities can be written by the author.
All text messages are inherently designed to be printed out on the
screen of the single user "the ME character".
Languages like MOO are designed such that the database of verbs and objects
can be expanded at run-time from within the environment. This
allows players to create new characters, objects, etc. while playing.
Different messages are generated for each action -- one for the player
who caused the action, and one for all other witnesses.
The major disadvantage is that the parser must be lousy to accomodate
the run-time expandability. Essentially, the only constructs which
are acceptable are <verb> <noun> or <verb> <noun> <prep> <noun>.
What I envision is a language designed for Multi-user Interactive Fiction.
In other words, an author constructs a known environment, an elegant parser
is generated from the specified grammar, but then multiple participants
can participate in this planned interactive fiction simulataneously.
Comments?
--Mark Engelberg
Paul F. Snively
m...@gothamcity.jsc.nasa.gov (Mark Engelberg) writes:
> TADS and INFORM take advantage of the fact that all objects, verbs, etc.
> are known at compile time. By prohibiting dynamic allocation of new
> verbs and objects, an elegant, flexible parser can be built, and
> rich text for all known possibilities can be written by the author.
> All text messages are inherently designed to be printed out on the
> screen of the single user "the ME character".
>
> Languages like MOO are designed such that the database of verbs and objects
> can be expanded at run-time from within the environment. This
> allows players to create new characters, objects, etc. while playing.
> Different messages are generated for each action -- one for the player
> who caused the action, and one for all other witnesses.
> The major disadvantage is that the parser must be lousy to accomodate
> the run-time expandability. Essentially, the only constructs which
> are acceptable are <verb> <noun> or <verb> <noun> <prep> <noun>.
There's actually no correlation between a game being single-player and
having a good parser and being multiplayer and having a lousy parser.
The MUDs, MOOs, etc. were all derived from sources written by people
who didn't have natural language processing backgrounds, unlike, say,
the Infocom text adventures.
> What I envision is a language designed for Multi-user Interactive Fiction.
> In other words, an author constructs a known environment, an elegant parser
> is generated from the specified grammar, but then multiple participants
> can participate in this planned interactive fiction simulataneously
>
> Comments?
I'd like to go even farther and see the vocabulary extensible at
runtime. This shouldn't be all that difficult for anyone who is
willing to really put some thought into the English language. For
example, if you are going to add the word `can' to the vocabulary,
you'd have to remember that it can be a noun (`I bought a can of
peas.'), a verb (`Would you please can the tomatoes?'), or one of those
nifty verb-helper things whose name escapes me at the moment (`I can
hardly stand it.') You'd also need to know about any exceptional
spelling cases for things such as the past participle or future
perfect. Etc. etc. etc.
> --Mark Engelberg
-----------------------------------------------------------------------
Paul F. Snively "Just because you're paranoid, it doesn't mean
ch...@shell.portal.com that there's no one out to get you."
Gerry Kevin Wilson
:) You guys are gonna LOVE TADS 2.2. Believe me on this.
--
<~~~VERTIGO~~~~~~~~~~~~~~~~SPAG~~~~THIRD~ISSUE~DUE~OCT~26~~~~~~~~~~~~|~~~~~~~>
< The Society for the Preservation of Adventure games. Filled with | ~~\ >
< reviews, ratings, and advertisements...all about text adventures. | /~\ | >
<___SOFTWARE______E-MAIL...@uclink.berkeley.edu__|_\__/__>
john t baker
>[Discussion of things folks want to see in text adventure languages deleted.]
>
>:) You guys are gonna LOVE TADS 2.2. Believe me on this.
I already can't wait. I am, though, struggling to get my first game completed
before V2.2 comes out. If I don't get it done before, I'll probably be too
tempted to re-implement everything. :)
--
John Baker
"It ain't an easy life being a self-parody."
- John Baker
Gareth Rees
> TADS and INFORM take advantage of the fact that all objects, verbs,
> such that the database of verbs and objects can be expanded at
> run-time from within the environment. This allows players to create
> new characters, objects, etc. while playing.
I think you're confused. The new version of TADS allows for run-time
creation of objects, and while the limitations of the Z-machine prevent
Inform from doing this, there's no reason why you can't change the names
and properties of objects in response to the actions of the player (see
for example, "Balances").
Multi-player games (MUDs) have a number of game design difficulties
completely distinct from those encountered in single-player IF ('SPIF'),
and completely separate from any parser or implementation issues:
* The timing problem. In SPIF, it's appropriate for one action to
take several minutes of "game" time (go south) and another to take a
second or two (strike match). In MUDs, all the players have to be
running on the same timescale.
* The object problem. In SPIF, a puzzle will typically require
getting a few objects and then using them to persuade some area of
the game to go through a few states. In MUDs, how is player X to
get solve the problem when player Y has the object needed to solve
it? Do you duplicate objects? Or have object-less puzzles?
* The resetting problem. When you solve a problem in SPIF, it stays
solved; in MUDs you want the problem to be 'reset' so that it can be
solved by the next player. How to do this? Have thieves who run
round stealing the relevant objects and returning them to their
initial positions? What about the player who solved the puzzle the
first time? Won't they be annoyed when they come back and have to
solve it again?
Multi-player games tend to be multi-author games, too. I'm sure you
don't need me to describe the difficulties that can result when several
people (none of whom know what the others are doing) are allowed to
write general IF code.
These difficulties explain, I think, why MUDs have such a different feel
(action adventure or player interaction) to SPIF (puzzle- and narrative-
oriented). Writing MUDs that have the puzzle/narrative structure that
SPIF players are used to would involve a lot of effort on the game
designers' part. In particular, it would be folly to allow players to
have unrestricted game-writing powers - perhaps some kind of submission/
refereeing/testing process would be appropriate for the addition of new
sections to such a game.
Perhaps Graham or Dilip will tell you about TERA, which set out to
attack some of these difficulties.
--
Gareth Rees
Greg Ewing
In article <397qqp$2...@lyra.csx.cam.ac.uk>, gd...@cl.cam.ac.uk (Gareth Rees) writes:
|>
|> Multi-player games (MUDs) have a number of game design difficulties
|>
|> get solve the problem when player Y has the object needed to solve
|> it?
|>
|> so that it can be solved by the next player.
These problems stem from attempting to create an open-all-hours
universe where players drop in and out. Instead, perhaps we should
think about "team IF", where a bunch of players get together and
decide to play a game session. The universe is set to some
initial state, and the players embark on the game, until they
complete the goal they've set themselves, or get bored, or
decide to stop for lunch or whatever. Players who want to join
the game part way through will have to accept the universe
in whatever state it's in. Much like roleplaying game sessions
are, I suppose.
|> I'm sure you
|> don't need me to describe the difficulties that can result when several
|> people (none of whom know what the others are doing) are allowed to
|> write general IF code.
To me this suggests that the traditional programming-language
style of IF programming is the wrong way to go in this context.
It's way too general - any piece of code can do anything.
I've been thinking about this problem on and off for quite some
time, and I believe the solution lies in a very simulation-oriented
structure which defines basic "laws of physics" on which everything
else is based. The game is extended, not by writing code outside
the game, but by working within the universe itself according
to the rules of the game.
My ideas on what such a set of laws would be like are pretty
hazy, but I have a few ideas I could share if anyone is
interested.
|> Perhaps Graham or Dilip will tell you about TERA, which set out to
|> attack some of these difficulties.
Yes, I'd be interested to hear about that.
|> Gareth Rees
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
Mah / Nick (MGM)
Jamieson Norrish <ja...@akeake.its.vuw.ac.nz> wrote:
>In article <397qqp$2...@lyra.csx.cam.ac.uk> gd...@cl.cam.ac.uk (Gareth
>Rees) writes:
>
> * The timing problem. In SPIF, it's appropriate for one action
> to take several minutes of "game" time (go south) and another
> to take a second or two (strike match). In MUDs, all the
> players have to be running on the same timescale.
>
>up time-consuming actions into smaller parts, or by simply enforcing
>some sort of delay in action resolution. Neither are difficult to do.
This is true .. however, this can get VERY irritating. Muds rely on a
compressed time system. It's not realistic, but it works. For an example
of just how irritating it is, go try Medievia mud (And then leave - it's
a horrid mud, known for their lack of credits to the authors of the base
code :).
>This stems from the approach that every puzzle must be doable by every
>character. Change that approach and the problem disappears.
Yup - if you make sure that there are enough puzzles, then this is fine.
Curses would not work as a multiplayer game - the puzzles are too linked
.. one puzzle leads on from another. Zork would work better .. It will be
interesting to see how the creators at zorkmud manage to implement a
purely puzzle driven mud.
> * The resetting problem.
>Resets are bad. Do not have resets. Leave the game world alone.
Suggested modification (from abermuds/dums/Mud1) have resets, but require
all players to agree, and to be in the reset room .. also have a minimum
period between resets. No retention of objects between resets.
-- Taro.
Jamieson Norrish
* The timing problem. In SPIF, it's appropriate for one action
to take several minutes of "game" time (go south) and another
to take a second or two (strike match). In MUDs, all the
players have to be running on the same timescale.
This can be adequately dealt with in most cases by either splitting
up time-consuming actions into smaller parts, or by simply enforcing
some sort of delay in action resolution. Neither are difficult to do.
* The object problem. In SPIF, a puzzle will typically require
getting a few objects and then using them to persuade some area
of the game to go through a few states. In MUDs, how is player
X to get solve the problem when player Y has the object needed
to solve it? Do you duplicate objects? Or have object-less
puzzles?
This stems from the approach that every puzzle must be doable by every
character. Change that approach and the problem disappears.
* The resetting problem.
Resets are bad. Do not have resets. Leave the game world alone.
Jamie
Phil Goetz
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>
>I've been thinking about this problem on and off for quite some
>time, and I believe the solution lies in a very simulation-oriented
>structure which defines basic "laws of physics" on which everything
>else is based. The game is extended, not by writing code outside
>the game, but by working within the universe itself according
>to the rules of the game.
As I've said before --- use a rule-based system!
Let the authors create objects, and write rules involving those objects.
Phil go...@cs.buffalo.edu
Jamieson Norrish
u94...@student.canberra.edu.au (Mah / Nick (MGM)) writes:
In article <JAMIE.94N...@akeake.its.vuw.ac.nz>,
Jamieson Norrish <ja...@akeake.its.vuw.ac.nz> wrote:
>This can be adequately dealt with in most cases by either
>splitting up time-consuming actions into smaller parts, or by
>simply enforcing some sort of delay in action resolution. Neither
>are difficult to do.
This is true .. however, this can get VERY irritating. Muds rely on
a compressed time system. It's not realistic, but it works.
I don't think that this compressed time system has to be in place,
however. Sure, it needs to be handled well in order for it not to be
irritating, but it isn't that hard to remove long pauses from the
game.
>This stems from the approach that every puzzle must be doable by
>every character. Change that approach and the problem disappears.
Yup - if you make sure that there are enough puzzles, then this is
fine.
Well, I guess there's that solution. I was thinking more of a game
where there was no absolute "success" (if it was meant to be like most
MU*s are - running on and on without (intended) end), or was designed
so that people could lose out. With these sorts of game, there is no
need to provide lots of puzzles - besides, lots of conflict can arise
just out of the characters.
>Resets are bad. Do not have resets. Leave the game world alone.
Suggested modification (from abermuds/dums/Mud1) have resets, but
require all players to agree, and to be in the reset room .. also
have a minimum period between resets. No retention of objects
between resets.
No, resets are bad. Do not have resets. There is probably nothing
which destroys any feeling a player may have that the characters exist
in the world in a meaningful way than resets. They remove all the
minimal changes that can occur on most MU*s. Resets spring out of two
desires - the desire for there to always be enough monsters to kill (a
stupid reason, and regardless resets are a pitiful solution), and so
that objects aren't all stuck in the hands of players for ever and
ever. Neither of these seem particularly relevant to IF.
Jamie