[general] multiple player IF

2 views
Skip to first unread message

Chris

unread,
Mar 27, 2001, 12:04:12 PM3/27/01
to

Dear all,

I currently have a half-finished engine for multiple player games, heavily
based upon inform.

Before I make the massive effort to complete the engine, I need a game idea
to run on it. I have several, but they're a bit half-baked at the moment.

I could just turn it into a MUD, but I don't want to. What I mean by MUD is
a game where you have multiple copies of everything essentially, (i.e. each
player will find a lamp in the cupboard, not first come first served), and
that players aren't trying to complete the game, but play against each other
and impreove their attributes.

This last part I detest - doing 'quests' to improve your characters stamina.
I would prefer to write a game that involved a game which was basically IF
but with the provision for many players to take part at once, as different
characters, each with different aims to complete the game from their point of
view, perhaps at the expense of the other players from time to time but on
the whole in parallel, and avoiding the kind of 'throw x at y' scenario in
most MUDs where you have to kill everyone to gain experience points.

It would be possible to run those characters not currently being used by
players using some sort of AI model - so you shouldn't be able to tell the
difference.

Is any of this be a good idea? Does the whole thing smack of naivete? Has
this been done already? If so did it work well (or at all)?

How would one alter the basic design and principles of IF to cope with a
multiple player scenario? Is it feasible?

Discussion invited.

Yours ponderingly

Chris

--
Christian Lund | email: cd...@cam.ac.uk
Jesus College | 'phone: [blanked]
Cambridge |

Alex Schroeder

unread,
Mar 27, 2001, 3:18:41 PM3/27/01
to
Chris <cd...@pop.hermes.cam.ac.uk> writes:

> I could just turn it into a MUD, but I don't want to. What I mean by MUD is
> a game where you have multiple copies of everything essentially, (i.e. each
> player will find a lamp in the cupboard, not first come first served)

This is not true for the MUSH I play on.

> players aren't trying to complete the game, but play against each
> other and impreove their attributes.

Well, on a MUSH there no game to complete, it's just endless roleplay
(or chat, as often happens).

> This last part I detest - doing 'quests' to improve your characters stamina.

No such thing on a MUSH.

> Is any of this be a good idea? Does the whole thing smack of naivete? Has
> this been done already? If so did it work well (or at all)?

What you get on the MUSH I play on is objects, rooms, characters,
talking, moving, fighting (if you choose to do so), but little or no
bots, quests, and fights, and no experience points, no levels. So
much for the downside of MUDs/MUSHes. Whether it is a MUD or a MUSH
depends very much on the softcode used, so I think you are lumping
together things that are not necessarily connected.

What I have done on MUSHes is code rooms, objects and NPCs. But there
was no fighting, no experience to be gained. In essence a quest to be
solved because it was entertaining to read. It involved a murder,
underground chasing in the sewers, hidden rooms, a shop with
information about my characters culture.

What exactly was different from an IF? No score. No death. And the
*focus* was different. People didn't expect there to be quests.
People expected to roleplay together.

