Multiplayer IF - A specification
David A. Cornelson
the z-machine.
In order to create MPIF, the language and z-machine would have to support an
indirect I/O methodology. This is mostly done already it seems with the
relationship between the z-code data file and a z-machine interpreter
program.
The part that's missing is that instead of one direct output to one
interpreter, we probably need to be able to send a single output that
contains information that can then be sent to multiple interpreters.
Z-Code File --> Central Z-Machine Interpreter <--> Client Interface {2..n}
So instead of outputing...
print_ret "Why don't you just walk like normal people?"
...you would have to do something like...
response 0:print_ret "Why don't you just walk like normal
people?";1:print_ret "Joe jumps around, looking like a fool.";2:~rfalse
I guess there's likely some z-machine code we could reuse as a responder
routine that get's disseminated by the CZMI object and then sends the proper
z-code response to each client. I'm not sure what would be appropriate.
This all assumes that some library of functionality is available to produce
MPIF responses. I forsee some centralized daemon or property that's thrown
into the main loop. The trick is how to process commands. We have to
differentiate between a direct command from one of the PC's as opposed to a
reaction to another PC's command. In some cases, the reaction may precede
the action.
*** your screen (playing a turtle) ***
> GET FLAG
The Rabbit, being vastly superior in speed and agility to you, recognizes
your intent and grabs the flag before you take even one step.
*** another screen (playing the rabbit) ***
You notice the turtle spying the checkered flag and before he has a chance
to blink, you've got the flag in your teeth.
In most cases the acion will precede any reaction from other players.
Do we implement this as simply an addition to the REACT_BEFORE/REACT_AFTER
routines or do we add OTHERS_REACT_BEFORE and OTHERS_REACT_AFTER?
It probably doesn't matter from a technical point of view, but from a
programmer's pov, it might make more sense to incorporate separate routines
for MPIF coding.
So then as an author I would have to do the following:
Object Flag "checkered flag"
with name 'checkered' 'flag',
description "The checkered flag is a smallish cloth with
interlaced black
and white squares.",
!
! I can only think of a 'respond' routine to possibly stack the
responses for when the
! turn is complete.
!
others_react_before
[opc; playerloop (opc) {
take: if (player == turtle && opc == rabbit) { ! probably use a switch
for 3+ players
move flag to rabbit;
respond(player,"You notice the turtle spying the
checkered flag and before he has
a chance to blink, you've got
the flag in your teeth.);
respond(rabbit,"You notice the turtle spying the
checkered flag and before he has
a chance to blink, you've got
the
flag in your teeth.");
rtrue;
}
!
! Don't really need to have an else in this case
since the rabbit is
! allowed to directly take the flag or if the rabbit
isn't around
! to block the turtle from retrieving the flag
himself.
!
}
],
before
[; if (player == rabbit) {
move flag to rabbit;
respond(rabbit,"You take the flag.");
if (turtle in location) {
respond(turtle,"You watch helplessly as the rabbit
grabs the flag.");
else
respond(turtle,null); ! null is no response to that
players client
rtrue;
}
],
The respond routine probably should automatically return to the CZMI if all
responses have been dtermined.
* * * * * *
I think this is only a preliminary pass and there are many questions left
open. I'm just trying to build a reasonable solution for MPIF.
Another issue would be technical architecture. I'm addressing this in
another document, but the thought that ocurred to me would be a veneer
z-code interpreter that connects to some server
java-applet-interpreter-controller.
So the applet would take over loading the game and intitiating input. Output
would come in the form of my response() code and the applet would then
deconstruct the responses for each client and send them back accordingly. It
would then wait for another command. Commands would be interpretted as they
come in. I wouldn't even get into some interpretation of when commands come
in. Although it might be nice to check the time after a responde to the time
of a received command. If a command came in before a response, then it might
be prudent to ignore it or have a late_command routine in Inform so that the
author can handle it themselves.
Each client would also have an event handler. The event handler would be
kicked off when a response is coming back but no command was given. Null
commands wouldn't fire an event for that client. This would be like changing
the state of the game for a player without them knowing it, which is part of
the potential beauty of MPIF.
* * * *
Anyway - a lot of thinking there and no spec....I just wanted to see what
sort of response I would get.
Jarb
David Given
"David A. Cornelson" <dcorn...@placet.com> writes:
> I'm building a specification for multi-player interactive fiction based on
> the z-machine.
>
> In order to create MPIF, the language and z-machine would have to support an
> indirect I/O methodology. This is mostly done already it seems with the
> relationship between the z-code data file and a z-machine interpreter
> program.
Have you thought about the asynchronous aspects of multiplayer IF? I mean by
this in that the different players may be entering commands at different rates.
While player #1 is still typing something in, player #2 may have walked into
the room, picked something up, hit player #1 with it, and left. How are you
going to portray this to the players?
And how would you implement it in the Z-machine? The whole structure of the
Z-machine is based around a single execution thread. It sits and waits for
input, does something, and sits and waits again. What would you do about
multiple input?
--
+- David Given --------McQ-+ "There is // One art // No more // No less // To
| Work: d...@tao-group.com | do // All things // With art // Lessness." --- Piet
| Play: d...@cowlark.com | Hein
+- http://www.cowlark.com -+
David A. Cornelson
news:v706s9...@172.16.100.66...
> In article <tu8kb7...@corp.supernews.com>,
> "David A. Cornelson" <dcorn...@placet.com> writes:
> > I'm building a specification for multi-player interactive fiction based
on
> > the z-machine.
> >
> > In order to create MPIF, the language and z-machine would have to
support an
> > indirect I/O methodology. This is mostly done already it seems with the
> > relationship between the z-code data file and a z-machine interpreter
> > program.
>
> Have you thought about the asynchronous aspects of multiplayer IF? I mean
by
> this in that the different players may be entering commands at different
rates.
> While player #1 is still typing something in, player #2 may have walked
into
> the room, picked something up, hit player #1 with it, and left. How are
you
> going to portray this to the players?
>
> And how would you implement it in the Z-machine? The whole structure of
the
> Z-machine is based around a single execution thread. It sits and waits for
> input, does something, and sits and waits again. What would you do about
> multiple input?
>
I would move the z-code interpreter into a centralized object that multiple
clients attach to...this object would also be a 'game manager' handling
saving, starting, responding, etc...
It has to be synchronous.
Jarb
Robin Rawson-Tetley
but IAGE has been doing (quite capably) what you are talking about for the
last 2 years (afraid you will have to learn a new language though, but it
isn't that difficult)...
www.robin.rawsontetley.btinternet.co.uk/iage/
"David A. Cornelson" <dcorn...@placet.com> wrote in message
news:tu8kb7...@corp.supernews.com...
David A. Cornelson
news:9sekii$8v7$1...@plutonium.btinternet.com...
> Um... I know it's not a Z machine and a lot of people really like Inform,
> but IAGE has been doing (quite capably) what you are talking about for the
> last 2 years (afraid you will have to learn a new language though, but it
> isn't that difficult)...
>
> www.robin.rawsontetley.btinternet.co.uk/iage/
>
Right, well, I looked at it before and again just now. The whole reason for
supporting MPIF through Inform is that with a few seemingly minor
technological achievements, people could begin to write MPIF in a short
period of time. There's also a great deal of supporting code and authors for
Inform.
The IAGEScript is really a step backward programming-wise and I for one am
unwilling to take that step. I'd rather do single-player IF than MPIF in
IAGE. (sorry, yes, I'm an Inform snob...oh well...)
Jarb
David Given
> I would move the z-code interpreter into a centralized object that multiple
> clients attach to...this object would also be a 'game manager' handling
> saving, starting, responding, etc...
Hmm.
Well, meaning no offense, but you're going to have to end up changing the
Z-machine and library beyond all recognition anyway, so if I were you I'd
base the engine on something more suited to multi-user games. The
LambdaMOO engine, for example, is a really good system designed around
multiple incoming socket connections. The language is fairly similar to
TADS with lists, garbage collection, object orientism etc, and it has
socket support built in. The whole system is persistent so you never have
to worry about loading and saving data to disk. I've written a multi-user
web game in pure Lambda code (Stellation), and it worked very nicely
The existing databases for LambdaMOO are mostly designed for MUDs, but it
would be perfectly possible to build a more game-based one.
--
+- David Given --------McQ-+ "USER'S MANUAL VERSION 1.0: The information
| Work: d...@tao-group.com | presented in this publication has been carefully
| Play: d...@cowlark.com | for reliability." --- anonymous computer hardware
+- http://www.cowlark.com -+ manual
David A. Cornelson
> In article <tue67t6...@corp.supernews.com>,
> "David A. Cornelson" <dcorn...@placet.com> writes:
> [...]
> > I would move the z-code interpreter into a centralized object that
multiple
> > clients attach to...this object would also be a 'game manager' handling
> > saving, starting, responding, etc...
>
> Hmm.
>
> Well, meaning no offense, but you're going to have to end up changing the
> Z-machine and library beyond all recognition anyway, so if I were you I'd
> base the engine on something more suited to multi-user games. The
> LambdaMOO engine, for example, is a really good system designed around
> multiple incoming socket connections. The language is fairly similar to
> TADS with lists, garbage collection, object orientism etc, and it has
> socket support built in. The whole system is persistent so you never have
> to worry about loading and saving data to disk. I've written a multi-user
> web game in pure Lambda code (Stellation), and it worked very nicely
See, a mud is not the right thing for IF. I don't want any number of people
connecting to the game. I want a game to be played among an exact number of
people. So if a particular game expects 2 people, then that's all the
architecture will allow to connect to that game. First person picks a
character and second person is automatically given second character.
I don't want a chat environment either. If you play the game, mimesis must
be maintained. You don't know what the other person is doing unless it's on
the screen handled by the author of the game.
Jarb
Robin Rawson-Tetley
to be a portable, simple to learn language.
If people let me know what they don't like, I can work on it - if
everyone keeps shtumm, then I'm just wasting my time.
Cheers,
Robin
"David A. Cornelson" <dcorn...@placet.com> wrote in message news:<tultjsd...@corp.supernews.com>...
David Given
> connecting to the game. I want a game to be played among an exact number of
> people. So if a particular game expects 2 people, then that's all the
> architecture will allow to connect to that game. First person picks a
> character and second person is automatically given second character.
>
> I don't want a chat environment either. If you play the game, mimesis must
> be maintained. You don't know what the other person is doing unless it's on
> the screen handled by the author of the game.
As I said, Lambda is a MUD *engine*. It provides the programming language,
multitasking VM, persistent object store, socket support, basic parsing,
etc. It doesn't provide any MUD functionality, that's all done in
LambdaCode in the database. As I said, by writing a custom database I
turned it into a web server.
It's ideal for what you want to do, and is seriously worth a look.
My game is here, and shows how to do a custom database and reinvent the
MOO completely (also contains some useful utility classes):
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/stellation/stellation/
And here's the Lambda engine's programming manual:
http://tecfa.unige.ch/guides/MOO/ProgMan/ProgrammersManual_toc.html
--
+- David Given --------McQ-+ "When an irresistable force meets an immovable
| Work: d...@tao-group.com | object, the result is a family fight." --- Diana
| Play: d...@cowlark.com | Wynne Jones, _Archer's Goon_
+- http://www.cowlark.com -+
David Cornelson
> In article <tuonj6s...@corp.supernews.com>,
> "David A. Cornelson" <dcorn...@placet.com> writes:
>
> As I said, Lambda is a MUD *engine*. It provides the programming language,
> multitasking VM, persistent object store, socket support, basic parsing,
> etc. It doesn't provide any MUD functionality, that's all done in
> LambdaCode in the database. As I said, by writing a custom database I
> turned it into a web server.
>
> It's ideal for what you want to do, and is seriously worth a look.
>
Okay. This is all nice and probably worth looking at for someone
that's more interested in MPIF than Inform-MPIF. But I'll make this
clear. I'm interested in extending, in particular the Inform language,
to MPIF.
I'm not interested in MOO programming. I don't want to create MPIF for
the sake of MPIF and have everyone play my one game and say, "Wow.
That was cool, too bad you have to learn a new language and all this
MOO stuff to make one of these games. If it were some easy extensions
to Inform, I would do one of these too."
Where IF is concerned I'm a centrist. I'll stray a bit here and there,
but because of my lack of time and technical ability, I can't stray
too far. I have to try to build upon what's already 'standard IF'.
Jarb
Kevin Forchione
news:1f688a41.0111...@posting.google.com...
> Where IF is concerned I'm a centrist. I'll stray a bit here and there,
> but because of my lack of time and technical ability, I can't stray
> too far. I have to try to build upon what's already 'standard IF'.
When did multiplayer become centrist? Or even considered straying "a bit"? I
must have woke up in an alternate universe. ;)
--Kevin
David A. Cornelson
news:N3WH7.1589$RG1.9...@news1.rdc1.sfba.home.com...
I think you misunderstood me. Inform is centrist. MOO programming is not. If
one were to use one of these tools to create MPIF, then starting with Inform
would seem to make more sense from a centrists point of view than using MOO.
Jarb
Kevin Forchione
news:tv0ia9a...@corp.supernews.com...
> "Kevin Forchione" <ke...@lysseus.com> wrote in message
> news:N3WH7.1589$RG1.9...@news1.rdc1.sfba.home.com...
> > "David Cornelson" <dcorn...@placet.com> wrote in message
> > news:1f688a41.0111...@posting.google.com...
> > > Where IF is concerned I'm a centrist. I'll stray a bit here and there,
> > > but because of my lack of time and technical ability, I can't stray
> > > too far. I have to try to build upon what's already 'standard IF'.
> >
> > When did multiplayer become centrist? Or even considered straying "a
bit"?
> I
> > must have woke up in an alternate universe. ;)
>
> I think you misunderstood me.
No, just giving you grief ;) I can't disagree with your arguments.
--Kevin
Robin Rawson-Tetley
and I think you have a very fair point.
When designing the language, I deliberately made it very easy for the
server to compile to it's bytecode and such that it was efficient when
it got there. Problem is, it's not very nice for human beings to
program :)
To address this problem, I have built a new compiler program for IAGE
which operates separately from the IDE (there is no need for the IDE
at all if you don't want it) and compiles text files. The new language
works incredibly like Inform for syntax and keywords, and uses the
Inform library conventions (no more of that using _ in expressions and
^ in strings malarkey).
It also allows object inheritance, classes and includes -- you no
longer need the whole template game thing, you simply import the IAGE
library in your source (sound familiar?)
It is currently undergoing testing and I hope to release it soon. I am
also working on documentation aimed at Inform programmers and how to
convert your existing Inform games to multiplayer games if you so
desire.
Does this sound interesting to anyone in the group?
Robin
David A. Cornelson
You've got my attention.
Jarb
David Thornley
David Cornelson <dcorn...@placet.com> wrote:
>d...@pearl.tao.co.uk (David Given) wrote in message news:<l8dos9...@172.16.100.66>...
>> In article <tuonj6s...@corp.supernews.com>,
>> "David A. Cornelson" <dcorn...@placet.com> writes:
>>
>> As I said, Lambda is a MUD *engine*. It provides the programming language,
>>
>>
>
>Okay. This is all nice and probably worth looking at for someone
>that's more interested in MPIF than Inform-MPIF. But I'll make this
>clear. I'm interested in extending, in particular the Inform language,
>to MPIF.
>
in adapting Inform for multi-player use. My guess is that the hard
part is going to be in handling interactions between the players,
which is not what Inform was designed for.
>I'm not interested in MOO programming. I don't want to create MPIF for
>the sake of MPIF and have everyone play my one game and say, "Wow.
>That was cool, too bad you have to learn a new language and all this
>MOO stuff to make one of these games. If it were some easy extensions
>to Inform, I would do one of these too."
>
Unfortunately, I really, really doubt there is going to be an easy
extension to Inform. It is likely that, when you're through,
you'll have something that needs a special interpreter and requires
at least as much getting used to as a MOO language.
I could of course be wrong, but that brings me to the next point....
>Where IF is concerned I'm a centrist. I'll stray a bit here and there,
>but because of my lack of time and technical ability, I can't stray
>too far. I have to try to build upon what's already 'standard IF'.
>
Multi-player is *not* something dealt with by an IF centrist.
Once you're off after that, you're no longer a centrist for the
purposes of that project.
Moreover, if you have a lack of time and technical ability, I
think you'll have a great deal of difficulty getting multi-player
to work well in the first place, unless you start with something
already multi-player. What you produce is likely to be awkward
and buggy. If you lack the time and ability to deal with all
the unforeseen problems, then I would strongly suggest you start
with a MOO or something.
If nothing else, possibly you can convince Inform to compile
to whatever language the MOO uses, and that might be a good
way to avoid the technical difficulties. It will mean that
you're going to have to figure out how to best extend Inform,
but you're already committed to that.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David A. Cornelson
news:gxBI7.3395$H7.16...@ruti.visi.com...
> In article <1f688a41.0111...@posting.google.com>,
> David Cornelson <dcorn...@placet.com> wrote:
> >d...@pearl.tao.co.uk (David Given) wrote in message
news:<l8dos9...@172.16.100.66>...
> >> In article <tuonj6s...@corp.supernews.com>,
> >> "David A. Cornelson" <dcorn...@placet.com> writes:
> >>
> >
> Unfortunately, I really, really doubt there is going to be an easy
> extension to Inform.
> Moreover, if you have a lack of time and technical ability, I
> think you'll have a great deal of difficulty getting multi-player
> to work well in the first place, unless you start with something
> already multi-player.
I don't lack the technical ability as much don't have time to do things.
However, I have a perfect understanding of what technologies are involved,
what code is involved, and what code needs to be modified. I'm trying to lay
it all out so that I can garner interest from others in the Inform/C++ camp
to join my vision.
The parts that are unclear are how the central MPIF game manager would talk
to the client and the game. The game is probably easier than the clients
since Inform is a capable language and there are ways to talk to it in such
a way that the game moves forward, but commands are used that wouldn't
resemble normal game play. There would likely have to meta MPIF verbs built
into a library of sorts.
On the client side things may actually be very easy. Create a WinFrotz type
application that doesn't execute the z-machine, but handles z-machine output
and communicates via tcp/ip with the MPIF game manager.
You see, I do understand what I'm trying to accomplish.
Jarb
Robin Rawson-Tetley
>
> Jarb
Great - the libraries and compiler have been ready for a week or so
now (still being rigorously tested as we speak). Documenting
everything is taking time, but I'm hoping to get everything uploaded
in the next few days (I reckon I'm about 70% through the docs).
Drop me a line if you are interested in looking at a pre-release. I
also have a (largely incomplete) multiplayer Zork port which I could
post the source code for if anyone is interested in seeing how the
Informesque language looks.
Cheers
Bob