SSM, IF on the Web (and elsewhere)
Henning Strandin
This is a follow-up to my question/thread about Text Adventures on the
Web (note that I have now learnt to say IF :-). I have thought a bit
about different approaches to this and thought that my new take could
have a more general interest.
This is what I would suggest:
Put a new mode in an existing IF engine (SSM = Standard Stateless Mode),
for example activated by using a switch on the command line. In this
mode, the engine would accept a complete set of variable settings,
together with normal input (e.g. 'go west') to STDIN, and would dump the
new state together with normal output to STDOUT. The input could be
formated to resemble an HTTP-header, i.e.:
Variable1=Value\n
Variable2=Value\n
Variable3=Value\n
\n # Header and body separated by an empty row
go west
<EOF>
Values containing newlines could be quoted, URL-encoded (yuck) or the
newlines could be escaped using some preceding whitespace (according to
the HTTP spec). I think I'd prefer normal quoting.
If the engine recieves an empty header it assumes that this is the first
round of the game and that all variables have their initial values.
Since all of the engines support saving state to disk today (saving the
game) this would seem to be doable, no?
With a mode like this, it would be the proverbial piece of a cake to
write a perl front-end to a web site. One could of course also write a
python front-end, tcl front-end etc etc. This mode could probably be
used for all kinds of things that I haven't thought about at all.
It would be the front-ends responsibility to save the state to a file
and mark it up in a way so that each player transparently uses his own
state-file. This is trivially done using a cookie, hidden input fields
(or both) maybe together with a login procedure (for when you change
computer or lose your cookie between sessions).
The coolest thing would of course be if most of the IF-engines supported
SSM so that exactly the same front-end could be used for any one of
them, and you just set what engine to use depending on what game you
would like to publish on your site.
With something like this, a standardized front-end would hardly be
crucial though, since hacking together one would be so trivial, and you
could take advantage of this by writing a specific front-end supporting
any special stuff that you would like your site to include. However, I
would definitely enjoy writing a first implementation of the front-end,
with a few design specifics that I think are worthwhile. For example, I
would inklude event triggers in the front-end, so that the game easily
could interact with external systems when certain predefined criteria
are met. This could include sending out an email or use some external
web-resource like a dictionary, or up-to-date statistics of some form
retreived from a web site. This way games could be specifically written
for web publication that could take advantage of the web's endless
possibilities for communication and information retreival.
Now, if there is some general interest in this idea, I will contact the
authors of the most popular engines (suggestions welcome) to see if they
think that tis can be done, and if they would be interested/have the
time to help out, and in what way. Anyone who would like to contribute
to this project could contact me at hen...@travellab.com and I will
have a web page with information up in no-time. C programmers willing to
have a look at the existing engine code are especially welcome, in case
the original authors can't spare the time for a modification like this.
Happy Gaming
Henning
--
"The world will little note nor long remember what we say here."
- A. Lincoln
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Henning Strandin
Henning Strandin <hen...@travellab.com> wrote:
> Put a new mode in an existing IF engine (SSM = Standard Stateless
Mode),
> for example activated by using a switch on the command line. In this
> mode, the engine would accept a complete set of variable settings,
> together with normal input (e.g. 'go west') to STDIN, and would dump
the
> new state together with normal output to STDOUT. The input could be
> formated to resemble an HTTP-header, i.e.:
>
> Variable1=Value\n
> Variable2=Value\n
> Variable3=Value\n
> \n # Header and body separated by an empty row
> go west
> <EOF>
>
I just realized a few things. Bidirectional piping is almost impossible
in perl (it's a hassle at any rate), so a better way of doing this is:
STATELESS REQUEST-RESPOSPONSE PROCEDURE
1. Request (on command line):
<engine> -ssm <name of file containing state> <player command>
2. Engine returns:
<new state in saveable format>
\n
<game output>
<EOF>
3. Engine exits.
This is actually neater anyway because the engine exits after each
request, as it should. Also, this way the format that state is saved in
becomes transparent to the front-end programmer, he just saves whatever
comes in and uses what he's saved, so each engine could use whatever
format is most easily implemented (closest to how it saves games today I
guess). This said, I think plain text formats have much going for them
and an HTTP-header like format sure would be neat. Anyway, there is a
choice, and engines don't have to use the same format to be
interchangeable.
Henning Strandin
better to begin with). I guess it's better to put this new functionality
in a new alternative engine binary instead of enabling it with a CL
switch. Hence:
Procedure:
1. Request (on command line):
<engine> -gf <game file> -sf <state file> -pc <player command>
2. Response (to STDOUT):
<game state>
\n
<game turn output>
<EOF>
3. Engine exits
This suddenly implies things about game engine design in general, e.g.
that the engine back-end should be stateless in nature and concern
itself only with parsing the game file, the state data, evaluate player
commands and return the new state and game turn output, while it's up to
the front-end to keep state in any way it pleases (on disk, in memory
etc). Maybe this is how it works already, I'm not intimately familiar
with the design of the existing engines? If not, I'm not at all
suggesting a rewrite of an existing engine or anything. SSM would be a
high level interface that could (I hope and believe) be quickly
implemented.
Another thought regarding the format of the state data: If we would like
to add event triggers in the front end, to enable intercommunication
with other systems, the state data would have to be readable by the
front-end. This means that it's not as transparent as I suggested in my
last post, but it really would be valuable to the front-end designer to
be have access to state semantics. All it takes is that the data is in a
plaintext format or something easily converted to plaintext.
That's all for today. Promise ;-)
Joe Mason
> Ok, a few more clarifications (sorry, should've thought this through
> better to begin with). I guess it's better to put this new functionality
> in a new alternative engine binary instead of enabling it with a CL
> switch. Hence:
Definitely.
> This suddenly implies things about game engine design in general, e.g.
> that the engine back-end should be stateless in nature and concern
> itself only with parsing the game file, the state data, evaluate player
> commands and return the new state and game turn output, while it's up to
> the front-end to keep state in any way it pleases (on disk, in memory
> etc). Maybe this is how it works already, I'm not intimately familiar
> with the design of the existing engines? If not, I'm not at all
> suggesting a rewrite of an existing engine or anything. SSM would be a
> high level interface that could (I hope and believe) be quickly
> implemented.
All existing engines have a facility for saving/loading the game, so if you
send a standard save file over, the engine can simply treat it as three
commands:
>load [file]
>[player command]
>save [file]
The engine could be implemented as a wrapper around the standard engine,
which simply boots up the regular engine, executes these three commands, and
captures all the output (providing the engine writes to sio). Sounds like a
use for CheapGlk!
Joe
Admiral Jota
> Hi guys/gals,
> This is a follow-up to my question/thread about Text Adventures on the
> Web (note that I have now learnt to say IF :-). I have thought a bit
> about different approaches to this and thought that my new take could
> have a more general interest.
I know that this is probably no longer relevant, but I haven't seen anyone
else mention it, so I thought I'd point out this:
http://tjwww.stanford.edu/adventure/
It's a WWW-based implementation of Advent, which stored the game state in
the URL (which can then be easily bookmarked). It may or may not be of
interest to you.
--
_/<-= Admiral Jota =->\_
\<-= jo...@tiac.net =->/
wyndo
> else mention it, so I thought I'd point out this:
> http://tjwww.stanford.edu/adventure/
> It's a WWW-based implementation of Advent, which stored the game state in
> the URL (which can then be easily bookmarked). It may or may not be of
> interest to you.
This looks like a stand-alone game. It would be nicer to work off an existing
engine (or at least use an engine that could have new games plugged into it).
The implementation is kind of how I imagine it. It looks like it's compatible
with most browsers (even non-framed ones). I'd like to see it work with
graphic illustrations, frames, etc.
I am planning to develop what I'm describing, either as a port to an existing
engine, or as my own. I'll announce more most likely after the IF Competition.
Mike.
Henning Strandin
This sounds right. It would be one (possibly the simplest) way of
implementing SSMI. I will have a good look at Glk right now. By the way,
my motivation for doing all this is of course that I have an idea for a
game that needs it. Putting it on the web is an integral part of what
the game is all about. I haven't been close to IF/text adventures since
'85 or so, so I have a lot of catching up to do. So this is basicaly
'learning by doing' :-)
Henning Strandin
implementing the 'first' part of SSMI. The second part is to make the
state file readable to the front end, to make it possible to extend the
game using event triggers for game events. I realize that this is the
hardest problem and I have no idea what data structures are used in the
different engines today. Nevertheless, I believe that this would be
extremely valuable.