So what I'm getting at is that you can have all that you want within a
MUSH (eg. http://www.pennmush.org/), all you have to do is advertize
your focus on puzzle solving and coding to the players. All you need
is lots of energy to put in setting up a MU*, running it,
administrating it, inviting other players...

One alternative is to "hijack" a social MUSH run by other people.
Code what you need to code. Invite friends for a session and roleplay
the riddles and puzzles you've set up. I know people that have done
this and it must have been great fun.

Alex.
--
http://www.geocities.com/kensanata/
Coffee should be black as hell, strong as death and sweet as love.
-- Turkish proverb

Dennis G. Jerz

unread,
Mar 27, 2001, 3:25:42 PM3/27/01
to
"Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
news:e68ee7614a%cd...@utopia.jesus.cam.ac.uk...

I think this is a great, ambitious project. As a mediocre programmer at
best, I have no advice to offer as to its feasibility.

I wonder if the technology just might be ahead of what the storytellers
might be able to do with it. It's hard enough coding one PC... but coding
multiple PCs so that if they're not being played by a person, they're
handled by AI? What happens if one human player has to quit in the middle
of the game -- does the AI kick in immediately?

Phil Goetz has a few words to say about how the addition of another PC would
affect the experience:
---begin quote from Goetz --------
Multi-reader interactive fiction

Many computer games have developed from single-player to multi-player, such
as Nettrek and Conquest (space war games), Maze (a tank-war game), and many
multi-player dungeons. But having multiple readers in an IF is not as simple
as introducing another person into the same scenario. If the two people act
independently, how can they both experience a dramatic unfolding of events?
How can they both even understand what is happening in the world? In order
for a reader to experience drama, what unfolds before them must be important
to future events. But if what unfolds before each reader is central to the
plot, then each sees only one half of what they need to. If they find each
other and exchange information, the plot will not unfold but be thrown on
them in disordered chunks.

Writers using the third person limited point of view must be careful to
ensure that their central character has an appropriate view of the story; no
events should occur without explanation, but when suspense is intended, the
outcome should not be known in advance. Can these restrictions be ignored
safely, as they are in live-action role-playing games? Perhaps the solution
is that each participant experiences a different drama: one may be the
protagonist, and the other the antagonist.

For adventures, the task is difficult, but different. Since the primary
purpose in an adventure is puzzle-olving, players can interview each other.
It doesn't matter in what order information is revealed. Half of the fun
might be divinig which players are telling the truth and which are lying.
Some might pretend to be computer-controlled, so as not to be feared as
competitors. A different problem for adventures is that in traditional
puzzles, particular items are often necessary. If there is only one key to
the attic, and one player keeps it, what can the rest do? Perhaps the
scenario can be designed so that each participant has a different set of
tasks.

What if one player plays for hours on end, and the other only an hour a day?
Can a narrative be such that one can drop in and out of it and still enjoy
it? In a narrative with competing players, perhaps the players can take
turns, with large sections of narrative between each turn - a play-by-mail
(or email) format.

--------end quote from Goetz
<http://www.mud.co.uk/richard/ifan194.htm> -----------


I can think of scenarios -- mostly in genre fiction, along the lines of the
"How to Host a Murder" party games, but as you note this kind of gameplay
would have to be part IF and part MUD (and part... I don't know what).

This might work well as part of a series of well-defined "missions" that
relate to each other as part of an overall quest. I'm thinking of a Star
Trek style "aweigh team," or traditional party-based activities... but then
you get into the tedious "building up skill points" activities that you say
you wish to avoid.

But look at how IF has changed from the days of "Colossal Cave Adventure" --
Crowther wouldn't have gotten anywhere if he'd waited for the perfect plot.
His storyline developed more or less organically from the strengths and
limitations of the medium. Exploration, recognizing patterns, collecting
widely-dispersed clues, and conversation trees with NPCs are all standard
IF features that could possibly be divided up among several players (who
might, say, split up at an intersection, but remain in voice communication
via walkie talkie props). A detective story with a lot of characters to
interview and a lot of backstories to check out could prove interesting.
You might also try a cops and robbers variation, on the level of
"Bladerunner", in which you are either a free spirit trying to escape the
ruthless laws of a totalitarian state, or a devoted civil servant dedicated
to punishing the guilty for their crimes. Instead of working together, you
could be working against one another. This could be a challenge to write --
especially since it would make sense to let the game progress
asynchronously, but would certainly add to the replay value.

My suggestion is that you create a sample world that demonstrates the new
storytelling/simulation/experiential tools that your environment can
provide, and then once more people get familiar with your hybrid, maybe
we'll all have a clearer idea what the issues are.

--
Dennis G. Jerz, Ph.D.; (715)836-2431
Dept. of English; U Wisc.-Eau Claire
419 Hibbard, Eau Claire, WI 54702
------------------------------------
Literacy Weblog: www.uwec.edu/jerzdg

Chris

unread,
Mar 27, 2001, 7:00:07 PM3/27/01
to
"Dennis G. Jerz" <Jer...@uwec.edu> wrote:
[snip previous post]

> I wonder if the technology just might be ahead of what the storytellers
> might be able to do with it. It's hard enough coding one PC... but coding
> multiple PCs so that if they're not being played by a person, they're
> handled by AI? What happens if one human player has to quit in the middle
> of the game -- does the AI kick in immediately?
>
well, maybe. It depends on what is required, which is the best way. An
(N)PC when not a PC would behave like an NPC which moved around a bit better,
and was fairly dumb. In other words, not really like a player at all, but
would still be a part of the game. Not very I in AI ;-)

> Phil Goetz has a few words to say about how the addition of another PC
> would affect the experience: ---begin quote from Goetz --------
> Multi-reader interactive fiction
>
> Many computer games have developed from single-player to multi-player, such
> as Nettrek and Conquest (space war games), Maze (a tank-war game), and many
> multi-player dungeons. But having multiple readers in an IF is not as
> simple as introducing another person into the same scenario. If the two
> people act independently, how can they both experience a dramatic unfolding
> of events? How can they both even understand what is happening in the
> world? In order for a reader to experience drama, what unfolds before them
> must be important to future events. But if what unfolds before each reader
> is central to the plot, then each sees only one half of what they need to.
> If they find each other and exchange information, the plot will not unfold
> but be thrown on them in disordered chunks.
>

Very very true. The key I see here is 'central'. There would have to be a
carefully structured story so as to make not just one player the central
character.

> Writers using the third person limited point of view must be careful to
> ensure that their central character has an appropriate view of the story;
> no events should occur without explanation, but when suspense is intended,
> the outcome should not be known in advance. Can these restrictions be
> ignored safely, as they are in live-action role-playing games? Perhaps the
> solution is that each participant experiences a different drama: one may be
> the protagonist, and the other the antagonist.
>

what I had in mind, only better expressed...

> For adventures, the task is difficult, but different. Since the primary
> purpose in an adventure is puzzle-olving, players can interview each other.
> It doesn't matter in what order information is revealed. Half of the fun
> might be divinig which players are telling the truth and which are lying.
> Some might pretend to be computer-controlled, so as not to be feared as
> competitors. A different problem for adventures is that in traditional
> puzzles, particular items are often necessary. If there is only one key to
> the attic, and one player keeps it, what can the rest do? Perhaps the
> scenario can be designed so that each participant has a different set of
> tasks.

Here we have the earliest (but probably not biggest) hurdle - in many MUDs
(like Discworld), everyone can have each object. As one player approaches
the dumbwaiter and finds the wishbone, there is no longer a wishbone there
for him. But for the next, is there a wishbone? Each 'instance' of a
wishbone could be tagged as for one player, to do with as they liked, or
there could be just one. To be fought over.

In one of the early MUDs, (Island), when a player died/quit, then everything
he had vanished and went somewhere else. So it could be used by anyone, but
there was only one - only one player could have it at any one time, but when
you left, it was up for grabs again. This is probably the best middle way...
the bad thing is, if you look somewhere for something and it's not there, it
may well live there most of the time but someone had it when you looked; so
you'd have to look everywhere more than once until you found it. Not great.

> What if one player plays for hours on end, and the other only an hour a
> day? Can a narrative be such that one can drop in and out of it and still
> enjoy it? In a narrative with competing players, perhaps the players can
> take turns, with large sections of narrative between each turn - a
> play-by-mail (or email) format.

Don't think this is much of an issue. Does anyone disagree? If one player
plays longer, they'll get further.

> --------end quote from Goetz <http://www.mud.co.uk/richard/ifan194.htm>
> -----------

[snip]


> My suggestion is that you create a sample world that demonstrates the new
> storytelling/simulation/experiential tools that your environment can
> provide, and then once more people get familiar with your hybrid, maybe
> we'll all have a clearer idea what the issues are.
>

That's what I hope to do. But I'm past the stage of creating the program,
and into the stage where I have to code millions of verbs and think about
exactly what I need to code now. I have in place the structure to do
anything, but I need to know in which direction to move...

What I lean towards at the moment is a 'multiple dimension' game, in which
each arena has different characteristics. In some, maybe you need other
players to help (push buttons at the same time, etc.?), and in others it's
more of a race/competition.

The key point is: I want a story. I want people to work together or against
each other to push forward and work out *what happens next*, (what in my
opinion is) the whole point of IF. To not really be role-play for
role-play's sake, but to immerse oneself in the character(s) to live out the
story, not to make your own up as you go along.

Cheers for the feedback,

Chris

--
Christian Lund
Jesus College
Cambridge

Chris

unread,
Mar 27, 2001, 6:42:36 PM3/27/01
to
-- Christian Lund Jesus College Cambridge
you wrote: [snip]

> > players aren't trying to complete the game, but play against each other
> > and improve their attributes.

>
> Well, on a MUSH there no game to complete, it's just endless roleplay
> (or chat, as often happens).
>
Now this is fine, however; if people want social chat and little else, then
go to a chatroom (or similar). So why go to a MUD (I don't know what MUSH
stands for or how it differs from a MUD, so I'll continue using MUD)? Well,
because you have something else to do apart from chat, if you so choose. It
is this something else that I am looking for.

> > This last part I detest - doing 'quests' to improve your characters
> > stamina.
>
> No such thing on a MUSH.
>
> > Is any of this be a good idea? Does the whole thing smack of naivete?
> > Has this been done already? If so did it work well (or at all)?
>
> What you get on the MUSH I play on is objects, rooms, characters,
> talking, moving, fighting (if you choose to do so), but little or no
> bots, quests, and fights, and no experience points, no levels. So
> much for the downside of MUDs/MUSHes. Whether it is a MUD or a MUSH
> depends very much on the softcode used, so I think you are lumping
> together things that are not necessarily connected.
>

Yes, I am lumping things together, but through ignorance. That's why I
asked. I have little (or no) idea! The few MUDs I have tried have involved
quests and too much combat for my liking.

> What I have done on MUSHes is code rooms, objects and NPCs. But there
> was no fighting, no experience to be gained. In essence a quest to be
> solved because it was entertaining to read. It involved a murder,
> underground chasing in the sewers, hidden rooms, a shop with
> information about my characters culture.
>

This is more like what I need. I need a way to implement a storyline which
people can play together. I suspect this may be very difficult (see other
post in this thread).

> What exactly was different from an IF? No score. No death. And the
> *focus* was different. People didn't expect there to be quests.
> People expected to roleplay together.
>

Here, I would say that the very best IF has no death either. Yes, you can
make mistakes, but is no death at all very different from 'a puff of orange
smoke'?

See other post (by the way - I may disagree on some points, but on the whole
very informative and thank you :-)

--
Chris Lund
Jesus College
Cambridge

David

unread,
Mar 27, 2001, 8:37:49 PM3/27/01
to
How about a "Tomb Raider" thingy whereby the players are part of the
excavation team in the desert and must enter the pyramid.

Story twists could include:
Desert nomads who try to rob you
Does the scorching sun dehydrate players? Thus, do they face the sun or the
nomads to get to the well?
The player attributes (one player is thin and wiry: the professor who can
read the hyroglyphs, another is large and muscular: the strongman, another
is...)
The puzzles (3 stones that must be stood on at the same time to open the
inner chamber, strongman must lift a rock for the professor to duck
underneath to read the underside, etc)

The problem is ensuring that all players are actively involved. We can't
leave the strongman outside the pyramid without a quest while the professor
is inside. Maybe the strongman has to deal with the nomads somehow which
will affect the outcome for the professor (an alternative entrance to the
pyramid, or the nomads wanting a portion of the loot and hence score).

Just my 2 cents.

--
David

"I'm told that the difference between children and
puppies is the dissapointment when a puppy grows up"

"Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
news:e68ee7614a%cd...@utopia.jesus.cam.ac.uk...
>

David A. Cornelson

unread,
Mar 27, 2001, 11:11:50 PM3/27/01
to
"Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
news:e68ee7614a%cd...@utopia.jesus.cam.ac.uk...
>
> Dear all,
>
> I currently have a half-finished engine for multiple player games, heavily
> based upon inform.
>
> Before I make the massive effort to complete the engine, I need a game
idea
> to run on it. I have several, but they're a bit half-baked at the moment.
>

I brought this up a year or more ago on ifMUD and one of the mudders created
a method where a mud bot represents the 'interface' to inform and tads
games. The mud has a version of werewolf that about many of us can play at
the same time. Outside of that, the mud-bot will allow you to play any of
the 'installed' games via ifMUD.

Anyway, to your question. I want this bad. I think a multi-player if
compiler would be fantasic. We had many discussions about this and there may
even be a transcript somewhere. Some of the roadblocks were how turns would
count for each player, how would players connect to the same game, how would
you modify the Inform language to accomodate multiple 'views' of the same
game state, and much more. Well, I use Inform as an example, but whatever
language would be used would need to have reactions to other players. If one
player drops an object, the interface has to relay that to the other
player(s). If collaboration is allowed, then how do you code this?

I think the design would be to have a client/server model where the server
controls an instance of a game and players use a client to connect. They see
the list of instances and 'join'. Then they get to pick or resume a
character. The system would be turn based. If all players aren't playing,
then you can't play the game. The whole point would be to have a truly
multiplayer environment.

So after the programmed characters have been instantiated by the players,
the game will move turn by turn for each player unless there is a
dependency. What I mean is, I can continue with my running around while the
other player stands in one spot. The other player's client will display
messages if I'm int he vicinity, but otherwise remain silent. (this would be
controlled through the game developers own code).

But a dependency would be something like a tree that needed to be climbed.
Say the game required that one player lift the other player up to the lowest
branch. This would require both players to be involved in the same puzzle,
therefore the game could not continue climbing the tree unless both players
needed to climb the tree were present.

PArt of me thinks that there may be a way to do this with some tricky client
code and a basic Inform game file, but I haven't really sat down and tried
to lay it all out. Another part of me thinks that you really need to build a
whole new virtual machine that would be a server based machine and then have
a client that would connect to the server appropriately and manage game
state from multiple clients.

These are my thoughts. I really think this would take IF to another level,
but it seems unlikely that it will happen anytime soon.

Jarb


Alex Warren

unread,
Mar 28, 2001, 9:11:15 AM3/28/01
to
David A. Cornelson wrote:

[various snippages]


> I think a multi-player if compiler would be fantasic.

> Some of the roadblocks were how turns would
> count for each player, how would players connect to the same game, how would
> you modify the Inform language to accomodate multiple 'views' of the same
> game state, and much more. Well, I use Inform as an example, but whatever
> language would be used would need to have reactions to other players. If one
> player drops an object, the interface has to relay that to the other
> player(s). If collaboration is allowed, then how do you code this?

Perhaps a quick peek at my QX server and current Quest 3.0 beta software at
http://www.axeuk.com/qx/ and http://www.axeuk.com/quest/beta/ may be of
interest. It seems to be fairly similar to what you're describing in your post,
except it's not based on Inform but on version 3.0 of Quest, which is a damn
sight more powerful and generally nicer than previous versions.

In a nutshell: QX is the server software, and when you run it you select a game
to run on the server, and then the software listens for incoming connections.
Quest can then be used by other players as the client software, and this
connects to the server. In its default state everybody would start from the same
point and essentially be the same character, although it wouldn't be too hard at
all to code some system of selecting a character, starting from different
locations etc. yourself.


> So after the programmed characters have been instantiated by the players,
> the game will move turn by turn for each player unless there is a
> dependency. What I mean is, I can continue with my running around while the
> other player stands in one spot. The other player's client will display
> messages if I'm int he vicinity, but otherwise remain silent. (this would be
> controlled through the game developers own code).

