Strange idea: turn single player IF into multi player

2 views
Skip to first unread message

Madoc

unread,
Jun 19, 2007, 8:10:00 AM6/19/07
to
Hello,

I have this strange idea in my head. I know, there is an unlimited number of
problems attached when You want to make a multi player game out of a single
player game. But cannot do other than posting those ideas. I already posted
them on intfiction.com, but got no response. Here is the article I posted there:

The basic idea is old, and I believe that every follower of interactive fiction
has already thought about it. There are so many great text adventures with such
great stories and sceneries, it is a pity that they are doomed to stay single
player adventures! Would it not be great if we could walk through our beloved
adventures online, together with others?

The other part is: I used to be a MUD player and developer. Lately, I looked on
some LPC source code (this is the language used for programming many MUDs). I
found it awful, could not find any documentation and quickly closed it again.
It would be great if MUDs could be programmed as easily as Inform 7, for
example. How about joining both?

The idea is in my mind for several years now, and I always turn it back,
thinking it would be impossible to make a single-player game multi-player.
There are good arguments for that. My main interest would be adding
multi-player support to Inform 7. That would just rock! (Do You know if any
such project already exists? I am sure that I am not the only one with that idea.)

But Inform is inherently single-player. The engine is created to support only
one player.

Wait a minute! There are text adventures in which You can switch Your
character, so You can control a group of people. Wouldn't that be a starting
point for making a text adventure multi-player?

Imagine the MUD server is just a program that the clients connect to, and
internally, it is running a Z machine, for example. The server is really not
much more than a filtering proxy for the Z machine. When player X sends command
A, the proxy server forwards the command to the Z machine. But it alters the
command a little bit, so the Z machine can recognize from whom the command
came. For example, it might send to the Z machine: "(X) A". The Z machine's
parser would be slightly altered, so that it recognizes this as the command
"switch into character X, then execute command A".

Then, the server captures all the output from the Z machine and sends it back
to the client.

For a very first, super simple version, this might work. However, more is
neccessary of course: When someone enters a room, all the other players in the
same room are supposed to see something like "X has entered the room", while
the player who has entered the room should see "You have entered the room". (I
think those messages could be captured with the same mechanism that a
single-player game player could "see through the eyes" of an NPC, for example
when the adventure involves remote controlling a robot.)

Well, can be done. Just like the proxy prefixes every player's command when
forwarding it to the Z machine, the Z machine can prefix every line of output
with the player it is directed to. In that way, a simple protocol can be
defined which can be used not only with the Z machine but with every IF system
for which someone wrote a multi-player library patch. (Actually, the protocol
would be somewhat different. For example, it would be better to use connection
IDs instead of player names.)

Of course, there would be more issues to be addressed. For example, commands
like undo, save and load must be deactivated. The server would need to create a
save file regularly and back it up. Probably, some engine limitations would
have to be broken or bended: For a MUD, it would be good to have the
possibility of creating objects dynamically. (Still, it is possible without
dynamic object creation. But even a moderately frequented MUD would have an
enormous number of objects soon.) Some limitations could be overcome by having
several Z machines running at the same time, serving different regions of the
game world. (When a player goes from one region to another, the proxy
transparently switches him to another Z machine, passing all the character's
data to the new Z machine.) I also believe that the proxy would need to be able
to have some introspection into the game world and the character's states.

Another issue is the passing of time. This might be a kill criterion why the
majority of existing text adventures would not work in multi-player mode (apart
from the structure of the story itself, which is always only around one player
and would be inconsistent with several players). Maybe this could also be solved.

Updates are also a most critical issue. How do I update the game world when a
bug was fixed? (Sounds like a killer first, but I have ideas on that one.)

You might say that this would be a very great waste of performance. But think
again! The Z machine runs lightning fast. (And the other IF engines as well, by
the way.) I think they are better suited for MUD development than any of the
actual MUD systems, at least if You want role playing flavored MUDs.

Please think about my ideas. What do You think of them? I know, it sounds naive
at first sight, but the longer I think about it, the more plausible it seems to me.

Madoc.

Mike Snyder

unread,
Jun 19, 2007, 8:50:32 AM6/19/07
to

"Madoc" <Mado...@gmail.com> wrote in message
news:f58go7$10qv$1...@sxnews1.qg.com...

> Hello,
>
> I have this strange idea in my head. I know, there is an unlimited number
of
> problems attached when You want to make a multi player game out of a
single
> player game. But cannot do other than posting those ideas. I already
posted
> them on intfiction.com, but got no response. Here is the article I posted
there:

I think you mean intfiction.org... :)

Single-player offline IF runners just aren't the right tool for multiplayer
online IF. For the work you'd have to do -- altering the input, making zcode
run as an in-server process, maybe wrapping it in an i/o watchdog to get it
to work CGI-like, writing a single-player game that makes sense as a
multiplayer game -- you'd be better off writing an engine that does what you
want.

You mention MUD's. If you want something that runs via telnet, couldn't you
write multiplayer IF *in* a MUD? Command parsing for zcode may be more
advanced, but it's already suited to the task.

--- Mike.


Urbatain

unread,
Jun 19, 2007, 9:27:44 AM6/19/07
to
For an example of an amazing system and parser for multiplayer IF, try
Castle Marach at Skotos:

http://www.skotos.net/

I'm not in pay there, but I think that they accomplished what a
multiplayer IF must have about the parser.

See you.

Urbatain.

Madoc

unread,
Jun 19, 2007, 10:15:47 AM6/19/07
to
> I think you mean intfiction.org... :)

Well I did, thanks!

> Single-player offline IF runners just aren't the right tool for multiplayer
> online IF. For the work you'd have to do -- altering the input, making zcode
> run as an in-server process, maybe wrapping it in an i/o watchdog to get it
> to work CGI-like, writing a single-player game that makes sense as a
> multiplayer game -- you'd be better off writing an engine that does what you
> want.

Think of all the required changes to the library! You'd have to do something
about all global player-related variables.

On the other hand, look on the source code of an adventure written in Inform 7:
Do You think there would be *that* many changes required to run it on a
supporting multi player system? I think most of it could stay as it is. That's
what motivated this thought of mine.

And then, there are those single-player adventures that allow to change the
controlled character during the game. So, my idea is not so impossible, after all.

I want to have a quick solution that works, tolerating technical imperfections.
A Z-Machine runs so fast, performance is really not an issue here. So we can
take the Z-Machine and "abuse" it to the limits.

If I'd write my own engine, then I would be busy for years and get a result
that is way worse than I7. Plus, when using I7, You already have loads of
authors who are perfectly familiar with the programming language. Traditional
MUDs require You to learn a - to my mind - really creepy programming language.

> You mention MUD's. If you want something that runs via telnet, couldn't you
> write multiplayer IF *in* a MUD? Command parsing for zcode may be more
> advanced, but it's already suited to the task.

You mean a kind of I7-to-MUD-language cross converter? Might be an idea. I
would need to take the I7 parser as a base. And I'm not sure if it can be
bended easily for such a task. In fact, I doubt it. Probably, it is strongly
connected with the Z machine and the Inform base library.

Another way would be introspection: You have a process running the single
player adventure. It turns on the "god" mode and walks through the whole game
world, thereby re-creating it as a set of MUD files. However, with that, one
would be missing all the algorithms defined in the code.

Well, maybe some kind of I7 cross compiler would be great. But the compiled Z
code could not serve as a source format for such a cross compiler, so we would
need to start at the I7 source and convert it to LPC, for example. My, that
would be a task!

Madoc

unread,
Jun 19, 2007, 10:18:34 AM6/19/07
to
> I'm not in pay there, but I think that they accomplished what a
> multiplayer IF must have about the parser.