This is similar to what QX does. Basically the view each player has is much like
conventional IF, but from time to time the window may print some event - for
example, "Bob has entered the room", or "Bob dropped a mug". If Bob is in the
room, you can talk to Bob. If he's dropped a mug, you can now pick it up.


> But a dependency would be something like a tree that needed to be climbed.
> Say the game required that one player lift the other player up to the lowest
> branch. This would require both players to be involved in the same puzzle,
> therefore the game could not continue climbing the tree unless both players
> needed to climb the tree were present.

I don't think this would be too easy to do in QX's current incarnation (it's
only an alpha after all), but as soon as there is a method of whereby the game
code can easily tell what players are at a given location, this won't be too
hard to code.


> These are my thoughts. I really think this would take IF to another level,
> but it seems unlikely that it will happen anytime soon.

I could argue, I suppose, that "it's happening now", but unfortunately it
patently isn't. Interest in QX seems to be a little bit low at the moment, but
it's early days yet. What I think would increase interest is if I could come up
with a decent game to play on the system, and if I or some kind soul could get
access to a machine where it could be run 24 hours a day.

I don't think a standard IF game would translate too well to multiplayer though.
Some sort of vaguely general-purpose "world" would be more appropriate, which
would allow players to join and leave at any time. The focus would be more on
players interacting with players, rather than players interacting with bits of
the world that have been created by the game author - otherwise the whole thing
could quickly get very boring.