I was more interested in the other side - the programming part. I7 is an
enormously elegant way of writing IF. Natural language programming would not
work out for most other areas of computer programming, but for IF, it's really
a genius' idea. If only I7 adventures could be multi player...

Mike Snyder

unread,
Jun 19, 2007, 10:22:02 AM6/19/07
to
"Urbatain" <urba...@gmail.com> wrote in message
news:1182259664....@q69g2000hsb.googlegroups.com...

Ah, yeah. I'm aware of Skotos, but I only tried one of their games briefly,
many years ago. It appeared to be a MUD using an embedded Java web client. I
could be remembering wrong.

At any rate, that's probably not how I'd approach it either. My idea was
always for something browser-based, without the text input at all (except
for chat). I spent six years working on the idea. Most of it is a
single-player adventure in a multiplayer world, but the engine itself would
easily handle multiplayer adventures. I could remove many of the
game-specific features (space travel, auctions, etc) and with a little work
have an interesting multiplayer engine for adventure games (I'd probably
want to work in a "give" from player to player that wouldn't involve one
player dropping the item, and the other picking it up, for instance).

http://www.starlock.com/

The back-end is in Perl, which drives a simple script interpreter (so
writing actual game/quest content is done that way, which makes it easier to
maintain).

I haven't worked on it in a long time, though. The game I was trying to
write with the engine was just too ambitious for me, which I had to concede
after six years. It'd be great for multiplayer adventure games, though.

---- Mike.


Mike Snyder

unread,
Jun 19, 2007, 10:35:31 AM6/19/07
to
"Madoc" <Mado...@gmail.com> wrote in message
news:f58o42$1304$1...@sxnews1.qg.com...

>> I think you mean intfiction.org... :)
>
> On the other hand, look on the source code of an adventure written in
> Inform 7: Do You think there would be *that* many changes required to run
> it on a supporting multi player system? I think most of it could stay as
> it is. That's what motivated this thought of mine.

I think you'd end up tailoring it to the specific input and output you
expect, or you'd have to require certain meta-output to trigger the
"wrapper" to take an action: for instance, room entry and exit commands that
the game couldn't otherwise handle without true multiplayer features.

> And then, there are those single-player adventures that allow to change
> the controlled character during the game. So, my idea is not so
> impossible, after all.

Yeah, that would let you handle different players in different rooms
containing their own inventory. And yeah, each command would *have* to be
preceded with a "switch player" command. You'd have to tailer the game's
output to make sense with that kind of frequent change going on, but if
you're writing something to be multiplayer, I guess that would just be part
of it.

> I want to have a quick solution that works, tolerating technical
> imperfections. A Z-Machine runs so fast, performance is really not an
> issue here. So we can take the Z-Machine and "abuse" it to the limits.

It would have to stay resident, and you'd be servicing one game at a time. I
guess if you had multiple copies of the game running, and the "wrapper" knew
which one to talk to, you could handle multiple games at once. You're
thinking of the game running server-side, right? Or do you want a
client-side wrapper that actually comminicates to the other players? You'd
have to duplicate each player's commands and hide the output...

> If I'd write my own engine, then I would be busy for years and get a
> result that is way worse than I7. Plus, when using I7, You already have
> loads of authors who are perfectly familiar with the programming language.
> Traditional MUDs require You to learn a - to my mind - really creepy
> programming language.

Writing a multiplayer game is different than writing a single-player one.
With my StarLock engine (multiplayer), I ended up doing so much of it as
single-player quests that all the multiplayer power is limited to things
like virtual billiards, auctions, and chat. To *really* take advantage of a
multiplayer adventure, you have to think in that mindset.

> You mean a kind of I7-to-MUD-language cross converter? Might be an idea. I
> would need to take the I7 parser as a base. And I'm not sure if it can be
> bended easily for such a task. In fact, I doubt it. Probably, it is
> strongly connected with the Z machine and the Inform base library.