--
Alex Warren
al...@axeuk.com
Quest - Make adventure games easily - http://www.axeuk.com/quest/

Alex Schroeder

unread,
Mar 28, 2001, 1:22:36 PM3/28/01
to
As to the MUD/MUSH distinction. As far as I can tell, all of these
things look more or less alike. Like a text adventure but
multiplayer. There seems to be a "cultural" difference, though: MUDs
focus on quests, fighting, levels, experience, while MUSHes focus on
roleplaying, plots, playing together. As to the discussion at hand I
don't think the distinction matters. :)

I'll describe the MUSH I'm playing on, Elendor,
http://www.elendor.net/

Chris <cd...@pop.hermes.cam.ac.uk> writes:

> See other post (by the way - I may disagree on some points, but on the whole
> very informative and thank you :-)

Thank you. I'll try to do some more convincing. Somehow I feel that
the main problem is lack of experience -- reading some of the other
posts I feel as if people here want to reinvent the wheel. Therefore,
I suggest we collect arguments *against* using a MUSH so that I can
see wether we can dispell these arguments or wether a new solution is
actually called for. Obviously nobody wants to code something from
scratch if an existing solution can be adapted.

The following seems to be your main point (correct me if I'm wrong,
add more if you're still not convinced to look at it):

> This is more like what I need. I need a way to implement a storyline which
> people can play together.

Several problems arise, I'll try to address some of them:

Objects

Objects are owned by their creator. Each object exists exactly once.
When a character disconnects, he is inactivated (invisible, non
attackable, no events react to him). He keeps his objects (which are
therefore also invisible, since they are "inside" the character.

Plots

Plots usually involve several people (at least one) that oversee the
plot much like a game master oversees a roleplaying game (AD&D etc).
These plot owners coordinate everything, prepare players for their
role, prepare any objects and rooms needed, etc. This is what you
will need to do.

Note that a lot of roleplay (most of the roleplay I've seen) doesn't
revolve around plots but is the result of several players improvising
together. You may not want to encourage this play mode, but then
again, why should you forbid it.

Uniqueness

As you prepare the game ahead of time, and as players go through the
plot and talk about it afterwards, the entire thing is usually a
one-time affair. You may not like this. Since a plot usually
involves *people*, however, there's no avoiding it. Nobody wants to
play the bad orc again and again and again.

Note that from an IF perspective, coding semi-intelligent NPCs is not
a problem. IF authors are often used to coding. Often enough MUSH
players don't code or don't have the priviledges to do so, therefore
not many people code the NPCs of their plots. Back when I did this, I
had to do this because we didn't have enough players (the MUSH
eventually closed down).


OK, enough for now. Perhaps you should take a look at a MUSH coding
manual to get a feel for what is possible and what is not. Jump right
to the 2x2 file for the coding, skipping the intro... ;)

http://pennsic.com/MUSHMAN/mman.html

The MUSH I play on is a PennMUSH (that refers to the "hardcode"
underneath all the descriptions, rooms, objects, etc. Sort of like
calling it the "Inform-Server" or the "TADS-Server"). There is a lot
of information on the homepage, including a short paragraph on MUD,
MUSH and PennMUSH:

http://pennmush.org/

Kevin Forchione

unread,
Mar 28, 2001, 3:28:32 PM3/28/01
to
"David A. Cornelson" <dcorn...@placet.com> wrote in message
news:Apdw6.8959$lA1.3...@news.dbn.net...

> "Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
> news:e68ee7614a%cd...@utopia.jesus.cam.ac.uk...
> >
> > Dear all,
> >
> > I currently have a half-finished engine for multiple player games,
heavily
> > based upon inform.
> >
> > Before I make the massive effort to complete the engine, I need a game
> idea
> > to run on it. I have several, but they're a bit half-baked at the
moment.
> >
>
> I brought this up a year or more ago on ifMUD and one of the mudders
created
> a method where a mud bot represents the 'interface' to inform and tads
> games. The mud has a version of werewolf that about many of us can play at
> the same time. Outside of that, the mud-bot will allow you to play any of
> the 'installed' games via ifMUD.

How would this differ from a MUD?

--Kevin


Stark

unread,
Mar 28, 2001, 5:55:38 PM3/28/01
to
In article <3ac13ec4$0$25473$7f31...@news01.syd.optusnet.com.au>, "David"
<davi...@optusnet.com.au> wrote:

> How about a "Tomb Raider" thingy whereby the players are part of the
> excavation team in the desert and must enter the pyramid.
>
> Story twists could include: Desert nomads who try to rob you Does the
> scorching sun dehydrate players? Thus, do they face the sun or the
> nomads to get to the well? The player attributes (one player is thin and
> wiry: the professor who can read the hyroglyphs, another is large and
> muscular: the strongman, another is...) The puzzles (3 stones that must
> be stood on at the same time to open the inner chamber, strongman must
> lift a rock for the professor to duck underneath to read the underside,
> etc)
>
> The problem is ensuring that all players are actively involved. We can't
> leave the strongman outside the pyramid without a quest while the
> professor is inside. Maybe the strongman has to deal with the nomads
> somehow which will affect the outcome for the professor (an alternative
> entrance to the pyramid, or the nomads wanting a portion of the loot and
> hence score).
>

Of course, this would only really work if there were a fixed number of
people playing the game at any one time. However, I *really* like these
ideas and think that a "three-person game" would be great to play -
providing you can find another two people to play with at the same time.

I always wanted to write a puzzle which required two people to turn
different keys in different locks at the same time to open a high-security
safe (as seen in many quality spy/action films!).

Cheers,
Stark

David A. Cornelson

unread,
Mar 28, 2001, 8:47:51 PM3/28/01
to
"Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
news:e68ee7614a%cd...@utopia.jesus.cam.ac.uk...
>
> Dear all,
>
> I currently have a half-finished engine for multiple player games, heavily
> based upon inform.
>

I found it. Here is the original ifMUD conversation about networked IF from
two years ago.

http://ifmud.port4000.com/alex/logs/networked-if.txt

Jarb


Brandon J. Van Every

unread,
Mar 30, 2001, 1:38:40 AM3/30/01
to

"Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
news:e4a2d624a%cd...@utopia.jesus.cam.ac.uk...

> Here we have the earliest (but probably not biggest) hurdle - in many MUDs
> (like Discworld), everyone can have each object. As one player approaches
> the dumbwaiter and finds the wishbone, there is no longer a wishbone there
> for him. But for the next, is there a wishbone? Each 'instance' of a
> wishbone could be tagged as for one player, to do with as they liked, or
> there could be just one. To be fought over.

Why do players need to have "things?" What is the purpose of having
"things?" You need to answer these questions in narrative terms. If they
are merely resources to be fought over, you don't have an adventure game,
you have a wargame. Implemented in textual drag, of course.

> What I lean towards at the moment is a 'multiple dimension' game, in which
> each arena has different characteristics. In some, maybe you need other
> players to help (push buttons at the same time, etc.?), and in others it's
> more of a race/competition.

Also be careful you're not just implementing multiplayer Sokobahn (sliding
barrel puzzle game). Some things, you have to ask yourself why you chose to
do this in text as opposed to a straightforward videogame. A text game
should use story as a core component of its gameplay, IMHO.