No. I meant write a game using a MUD. Basically... a MUD...

> Another way would be introspection: You have a process running the single
> player adventure. It turns on the "god" mode and walks through the whole
> game world, thereby re-creating it as a set of MUD files. However, with
> that, one would be missing all the algorithms defined in the code.

No, that's not what I was thinking at all...

> Well, maybe some kind of I7 cross compiler would be great. But the
> compiled Z code could not serve as a source format for such a cross
> compiler, so we would need to start at the I7 source and convert it to
> LPC, for example. My, that would be a task!

Your original idea makes more sense, though. If the game had some
meta-command output -- i.e. you put [P1] at the beginning of anything only
to be seen by player 1 and end it with [/P1], your wrapper could filter out
what's shown based soley on the player. You could handle your entry-exit
text that way. You'd just print multiple lines enclosed in meta tags of use
only by the wrapper. And like you say, you'd have a "switch player" command
required before *every* player-supplied command.

I guess, though, that when I think about multiplayer games, I want something
more visual. The *idea* of multiplayer command-only IF doesn't have a big
appeal to me personally.

---- Mike.


Mike Snyder

unread,
Jun 19, 2007, 10:42:09 AM6/19/07
to
"Mike Snyder" <wy...@prowler-pro.com> wrote in message
news:AQRdi.279$Zg5...@newsfe19.lga...

>
> It would have to stay resident, and you'd be servicing one game at a time.
> I guess if you had multiple copies of the game running, and the "wrapper"
> knew which one to talk to, you could handle multiple games at once. You're
> thinking of the game running server-side, right? Or do you want a
> client-side wrapper that actually comminicates to the other players? You'd
> have to duplicate each player's commands and hide the output...

You wouldn't even need a wrapper, probably. With source code to Z-machine
interpreters available -- or GLK libraries -- you'd just need to write in
what you need for i/o.

---- Mike.


Matthew Wightman

unread,
Jun 19, 2007, 11:29:09 AM6/19/07
to
On 19 Jun, 13:10, Madoc <MadocD...@gmail.com> wrote:

> My main interest would be adding
> multi-player support to Inform 7. That would just rock! (Do You know if any
> such project already exists? I am sure that I am not the only one with that idea.)

IIRC, there was an extension for earlier versions of Inform
(multifloyd.h?) which did a lot of what you are suggesting, using a
bot on ifMUD as the players' interface to the game.

--
Matthew.

Mike Rozak

unread,
Jun 19, 2007, 7:34:07 PM6/19/07
to
My scripting is more like C++ (not NLP like Inform 7), but I have been
working on multiplayer (graphical) interactive fiction for awhile. See
http://www.CircumReality.com . It's up and running. It may (or may not) be
what you're looking for.

"Madoc" <Mado...@gmail.com> wrote in message

news:f58o98$1304$2...@sxnews1.qg.com...

Stephen Gilbert

unread,
Jun 20, 2007, 10:53:32 AM6/20/07
to