--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA


Brandon J. Van Every

unread,
Mar 30, 2001, 2:25:47 AM3/30/01
to

"Chris" <cd...@pop.hermes.cam.ac.uk> wrote in message
news:e68ee7614a%cd...@utopia.jesus.cam.ac.uk...

>
> Is any of this be a good idea? Does the whole thing smack of naivete?
Has
> this been done already? If so did it work well (or at all)?
>
> How would one alter the basic design and principles of IF to cope with a
> multiple player scenario? Is it feasible?

It is feasible. But first you have to realize that it's a problem of
content, not technology. Try running a freeform multiplayer PBEM RPG. By
"freeform" I mean "has no rules." Well, except however the Gamemaster
chooses to enforce consistency. But nothing like stats etc.

I've been doing such experimental exercises for 3 years now and I'm finally
starting to understand how to do one successfully. Call me slow. Principle
(1): no more than 3 or 4 players including the GM. More than that, and your
plot nodes spiral out of control, your characters end up thin, things just
devolve into uncoordinated pointlessness. Principle (2): you must
understand the basic craft of telling a story. What plot points are, what
character development is, what pacing is, what setups and payoffs are, what
reversals are, what the audience needs to perceive, etc. You can buy books
on that sort of thing. The books I read were mainly about screenwriting,
but you could read any books that deal with constructing a common literary
form. Principle (3): once you know how to write stories, don't try to
impose an overbearing structure on your players. Just have them improvise
everything. You be the guide. If you try to turn it into some kind of big
plot structured thing, premeditating all the character descriptions and
motives, you'll never get anything done. The story will never get written.
Just start improvising, stay on top of people to write material, and let the
chips fall where they may.

You're going to fail over and over again on the technological end of things
until you understand the content end of things. The content should drive
the technology. If you let the technology drive the content, you're
probably going to end up with a hack 'n' slash CRPG.

The Game Of Immortals, which I'm doing for the 3rd time or something like
that now, has an interesting basic premise: death is impossible. All the
mortals have perished, leaving only the gods to contemplate their
entertainment in the absence of mortals to kick around. No death, no fun!
Fortunately there is still Ego. Ego is the basic currency of immortal
existence. Anyways, the point of such a rule is to eliminate the easy
crutch of making everything about "Do as I say or you'll die!"

I've played games both where all the players are "blind" to each others'
actions unless they could perceive them in the course of events, and games
where everyone just writes everything together. I prefer the latter, it's
more productive. "Blind" stuff sounds cool but in practice introduces many
more plot holes than you would otherwise have. You spend too much time
worrying about who's gotten all the information they need to understand
what's going on. Simulating "blindness" might sound like a great idea to
you, something reminiscent of other client-server wargame experiences, but
be advised that simulation isn't the higher goal of game design.
Personally, I think it's more interesting to create the deviousness while
everyone is watching, and it's also easier.

Granted, there are lotsa things you can do with human players that you
couldn't do with a CDROM. Still, first you have got to spew out enough
content that you could viably produce a multiplayer adventure game. It is
easier if everyone is just reading everyone else's e-mail, heed my warning.
Writing freeform is the lowest overhead form of content production there is.
But it still takes time, and there are still things which will conspire to
keep you from getting it done. Reduce overhead, or you're finished.