You might want to take a look at Zinc (Z-Machine Interpreter with Network
Capabilities -- http://zinc-if.sourceforge.net/). It's a rather unusual
interpreter in that it has several multi-player options that can be used
for single-player games. It's rather different from what you're
describing, but the source code is available if you want to play with it.

Madoc

unread,
Jun 20, 2007, 11:35:45 AM6/20/07
to
> My scripting is more like C++ (not NLP like Inform 7), but I have been
> working on multiplayer (graphical) interactive fiction for awhile. See
> http://www.CircumReality.com . It's up and running. It may (or may not)
> be what you're looking for.

I am really thankful for Your suggestion, but I'm afraid that this is not what
I am looking for. It's exactly the elegance of NLP in I7 that I appreciate and
want to keep. Since it would be impossible to re-engineer this (and always keep
it up-to-date with I7 developments), I am searching for a way to make the
*EXISTING* I7 multiplayer-ish.

Madoc

unread,
Jun 20, 2007, 11:53:13 AM6/20/07
to
> I think you'd end up tailoring it to the specific input and output you
> expect, or you'd have to require certain meta-output to trigger the
> "wrapper" to take an action: for instance, room entry and exit commands that
> the game couldn't otherwise handle without true multiplayer features.

> Yeah, that would let you handle different players in different rooms


> containing their own inventory. And yeah, each command would *have* to be
> preceded with a "switch player" command. You'd have to tailer the game's
> output to make sense with that kind of frequent change going on, but if
> you're writing something to be multiplayer, I guess that would just be part
> of it.

Exactly! Except that, for room entry/exit/etc., no "outside interference" would
be required. For such a case, I imagine the internal input directed to the
Z-machine like this:

switch to connection 3
west

So, the connection number of the player who goes west is 3. Let's say there are
two other players in the tavern, with connection numbers 4 and 6. So, the
Z-machine could look like this:

<CONN#3>
You enter the tavern.
<CONN#4>
Sir Foo comes in.
<CONN#5>
Sir Foo comes in.

The wrapper manages all the connections, without even knowing which player is
connected to which connection. It just redirects the output of the Z-machine to
the "current connection". If the Z-machine output stream contains a command in
the form of "<CONN#4>", on a single line, the redirection is changed to the
connection with that number. Should be quite simple.

I tried around a little with I7. It is pretty easy to have such output by the
use of the "Before" and "After" commands. However, as far as I can tell, one
would need to add such behaviour for ALL of the standard library actions which
can be seen by other players. That means typing many many similiar looking
lines of code. But it's not impossible.

(Maybe, one could optimize this. I could make a generic "Before" and "After",
called for every action. It could use a table to look up what to tell the other
players.)

> It would have to stay resident, and you'd be servicing one game at a time. I
> guess if you had multiple copies of the game running, and the "wrapper" knew
> which one to talk to, you could handle multiple games at once. You're
> thinking of the game running server-side, right?

Yes, right.

> Or do you want a
> client-side wrapper that actually comminicates to the other players? You'd
> have to duplicate each player's commands and hide the output...

Whooo, I think that idea scares me. Well, at least this variant would not open
up the question of server hosting.

> Writing a multiplayer game is different than writing a single-player one.
> With my StarLock engine (multiplayer), I ended up doing so much of it as
> single-player quests that all the multiplayer power is limited to things
> like virtual billiards, auctions, and chat. To *really* take advantage of a
> multiplayer adventure, you have to think in that mindset.

Yes, and that is also the reason why 99% of the single player I7 adventures
would not work for multi player, even if they would be compatible to the
multiplayer library. Anyway, maybe some interesting works of IF could be
modified to support many players. And all the IF authors who are already
familiar with I7 could participate and would not need to change a thing about
their coding habits. (Except for sometimes adding a command like "Tell
others..." to their code.) They could even take the code of their unfinished
adventures, and integrate some regions of it to the multi player IF.

> No. I meant write a game using a MUD. Basically... a MUD...

Well, MUDs already exist! ;-)

>> Another way would be introspection: You have a process running the single
>> player adventure. It turns on the "god" mode and walks through the whole
>> game world, thereby re-creating it as a set of MUD files. However, with
>> that, one would be missing all the algorithms defined in the code.
>
> No, that's not what I was thinking at all...

Anyway, conserving the game state would be a real problem. Just "save" to an
Inform standard savefile does not suffice. What if the server gets updated? I
expect this to happen quite often. Every time a programmer changes the code,
the server would need to be updated. Inform savefiles would be incompatible
with the new version.

> I guess, though, that when I think about multiplayer games, I want something
> more visual. The *idea* of multiplayer command-only IF doesn't have a big
> appeal to me personally.

I used to be a MUD player, and I still love the idea. But the standard MUD
programming languages are just so bad, they are in no way a match for the
elegance of I7. That's why I could never again write something for a MUD.
Unless of course, it would be an I7 MUD! ;-)