David

unread,
Mar 30, 2001, 5:30:36 AM3/30/01
to

"Stark" <m...@tardis.remove_this_rubbish.ed.ac.uk> wrote in message
news:99tps5$rit$1...@newsg3.svr.pol.co.uk...

This being IF, any multiplayer facility would have to still be fiction
(MIF?). A storyline created by the author being experienced or explored by
the players. This almost rules out Multiplayer Adventure, but that would be
the best place to start since the code is freely available and it would
allow the ironing out of issues like:
* Even though you can't die in Adventure, what _would_ happen if I fell down
that crevice while still holding the stick with a star on the end? Where is
it, the stick that is, respawned and how? Do I get respawned?
* Does UNDO work? RESTART ? QUIT?
* How are player turns syncronised, or not?
* Can you distract the snake while I sneak past?

I also like the idea of a limited number of players. It allows better
shaping of characters and storyline. We don't want the expedition to
outnumber the nomads. We also probably don't want a player to be one of the
nomads, unless we limit their movement through fear of the Curse of the
Pyramid and give them their own plot.

Of course, the standard treasure hunt (like Zork) would work, given seperate
trophy cases, as a race against time and other players to accumulate wealth.

BTW. I like your "two key" idea. The plot could be based on an infiltration
of Area 51 (or the CIA Headquarters, or Fort Knox, or...) such that
coordination by players would be the flavour of the day. If one player
alerts the guards, all players should dive for cover. A player should be
able to get shot (wounded, or dead) and limit the rest of the team. Needless
to say, the story shouldn't have to say that dying may prevent the rest of
the players from completing the game.

--
David

"Turn left. No, your other left. No, your other left."


Reply all
Reply to author
Forward
0 new messages