Madoc

unread,
Jun 20, 2007, 11:56:06 AM6/20/07
to
> You wouldn't even need a wrapper, probably. With source code to Z-machine
> interpreters available -- or GLK libraries -- you'd just need to write in
> what you need for i/o.

Yes! I am currently thinking of Java, so I could take one of the Java Z-Machines.

Thinking again, my web hoster only supports PHP, Perl and Ruby. So maybe I
could look out for a Z-machine implementation in one of those languages. It's
funny: In this case, the "wrapper" does the least part of the logic - merely
taking connection an managing the I/O flow between them and the Z-machine. Once
there is an implementation of it, it should be fairly easy to port it to any
other programming language. The big part is the Z-machine, and that is
completely abstracted and portable. The idea appeals to me more and more.

Madoc

unread,
Jun 20, 2007, 11:56:49 AM6/20/07
to
> IIRC, there was an extension for earlier versions of Inform
> (multifloyd.h?) which did a lot of what you are suggesting, using a
> bot on ifMUD as the players' interface to the game.

Thanks for Your advice! I will see when I get the time to research that one.

Madoc

unread,
Jun 20, 2007, 11:57:34 AM6/20/07
to
> You might want to take a look at Zinc (Z-Machine Interpreter with Network
> Capabilities -- http://zinc-if.sourceforge.net/). It's a rather unusual
> interpreter in that it has several multi-player options that can be used
> for single-player games. It's rather different from what you're
> describing, but the source code is available if you want to play with it.

Thanks! It contains a pretty slim Z-Machine implementation in Java. I think I
could maybe reuse it.

Benjamin Caplan

unread,
Jun 22, 2007, 9:43:24 AM6/22/07
to
Perhaps what you want is a normal MUD whose programming language is a
superset of Inform 6. That way, you can integrate multiplayer
functionality tightly and efficently into the virtual machine, while
taking advantage of the I7 preprocessor to code your world in Natural
Inform.
It might take the most work to set up of all the suggestions so far,
but it may turn out to be worth it in the long run.

Madoc

unread,
Jun 22, 2007, 10:05:28 AM6/22/07
to

Do You know if any such MUD driver exists?

Benjamin Caplan

unread,
Jun 24, 2007, 5:56:41 PM6/24/07
to
> > Perhaps what you want is a normal MUD whose programming language is a
> > superset of Inform 6.
> Do You know if any such MUD driver exists?
Not that I'm aware of. My intent was to advocate its creation. If MUD
programming syntax commonly is as bad as was suggested earlier in this
thread, then I expect an I6 MUD base may find considerable usage in
the broader MUDding community.

Madoc

unread,
Jun 25, 2007, 5:04:42 AM6/25/07
to
> Not that I'm aware of. My intent was to advocate its creation. If MUD
> programming syntax commonly is as bad as was suggested earlier in this
> thread, then I expect an I6 MUD base may find considerable usage in
> the broader MUDding community.

Whether MUD programming is bad or not is obviously a question of taste. I
really hate LPC, but I understand those who like it. At least, there is a
huge difference in "thinking style" between I7 and LPC. I think it is so
big that You would hardly find any I7 fan who would gladly code in LPC.

When MUD programming could be done in I7, the underlying MUD driver really
would not matter for the Inform source code which describes the game world
and logic. It should be 99% of what is already there in I7, plus a few very
limited additions for multiplayer support.

I think "abusing" a single-player Z-machine for multiplayer, in the way I
described, would be a good start. Of course, if this would work out well
and find a greater audience, one would need to code a better driver, which
is more clean and has less of the "hack" feeling.

Reply all
Reply to author
Forward
0 new messages