[Announce] Flaxo, the Flash-based Z-Machine interpreter
Peter Mattsson
70% complete right now, but it's usable for most games (if you don't
mind the lack of save, restore, undo or restart functions).
Considering the comments in a couple of recent threads, I thought now
might be a good time to let it out into the wider world and let you
all play with it.
Try the demo at http://www.bespokerealities.com/FlaxoDemo.html and
tell me what you think!
Peter
P.S. I'm considering developing a "headless" version that uses
Javascript for output rather than the normal Flash window. This would
mean, among other things, that the display could be customised pretty
much as you like simply by adding the right Javascript functions to
your webpage. I could also adapt Flaxo to accept queries about the
game state (within the limits of what's easily extracted from the z-
machine state), to enhance the display. Would anybody be interested in
this and, if so, what information would you like to get at?
Emily Short
> Flaxo is a new, Flash 9-based Z-Machine interpreter. It's only about
> 70% complete right now, but it's usable for most games (if you don't
> mind the lack of save, restore, undo or restart functions).
> Considering the comments in a couple of recent threads, I thought now
> might be a good time to let it out into the wider world and let you
> all play with it.
>
> Try the demo athttp://www.bespokerealities.com/FlaxoDemo.htmland
> tell me what you think!
Gosh, this feels very smooth, and plays fast, at least on the demo
game. Just as a first impression, I like the look and feel better than
any of the other web-mounted z-machine interfaces I've seen so far.
I do miss scroll-back, though -- being able to see more than a single
screen of text is pretty critical from my point of view.
> P.S. I'm considering developing a "headless" version that uses
> Javascript for output rather than the normal Flash window. This would
> mean, among other things, that the display could be customised pretty
> much as you like simply by adding the right Javascript functions to
> your webpage. I could also adapt Flaxo to accept queries about the
> game state (within the limits of what's easily extracted from the z-
> machine state), to enhance the display. Would anybody be interested in
> this and, if so, what information would you like to get at?
The discussion over in Dave Cornelson's thread about an alternative
Glulx presentation might be relevant here too -- I could imagine using
imagery to enhance or replace the status line, or the ability to make
changes to the framing appearance of the game depending on what scene
was in progress, or any of a number of similar things.
Peter Mattsson
> Gosh, this feels very smooth, and plays fast, at least on the demo
> game. Just as a first impression, I like the look and feel better than
> any of the other web-mounted z-machine interfaces I've seen so far.
Thanks!
> I do miss scroll-back, though -- being able to see more than a single
> screen of text is pretty critical from my point of view.
Scroll-back is part of the 30% that isn't done yet :( It'll definitely
be in the finished version, though.
> The discussion over in Dave Cornelson's thread about an alternative
> Glulx presentation might be relevant here too -- I could imagine using
> imagery to enhance or replace the status line, or the ability to make
> changes to the framing appearance of the game depending on what scene
> was in progress, or any of a number of similar things.
I'd like to offer the facility to adapt the status line, but I'm not
sure how to do it without screwing up the other stuff that goes in the
upper window (like menus). So long as the upper window is only used
for status information, though, or the Javascript is tied to a
particular game, it should be quite do-able.
Another thought along these lines is that games could potentially use
one or more global variables to pass information to Flaxo (or any
other interpreter that wanted to know) that wouldn't otherwise be
easily accessible from the z-machine state, expanding the
possibilities.
Peter
George Oliver
>
> P.S. I'm considering developing a "headless" version that uses
> Javascript for output rather than the normal Flash window. This would
> mean, among other things, that the display could be customised pretty
> much as you like simply by adding the right Javascript functions to
> your webpage. I could also adapt Flaxo to accept queries about the
> game state (within the limits of what's easily extracted from the z-
> machine state), to enhance the display. Would anybody be interested in
> this and, if so, what information would you like to get at?
Wow, this is great!
It did seem to hang, though not consistently, on the first page of the
game -- I'm not sure if it really was a glitch or just a long load
time. Are you going to add some kind of load % bar to the official
release?
What about text and background style?
How easily could this be modified so that other people in their own
browsers could watch a session of a game that you're playing?
aaroni...@gmail.com
This is very cool, Peter!
The headless version is a cool concept, too. If I'm understand
correctly, that would mean the Flash applet is still running on the
page, just not in a visible window? Would it then do things like
update <div> contents, or would the Javascript have to be polling
something continuously?
Regardless it sounds very cool. The ability to extract data out of the
currently running game state would allow for all kinds of cool web-
based possibilities. I once wanted to make a virtual IF house for my
website, where different links, images, etc. appear around the main
window as you move through the house, but couldn't figure out a way to
do it at the time-- this technique might allow that to happen.
One robust solution might be to allow a Javascript to send a command
into the game--- say, "inventory". Flaxo could invisibly run this
command, send its output back to the Javascript, and then "undo" back
to the previous state. That would allow you to extract essentially any
information you wanted, by merely writing special commands into your z-
code game that could output it.
Regardless, this is already very cool. Keep us posted on developments!
--Aaron
denni...@gmail.com
to IE and it worked fine. The first thing I miss is scrollback.
I'd love to see some way of sending values into and out of the
program... of course I dream of a multiplayer version of IF, with
details about the shared game world stored in a MySQL database.
Could a Flash applet poll the status of the world state, so that, for
instance, an inventory window (in a Flash applet) could show inventory
images, and a conversation window could show portraits of characters
who are in the room? Set up the Flash screen with buttons pre-loaded
with commands, a la the graphic Zork series?
I'd be perfectly satisfied if it were necessary within I7 to
explicitly declare and update certain values that are accessible to
the outside world... I don't think it would be necessary for the Flash
wrapper to access every single thing that exists in the game world,
but obviously the location of objects, available exits, and standard
properties such as "open" or "closed" would be worth knowing.
Jeff Houck
Very, very cool Peter! Some friends and I were just discussing the idea
about using Flash in this manner the other day. Best of luck with this
and we'll surely be keeping an eye on this project!
Jeff Houck
> P.S. I'm considering developing a "headless" version that uses
> Javascript for output rather than the normal Flash window. This would
> mean, among other things, that the display could be customised pretty
> much as you like simply by adding the right Javascript functions to
> your webpage. I could also adapt Flaxo to accept queries about the
> game state (within the limits of what's easily extracted from the z-
> machine state), to enhance the display. Would anybody be interested in
> this and, if so, what information would you like to get at?
Yes! On both counts! I'd love to be able to both customize the interface
and access game state variables. Which ones? Any and/or all of them!
Andrew Plotkin
It's very difficult to extract anything from the Z-machine -- you'd
have to name explicit memory addresses to look at, and those change on
every compile.
(The BBC Hitchhiker's Guide UI did this, but they were dealing with a
legacy .z5 file that never got recompiled. Not the smoothest path for
newly developed games.)
By far the easiest way for Z-code to send out-of-band messages to the
interface is to use some custom markup. The game prints "You see a
troll here.<$TROLL_STATE_1$>" The interface recognizes the <$$> tags,
diverts that text (so that it doesn't go to the story window or
transcript), and then takes whatever Flash action.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
You don't become a tyranny by committing torture. If you plan for torture,
argue in favor of torture, set up legal justifications for torturing
someday, then the moral rot has *already* set in.
Eric Forgeot
> Flaxo is a new, Flash 9-based Z-Machine interpreter. It's only about
> P.S. I'm considering developing a "headless" version that uses
> Javascript for output rather than the normal Flash window. This would
really well done !
It's amazing to see the interpreter fits in only 23 kb.
A javascript version could be very interesting too.
I've updated our French website, which can now present all our games using
Flaxo ! (now people can choose between flash, java, and offline use with
some installed terp)
http://ifiction.free.fr/index.php?id=jeuflash&j=001 (from 001 to 030)
It's working well, the only annoyance is if the player clicks on the window
(I mean the flash window), it will loose the focus for typing, one can gain
it again only by clicking on the line with the prompt.
congratulation again.
Victor Gijsbers
> Try the demo at http://www.bespokerealities.com/FlaxoDemo.html and
> tell me what you think!
I loaded the page, but it doesn't seem to work with Gnash. (This means
that people who don't like to install Adobe's Flash binaries, which
involves accepting some rather dubious license agreements, can't use
Flaxo. As far as I know, Gnash is the most advanced free Flash alternative.)
Anyway, Gnash is under active development, so this problem might solve
itself.
Regards,
Victor
vaporware
> Here, Jeff Houck <jho...@northrim.net> wrote:
>
> > Peter Mattsson wrote:
> > > P.S. I'm considering developing a "headless" version that uses
> > > Javascript for output rather than the normal Flash window. This would
> > > mean, among other things, that the display could be customised pretty
> > > much as you like simply by adding the right Javascript functions to
> > > your webpage. I could also adapt Flaxo to accept queries about the
> > > game state (within the limits of what's easily extracted from the z-
> > > machine state), to enhance the display. Would anybody be interested in
> > > this and, if so, what information would you like to get at?
>
> > Yes! On both counts! I'd love to be able to both customize the interface
> > and access game state variables. Which ones? Any and/or all of them!
>
> It's very difficult to extract anything from the Z-machine -- you'd
> have to name explicit memory addresses to look at, and those change on
> every compile.
Well, there are a couple ways to simplify it:
1. Make a global array that starts out with a magic number and
contains, in some fixed order, whichever objects, property numbers,
arrays, or routines you want the UI to inspect. This is how Nitfol's
debugger works, IIRC. The drawback is it won't help you with global
variables.
2. Compile the game with -k and deploy gameinfo.dbg along with the
story file. The debug file contains everything the UI needs in a
format that's pretty easy to parse.
vw
Peter Mattsson
> It did seem to hang, though not consistently, on the first page of the
> game -- I'm not sure if it really was a glitch or just a long load
> time. Are you going to add some kind of load % bar to the official
> release?
It's not connected to the load time: by the time you see the first
page, everything's loaded. (There will, however, be a load % bar in
the finished version, for extra reassurance.) I don't /think/ it's
actually hanging on you, but rather it's not receiving focus (without
which it can't respond to keypresses). There seems to be a small bug
with the focus handling: to give it focus you have to click somewhere
on the text, not just anywhere in the window as you might expect. Does
it work if you do this? If not, could you tell me a bit about your
system, i.e.. what operating system, browser and Flash version are you
using? (To find out what Flash version you're using, go to
http://www.macromedia.com/software/flash/about/ and look in the
"Version Information" box.)
> What about text and background style?
The finished version will allow you to customise colours and fonts,
but I haven't got around to that yet. The issue of fonts is slightly
complicated by the fact that Flaxo has to download all the fonts it
uses (packaged as Flash files), which means it's restricted to fonts
with fairly open licenses (open enough to allow free internet
distribution). Flash /can/ use your local fonts, but renders them very
badly.
> How easily could this be modified so that other people in their own
> browsers could watch a session of a game that you're playing?
In principle this would be fairly easy, just a matter of modifying
Flaxo to send a copy of the transcript back to the server and writing
a small program to catch it and broadcast it to anyone who wants to
see. I'll certainly add it to the post-1.0 to-do list!
Peter
Peter Mattsson
> This is very cool, Peter!
Cheers!
> The headless version is a cool concept, too. If I'm understand
> correctly, that would mean the Flash applet is still running on the
> page, just not in a visible window? Would it then do things like
> update <div> contents, or would the Javascript have to be polling
> something continuously?
Yes, the Flash applet would be hidden. Flash programs can't modify the
page directly, but they can call Javascript functions, and vice versa,
so the display updating would be done by Javascript, invoked by Flaxo
as required. In return, Javascript functions could request information
from Flaxo about the game state.
> Regardless it sounds very cool. The ability to extract data out of the
> currently running game state would allow for all kinds of cool web-
> based possibilities. I once wanted to make a virtual IF house for my
> website, where different links, images, etc. appear around the main
> window as you move through the house, but couldn't figure out a way to
> do it at the time-- this technique might allow that to happen.
This is exactly the sort of thing I was hoping people could do, and
I'll do all I can to provide the facilities to do it. Depending on how
you feel about making a version of your game specially for Flaxo, it's
worth pointing out that it would be quite easy to allow HTML tags
embedded in the game text to be passed through and rendered by the
browser. Adding links and images would be as easy as adding the right
tags to your game text.
> One robust solution might be to allow a Javascript to send a command
> into the game--- say, "inventory". Flaxo could invisibly run this
> command, send its output back to the Javascript, and then "undo" back
> to the previous state. That would allow you to extract essentially any
> information you wanted, by merely writing special commands into your z-
> code game that could output it.
This is certainly an interesting thought, especially given that such
custom commands would be essentially invisible to other interpreters.
The only thing to remember is that doing too much of this might slow
things down, so it might be best to have one command that spits out
everything that's needed and leave it to Flaxo to parse the results.
> Regardless, this is already very cool. Keep us posted on developments!
Will do!
Peter
Peter Mattsson
> The opening screen froze in my Firefox browser (Windows). I switched
> to IE and it worked fine. The first thing I miss is scrollback.
I think this may be a focus problem rather than a real freeze; see my
reply to George Oliver earlier in the thread. Scrollback is No.1 on my
to-do list!
> I'd love to see some way of sending values into and out of the
> program... of course I dream of a multiplayer version of IF, with
> details about the shared game world stored in a MySQL database.
There are various ways of getting information out of the program (e.g.
embedding it in the output, as Zarf suggests), but getting
information /in/ is a little trickier, I think. The simplest way would
probably be either to set up a table at a known memory location
(storing that location in the header, for example), or to use a subset
of the global variables (if there are any spare). The main thing would
be to agree on a strategy, and on what sort of information to pass in
and out.
As for multiplayer IF, isn't that better-suited to a modified MUD
engine? It could be done after a fashion on the z-machine, I think
(e.g. by casting all the other players as NPCs and making them act
based on passed-in information about what the players are doing) but
you've still got the problem that the z-machine is basically turn-
based when you really want something that acts asynchronously.
>
> Could a Flash applet poll the status of the world state, so that, for
> instance, an inventory window (in a Flash applet) could show inventory
> images, and a conversation window could show portraits of characters
> who are in the room? Set up the Flash screen with buttons pre-loaded
> with commands, a la the graphic Zork series?
All of these things could be done, the only problem is that most of it
would require some support from the game: the information that can be
gleaned directly from the z-machine is rather limited.
> I'd be perfectly satisfied if it were necessary within I7 to
> explicitly declare and update certain values that are accessible to
> the outside world... I don't think it would be necessary for the Flash
> wrapper to access every single thing that exists in the game world,
> but obviously the location of objects, available exits, and standard
> properties such as "open" or "closed" would be worth knowing.
I think there are two possible approaches to this. One is to define a
standard set of information that is to be accessible to the outside
world and e.g. have games hold that information in a table for Flaxo
to access. The other is to do as Aaron suggests and add a special
command to your game whose function is to output all the information
you want to make available. If you used XML tags (e.g. <troll_pos>1</
troll_pos>), Flaxo could pass it on to external Javascript functions
quite easily. The advantage of this approach is that games could pass
out information that only made sense in the context of the game,
provided you wrote the Javascript to accept it and add it to your
webpage.
Peter
Peter Mattsson
> It's very difficult to extract anything from the Z-machine -- you'd
> have to name explicit memory addresses to look at, and those change on
> every compile.
I agree that it's difficult to extract much from the z-machine, but
can't you at least extract inventory information? I could well be
wrong, but I thought the child subtree of the player object
represented the inventory and that basic information about each item
(whether it is open, lit etc.) could be extracted from its attribute
flags. Is this true, or have I misunderstood things?
Also, the Inform games I've looked at have continued the V1-3 practice
of storing the current location object, score and number of turns in
the first three global variables. Is this something that can be relied
upon, or have I just been lucky?
> By far the easiest way for Z-code to send out-of-band messages to the
> interface is to use some custom markup. The game prints "You see a
> troll here.<$TROLL_STATE_1$>" The interface recognizes the <$$> tags,
> diverts that text (so that it doesn't go to the story window or
> transcript), and then takes whatever Flash action.
This sounds like a very good idea, though it would require either that
authors produce special versions of their games for Flaxo, or that
other interpreters be adapted to filter out the messages. How about
setting up some kind of standard for such messages, so that other
interpreters could also take advantage of the extra information, if
they wanted to?
Peter
Peter Mattsson
wrote:
> I've updated our French website, which can now present all our games using
> Flaxo ! (now people can choose between flash, java, and offline use with
> some installed terp)
>
It's great to see Flaxo already being put to use, though it might be
as well to warn people that it's not finished yet! It should be pretty
stable, but the lack of undo and restart might confuse or annoy some.
It's also perhaps worth pointing out that Flaxo can accept zlib-
compressed game files in place of ordinary ones, and that these can be
considerably smaller. ("Across the Stars" for example, compresses from
481K to 230K.) To do the compression, I used the "Usage Example" zpipe
from the zlib site: http://www.zlib.net/zpipe.c . Once compiled, it's
easy to use:
./zpipe < inputfile > outputfile
> It's working well, the only annoyance is if the player clicks on the window
> (I mean the flash window), it will loose the focus for typing, one can gain
> it again only by clicking on the line with the prompt.
Thanks for pointing this out; I'll add it to the buglist.
Peter
Peter Mattsson
> I loaded the page, but it doesn't seem to work with Gnash. (This means
> that people who don't like to install Adobe's Flash binaries, which
> involves accepting some rather dubious license agreements, can't use
> Flaxo. As far as I know, Gnash is the most advanced free Flash alternative.)
>
> Anyway, Gnash is under active development, so this problem might solve
> itself.
Unfortunately, Gnash only has fairly limited support for Flash 9 right
now. (One reason for this is that, starting with Flash 8.5, Adobe
introduced a new version of the Flash virtual machine. It's a lot
faster than the older one, but must be causing some headaches for the
Gnash developers.)
Anyway, I'll keep an eye on Gnash, and see how close Flaxo comes to
working with it. The proposed "headless" version might work better,
without all the display stuff to worry about.
Peter
Andrew Plotkin
> On Jan 17, 4:46 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > It's very difficult to extract anything from the Z-machine -- you'd
> > have to name explicit memory addresses to look at, and those change on
> > every compile.
>
> I agree that it's difficult to extract much from the z-machine, but
> can't you at least extract inventory information? I could well be
> wrong, but I thought the child subtree of the player object
> represented the inventory and that basic information about each item
> (whether it is open, lit etc.) could be extracted from its attribute
> flags. Is this true, or have I misunderstood things?
It's true but less helpful than you think, because you don't know a
priori which object is the player object, which attribute bit
in an object record represents any given attribute, which property
field represents any given property... etc. Each of these things can
vary from compile to compile, depending on the order that objects,
attributes, and properties are defined in the source code.
> Also, the Inform games I've looked at have continued the V1-3 practice
> of storing the current location object, score and number of turns in
> the first three global variables. Is this something that can be relied
> upon, or have I just been lucky?
You've been lucky. Not *absurdly* lucky -- the standard libraries
define things in a particular order, so there's a lot of commonality
from game to game. But if the author put definitions at the top of his
source file, it'll mess that up.
Now, as (I think) vaporware said, you could get Inform to generate a
debug file; that includes all this information that the Z-code file
doesn't have.
> > By far the easiest way for Z-code to send out-of-band messages to the
> > interface is to use some custom markup. The game prints "You see a
> > troll here.<$TROLL_STATE_1$>" The interface recognizes the <$$> tags,
> > diverts that text (so that it doesn't go to the story window or
> > transcript), and then takes whatever Flash action.
>
> This sounds like a very good idea, though it would require either that
> authors produce special versions of their games for Flaxo, or that
> other interpreters be adapted to filter out the messages.
You could have a special verb which turns on the custom tags. The
Flaxo interpreter inputs it on the first turn. (But that gets hairy if
you want the game to display a menu first turn instead of a line
input.)
A better solution would be to use some element of the header. Maybe
narf some bytes in the Z-code "header extension table". Or fill in a
magic number for the interpreter number: I don't think any current
interpreters use high values, so you could fill in (say) $F1 to tell
the game that it's in an interpreter that wants markup.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.
Emily Boegheim
4364-9ae5-e...@i7g2000prf.googlegroups.com:
> Flaxo is a new, Flash 9-based Z-Machine interpreter. It's only about
> 70% complete right now, but it's usable for most games (if you don't
> mind the lack of save, restore, undo or restart functions).
> Considering the comments in a couple of recent threads, I thought now
> might be a good time to let it out into the wider world and let you
> all play with it.
>
> Try the demo at http://www.bespokerealities.com/FlaxoDemo.html and
> tell me what you think!
It won't load for me - it just errors out with "*** System Error #1009
***". I tried using different browsers (I started with Opera, then tried
Firefox and IE7) and upgrading to the latest version of the Flash plugin,
but it didn't help.
Emily
Eric Forgeot
> It's great to see Flaxo already being put to use, though it might be as
> well to warn people that it's not finished yet! It should be pretty
> stable, but the lack of undo and restart might confuse or annoy some.
For the lack of undo, I'll add a note about this on our website. Flaxo
seems to be less heavy than java to start and use. Flash is also more
widespread than java (though for ethical reason I prefer java which is
now opensource rather than flash which is closed source, but anyway,
flash is a very conveniant and clever technology).
> It's also perhaps worth pointing out that Flaxo can accept zlib-
> compressed game files in place of ordinary ones, and that these can be
ok. But for our part, we use the same game file for java, flash, and
direct download, so we prefer to keep them uncompressed.
>> one can gain it again only by clicking on the line with the prompt.
>
> Thanks for pointing this out; I'll add it to the buglist.
>
I've discovered also when there is a long introduction, the beginning of
the game is cut (there is no "more" option). I guess with long text dump
during, it would be the same.
ex :
http://ifiction.free.fr/index.php?id=jeuflash&j=028
you can compare with zmpp :
http://ifiction.free.fr/index.php?id=jeujava&j=028&terp=zmpp
Eric Forgeot
> It won't load for me - it just errors out with "*** System Error #1009
> ***". I tried using different browsers (I started with Opera, then tried
> Firefox and IE7) and upgrading to the latest version of the Flash
> plugin, but it didn't help.
>
> Emily
Probably there is some errors with your flash player, because it worked
for me on Opera, firefox, konqueror etc, I could even make it work on
internet explorer in the wine emulator.
Emily Boegheim
news:4791028f$0$21577$426a...@news.free.fr:
I wondered that, but it works fine with other Flash games I've played
lately, and I upgraded to the latest version (of the official Adobe
plugin, not Gnash or anything like that) to make sure.
If it helps, all of the browsers I tried seemed to be catching
Javascript errors where the code was trying to call a method on the
"Flaxo" object, but "Flaxo" wasn't actually an object. (Could it be
something to do with the Flash element loading too slowly for the
Javascript? I have a really, really slow dial-up Internet connection.)
Emily
Peter Mattsson
> If it helps, all of the browsers I tried seemed to be catching
> Javascript errors where the code was trying to call a method on the
> "Flaxo" object, but "Flaxo" wasn't actually an object. (Could it be
> something to do with the Flash element loading too slowly for the
> Javascript? I have a really, really slow dial-up Internet connection.)
>
> Emily
I think the problem is due to a small bit of Javascript that was
intended to set the focus to the Flash window: if it tries to do this
before everything's loaded, you get an error. As an interim measure,
I've removed the offending Javascript; does it work for you now? As
mentioned earlier in the thread, you may need to click somewhere on
the introductory text -- not just anywhere in the Flash window -- to
get Flaxo to respond. (On dialup, the page may take a couple of
minutes to load, as it weighs in at about 400kb.)
Sorry about all the hassle,
Peter
P.S. If the problem persists, it would be useful to know what version
of Flash you're using. The easiest way to find this out is to go to
Emily Boegheim
4cb9-be1c-1...@d70g2000hsb.googlegroups.com:
The Javascript error has gone away, but the system error is still there.
The page loads, the 'terp appears as an empty white box. It just sits
there for a few minutes - I assume it's loading. Then it brings up the
"system error" message.
I'm using the Adobe Flash plugin version 9,0,115,0.
Emily
Peter Mattsson
> The Javascript error has gone away, but the system error is still there.
> The page loads, the 'terp appears as an empty white box. It just sits
> there for a few minutes - I assume it's loading. Then it brings up the
> "system error" message.
>
> I'm using the Adobe Flash plugin version 9,0,115,0.
Sorry for taking so long to respond. This is very strange: you're
using the same version of Flash as I am, so there's no problem there.
Error #1009 is a Flash system error (meaning, "Cannot access a
property or method of a null object reference.") and typically only
occurs if you try to access something that hasn't finished loading
yet. Loading is quite a straightforward process for Flaxo, so the only
thing I can suggest is that, somehow, Flash grew tired of waiting for
everything to load and timed out. (When you talk about a "few
minutes", how long do you mean? I'd expect everything to download in
about two minutes on most dialup connections.)
I'll look into this further (has anybody else had problems?). In the
meantime, if you still have any curiosity left, try the "Download
Demo" link instead (at http://www.bespokerealities.com/Flaxo.html ).
This allows you to download a version you can play offline (just
unpack the zip file and double-click on FlaxoDemo.html).
Thanks for your patience,
Peter
Emily Boegheim
> On Jan 19, 8:35 am, Emily Boegheim <emily.boegh...@gmail.com> wrote:
>> The Javascript error has gone away, but the system error is still
>> there. The page loads, the 'terp appears as an empty white box. It
>> just sits there for a few minutes - I assume it's loading. Then it
>> brings up the "system error" message.
>>
>> I'm using the Adobe Flash plugin version 9,0,115,0.
>
> Sorry for taking so long to respond. This is very strange: you're
> using the same version of Flash as I am, so there's no problem there.
> Error #1009 is a Flash system error (meaning, "Cannot access a
> property or method of a null object reference.") and typically only
> occurs if you try to access something that hasn't finished loading
> yet. Loading is quite a straightforward process for Flaxo, so the only
> thing I can suggest is that, somehow, Flash grew tired of waiting for
> everything to load and timed out. (When you talk about a "few
> minutes", how long do you mean? I'd expect everything to download in
> about two minutes on most dialup connections.)
I tried it again just now, letting it have the whole Internet connection
to itself to speed the download up, and it worked just fine. Took about
two and a half minutes from page load to title screen. I guess it's
quite possible that with a few other things using the connection at the
same time, the download might slow down enough to exhaust Flash's
patience. (Come to think of it, I have had a few other Flash thingummies
stop in the middle of loading recently.)
Anyway, the interpreter looks really nice and seems to run very
smoothly. (I wish there was something like this for other VMs!)
Emily
Peter Mattsson
> I tried it again just now, letting it have the whole Internet connection
> to itself to speed the download up, and it worked just fine. Took about
> two and a half minutes from page load to title screen. I guess it's
> quite possible that with a few other things using the connection at the
> same time, the download might slow down enough to exhaust Flash's
> patience. (Come to think of it, I have had a few other Flash thingummies
> stop in the middle of loading recently.)
That's good to know. I'll look into ways to make Flash more patient
(or at the very least put up a warning that this might happen).
> Anyway, the interpreter looks really nice and seems to run very
> smoothly. (I wish there was something like this for other VMs!)
Thanks! After everything you've been through, I'm glad it was
(somewhat) worth it...
Peter
krawhitham
4364-9ae5-e...@i7g2000prf.googlegroups.com:
> Flaxo is a new, Flash 9-based Z-Machine interpreter. It's only about
> 70% complete right now, but it's usable for most games (if you don't
> mind the lack of save, restore, undo or restart functions).
> Considering the comments in a couple of recent threads, I thought now
> might be a good time to let it out into the wider world and let you
> all play with it.
>
> Try the demo at http://www.bespokerealities.com/FlaxoDemo.html and
> tell me what you think!
>
> Peter
>
> P.S. I'm considering developing a "headless" version that uses
> Javascript for output rather than the normal Flash window. This would
> mean, among other things, that the display could be customised pretty
> much as you like simply by adding the right Javascript functions to
> your webpage. I could also adapt Flaxo to accept queries about the
> game state (within the limits of what's easily extracted from the z-
> machine state), to enhance the display. Would anybody be interested in
> this and, if so, what information would you like to get at?
>
How is development coming?
Peter Mattsson
> How is development coming?
Sadly, the last month has been insanely busy (blame a combination of
renovating my apartment and working hard enough to pay for it).
However, things should calm down a bit by early March, so I should be
able to get back to it then.
In the meantime, this might be a good time to ask everybody how you
want Flaxo development to proceed from here. It's a given that the
rough edges will be filed off the current version, but where do you
want to go after that?
For example, one thought is to add other engines (e.g. Glulx, TADS)
with the aim of getting as much IF as possible online. However, that
aim could also be achieved by writing a Glk implementation that either
allows games to be played from a server, or as a browser plugin. (The
end result might be a bit more laggy in the former case, and would
require players to download the plugin in the latter, but it would
likely be significantly less work to do.)
An alternative would be to stick with the Z-machine (possibly with the
addition of Glulx, given that more Inform games require it these days)
and add extra features. For example, as I suggested before, I could
make a "headless" version, instantly enabling authors to use arbitrary
HTML in their games. There's also the possibility of implementing
whatever comes out of the discussion over at Textfyre Channels.
Essentially, I'm open to any ideas that fall even vaguely into the
realm of possibility. If there's anything you've always wished an
interpreter could do (but been afraid to ask), tell me!
Peter
Emily Short
> For example, one thought is to add other engines (e.g. Glulx, TADS)
> with the aim of getting as much IF as possible online.
I would certainly like to see that happen, whatever the means.
> However, that
> aim could also be achieved by writing a Glk implementation that either
> allows games to be played from a server, or as a browser plugin. (The
> end result might be a bit more laggy in the former case, and would
> require players to download the plugin in the latter, but it would
> likely be significantly less work to do.)
I'm a little concerned about speed, but at the same time I'm
wondering: would a plugin interpreter be slower (natively) than one
that might be running on a server? If so, is it possible that
(especially for processing intensive games) the lag time of
transmitting data might be less significant than the speed difference
that comes from running a faster interpreter on the server? (It's
possible I completely mis-envision the issues here, so feel free to
ignore if it's not to the point.)
I'm also somewhat interested in the idea of a server-side interpreter
because it might allow for some interesting interface-with-the-outside-
world sorts of features that IF currently mostly avoids. Some ideas
that have been floated:
1) Keeping a record of winning players or leaderboard of some kind (if
it's a game that can be won with different scores); or (in the case of
educational IF) externally recording that students have in fact used
the program.
2) Allowing the game to rely on outside scripts or files as an
interface to web data (there are examples already of how to do this
with Glulx, but they require some script running on the computer
alongside the regular interpreter).
3) Having two or more linked game files that could be played by
multiple persons, perhaps for some kind of loosely-multiple player
game -- again, this would require having the games running in the same
place so that they can share files of data about world state and that
sort of thing. (I suspect we wouldn't see a LOT of these written, but
it might be fun to try.)
Aaron A. Reed
I'd love to see Glulx support, and the "headless" version would be
very cool too.
More ability to interface with the outside world, as Emily suggests,
would be great too. I've always wanted an easy way to post games on my
website and automatically capture logs from everyone who plays them.
--Aaron
Peter Mattsson
> I'm a little concerned about speed, but at the same time I'm
> wondering: would a plugin interpreter be slower (natively) than one
> that might be running on a server? If so, is it possible that
> (especially for processing intensive games) the lag time of
> transmitting data might be less significant than the speed difference
> that comes from running a faster interpreter on the server? (It's
> possible I completely mis-envision the issues here, so feel free to
> ignore if it's not to the point.)
A plugin terp shouldn't really be any slower than an ordinary, native
terp. (The only difference, really, between plugins and ordinary
programs is that plugins have a browser communication layer wrapped
around them.) On the other hand, a terp running on a server
potentially has to service several different players at once (not to
mention the fact that most web hosting packages ask you to share a
server with others), so it may turn out to be slower. However, since
terps usually spend most of their time waiting for input, this
probably wouldn't be an issue in practice.
As has been mentioned in another thread, server lag isn't a big issue
these days anyway, but it would likely mean that terp responses didn't
seem to be absolutely instantaneous. (On a bad day it would typically
add 100-150ms to the response time, which is only borderline
noticeable.)
The basic issue is that plugins (a) require players to download and
install them before play and (b) must be recompiled for each browser
and operating system you want to support. Using a server-based
approach avoids those problems, but instead (a) introduces a little
lag, (b) is more awkward to set up and (c) requires dial-up users to
stay connected to play.
Using Flash or Java and running the terp in-browser is the simplest
option (in that it's easy to set up and easy to use) but (a) is a
little slower (though generally not enough to worry about) and (b)
prevents re-use of any existing interpreter code. Personally, I'm
inclined to favour this approach anyway, because I think the upfront
cost of porting the terps is worth the later ease of use.
However, I'm also considering the server-based option quite seriously.
In that vein, I'm also considering setting up a service where people
could host their games for people to play, along the lines of Volity
but for IF. (In fact, I've just reserved Flaxo.org for the purpose.)
Is that something people would be interested in?
> I'm also somewhat interested in the idea of a server-side interpreter
> because it might allow for some interesting interface-with-the-outside-
> world sorts of features that IF currently mostly avoids. Some ideas
> that have been floated:
>
> 1) Keeping a record of winning players or leaderboard of some kind (if
> it's a game that can be won with different scores); or (in the case of
> educational IF) externally recording that students have in fact used
> the program.
This could be done just as well with a client-side interpreter, with
the help of a server-side script. In general, anything that can be
done with a server-side interpreter can also be done with a client-
side one; it's just a matter of deciding where you want most of the
processing to happen.
> 2) Allowing the game to rely on outside scripts or files as an
> interface to web data (there are examples already of how to do this
> with Glulx, but they require some script running on the computer
> alongside the regular interpreter).
It would be good to open up these sort of options; the tricky part
would be communicating the new data to the game. Perhaps the simplest
way would be to use a bit of fakery: when the game asks to read in a
given external file, it could get a stream of data from the terp
instead. If we can come up with a standard way to do this, I'll add
support for it.
> 3) Having two or more linked game files that could be played by
> multiple persons, perhaps for some kind of loosely-multiple player
> game -- again, this would require having the games running in the same
> place so that they can share files of data about world state and that
> sort of thing. (I suspect we wouldn't see a LOT of these written, but
> it might be fun to try.)
This is a case where a server-side interpreter might be a bit simpler,
but it would be easy enough to support with a client-side one: it
could send and retrieve files of game data to/from the server as
required. The difficult part would be coming up with a good scenario,
and working out how to deal with the lack of real-time support in
current IF platforms. (In a gameworld where one player might make five
moves in the time it took another player to make one, how do you build
good gameplay?)
Peter
Peter Mattsson
> More ability to interface with the outside world, as Emily suggests,
> would be great too. I've always wanted an easy way to post games on my
> website and automatically capture logs from everyone who plays them.
This shouldn't be a problem: I can give Flaxo the option of sending
play transcripts (named e.g. using the game name, IP address of the
player and time) back to the server. (You may want to warn players
that this is going to happen, though!)
Peter
Blank
Absolutely - I have quite enough of my government watching my every
move! I think there should be a minimum 'courtesy standard' of informing
such players that their moves are being logged, and ideally offering the
option to refuse permission.
--jz
Aaron A. Reed
Well, there goes my plan to get rich by adding a character to my
latest game who says "Please type in your real credit card number now!
Don't worry, it's just a Flash game on the internet, no one will see
it! P.S., remember to include the expiration date and CVC code."
--Aaron
Aaron A. Reed
But seriously, if I'm running a website and you visit it, I can
already look at the log files to tell what city you live in, what kind
of computer you're using down to fairly precise details, the time you
accessed my site and what links you clicked on, whether you bookmarked
it or not, and various other information.... I fail to see how viewing
your transcript of a text adventure could further compromise your
privacy or security.
--Aaron
chipjack
> But seriously, if I'm running a website and you visit it, I can
> already look at the log files to tell what city you live in, what kind
> of computer you're using down to fairly precise details, the time you
> accessed my site and what links you clicked on, whether you bookmarked
> it or not, and various other information.... I fail to see how viewing
> your transcript of a text adventure could further compromise your
> privacy or security.
I imagine some of the stuff people type into AIF games would be a
little embarrassing if made public. I'd be mortified if the world
found out about that thing I tried to do with the blonde, the buttered
toast, and the weed whacker.
So, shhh. Don't tell anybody.
-- chipjack
Eric Forgeot
> In the meantime, this might be a good time to ask everybody how you want
> Flaxo development to proceed from here. It's a given that the rough
> edges will be filed off the current version, but where do you want to go
> after that?
>
I'm just summing up what we already discussed here, and a few other
things I've noticed :
- the focus on the command line should be when you click on the window.
At the moment it's only when you click exactly on the command line (white
on white), which most people who are not experienced with internet and
computer would fail.
- When there are long text dump, it won't stop with a "more" option, the
beginning of the text will be cut.
- Some accented letters are not correctly shown : î for exemple. â is ok,
and ê seems ok too, but not when you type it (it looks like e^)
- accented letters are not recognized in input (on gargoyle some are not
too, like ê, but é is), if you type the accented letters, the game fails
to recognize them (in our french games, with frotz for exemple, the
accented letters are converted into normal letters, and the words are
correctly recognized)
- a scrollback would be nice, but it's not really essential
- a last command replay with the upper arrow would be nice, but it's not
really essential.
- a way to reduce the letter size would be nice (maybe it's already
implemented?)
- other system support : tads, alan etc, if it's not too difficult for
you (can you reuse the existing codes?). Glulx with graphics and sounds
would be amazing!!
- do you think it would be possible to make a facebook application with
flaxo? I don't really like facebook, but it could be a way to attract
more people to IF
- is there a way to release the games with faxo, fonts and the game file
in some embedded way, like an archive? It could be an idea to send IF
games to websites supporting flash adventure games, but I don't think
they would allow several files formats like z5 or blb.
- I can't think of something else. Flaxo is already a very enjoyable
thing for the diffusion of IF games.
Emily Short
> On Feb 20, 9:11 pm, Emily Short <emsh...@mindspring.com> wrote:
> However, I'm also considering the server-based option quite seriously.
> In that vein, I'm also considering setting up a service where people
> could host their games for people to play, along the lines of Volity
> but for IF. (In fact, I've just reserved Flaxo.org for the purpose.)
> Is that something people would be interested in?
Yes, I think that would be quite nice.
> > 3) Having two or more linked game files that could be played by
> > multiple persons, perhaps for some kind of loosely-multiple player
> > game -- again, this would require having the games running in the same
> > place so that they can share files of data about world state and that
> > sort of thing. (I suspect we wouldn't see a LOT of these written, but
> > it might be fun to try.)
>
> This is a case where a server-side interpreter might be a bit simpler,
> but it would be easy enough to support with a client-side one: it
> could send and retrieve files of game data to/from the server as
> required. The difficult part would be coming up with a good scenario,
> and working out how to deal with the lack of real-time support in
> current IF platforms. (In a gameworld where one player might make five
> moves in the time it took another player to make one, how do you build
> good gameplay?)
Yes, it's tricky -- I imagine it might have to be something quite
formalized and unusual, and I doubt we'd see many games of this kind.
One approach might be to have a "time of day" that is the same for
both players, regardless of the number of moves each has performed;
and design the game play so that it's not really puzzle-oriented in a
way that would reward people heavily just for typing fast. Then
whenever the game time ratcheted forward -- as Christminster does from
afternoon to evening, say, or Anchorhead from one day to the next --
the game might report back on the results of events taken on the other
side. So the result would be less like a tactical war game or the
like, and more strategic, a slow set of decisions about what to do
that might, from a great distance, affect the experience of the other
player.
Possibly one might even do it like Diplomacy: a given "day" is over
when each player has made some critical decision (equivalent to
submitting orders in Diplomacy); then their respective orders are
resolved and a new day begins with the new parameters in place. One
might then spend most of one's commands in-game on things like
exploring, planning, gathering information, etc., before submitting
the one command that signals completion of the day.
I initially proposed this as a wacky idea unlikely to be pursued very
much, but the more I talk about it, the more I think it would actually
be a lot of fun to write...
Peter Mattsson
<contact_is_on_websi...@anamnese.fr.st> wrote:
> I'm just summing up what we already discussed here, and a few other
> things I've noticed :
Thanks for this.
> - Some accented letters are not correctly shown : î for exemple. â is ok,
> and ê seems ok too, but not when you type it (it looks like e^)
The i-circumflex problem is probably a typo (I'll look into it), but
there shouldn't be any difference between displayed and typed
characters. It might be a problem with Flash's rendering of italic
accents.
> - accented letters are not recognized in input (on gargoyle some are not
> too, like ê, but é is), if you type the accented letters, the game fails
> to recognize them (in our french games, with frotz for exemple, the
> accented letters are converted into normal letters, and the words are
> correctly recognized)
There's no support yet for Unicode input (only output), so I'll attend
to that. Is it better to strip off the accents during input, or should
I feed them in in proper Unicode form? (Are French games designed to
expect accentless input, or do they accept both?)
> - a way to reduce the letter size would be nice (maybe it's already
> implemented?)
It's not, but it should be simple to do. In the next version, I'm
planning to have an XML configuration file, with support for changing
letter size, linespacing, fonts, margins, colours and anything else I
can think of.
> - other system support : tads, alan etc, if it's not too difficult for
> you (can you reuse the existing codes?). Glulx with graphics and sounds
> would be amazing!!
Glulx is almost certainly coming; porting other terps is on hold until
I see how well a server-based approach works. Unfortunately, I can't
re-use any existing code directly, as Flash applications have to be
written in ActionScript. However, ActionScript is very similar to Java
in many ways, so porting across a Java-based terp shouldn't be too
painful. (I was thinking of taking a look at Zag, for example.)
> - do you think it would be possible to make a facebook application with
> flaxo? I don't really like facebook, but it could be a way to attract
> more people to IF
As far as I can tell, gadgets for Facebook, MySpace, iGoogle etc.
would all be pretty simple to implement. I don't really use Facebook
or any of the other social networking sites either, but you're right:
it could be a good way to give IF more exposure.
> - is there a way to release the games with faxo, fonts and the game file
> in some embedded way, like an archive? It could be an idea to send IF
> games to websites supporting flash adventure games, but I don't think
> they would allow several files formats like z5 or blb.
Bundling everything into one file wouldn't be a problem, although it
would require you to recompile Flaxo yourself to do it. (That's fairly
painless, though, and Adobe's compiler is free-as-in-beer and cross-
platform. Ironically, it's written in Java.) I'll put a tutorial
together.
> - I can't think of something else. Flaxo is already a very enjoyable
> thing for the diffusion of IF games.
Thanks!
Peter
Peter Mattsson
> Possibly one might even do it like Diplomacy: a given "day" is over
> when each player has made some critical decision (equivalent to
> submitting orders in Diplomacy); then their respective orders are
> resolved and a new day begins with the new parameters in place. One
> might then spend most of one's commands in-game on things like
> exploring, planning, gathering information, etc., before submitting
> the one command that signals completion of the day.
This sort of approach would definitely be quite feasible, especially
given the limited interaction between the two sides. There's still the
problem that some players will get to the end of the day faster than
others, and wind up waiting for the rest to finish, but that's life, I
guess.
The main question, to me, is whether it's easier (technically) to add
multiplayer facilities to an IF engine, or to start from a MUD engine
instead and build from there.
> I initially proposed this as a wacky idea unlikely to be pursued very
> much, but the more I talk about it, the more I think it would actually
> be a lot of fun to write...
Go for it! (I'd certainly play the result.)
Peter
Emily Short
> The main question, to me, is whether it's easier (technically) to add
> multiplayer facilities to an IF engine, or to start from a MUD engine
> instead and build from there.
Well, I'm not sure. I originally brought it up because it's on my list
of stuff people want to do, but can't because we don't have server-
side interpreters; and that list exists because of other people's
requests. I field a fair number of questions from people who want to
use Inform 7 to write multiplayer games of some description or other,
who are often sad when I tell them that it's not really designed for
that. But, as I said, the more I talk about it the more I can envision
this being an interesting project. (And, obviously, for *me* it would
be easier to write a couple games in I7 than to learn a MUD scripting
language, etc., from scratch.)
Eric Forgeot
> feed them in in proper Unicode form? (Are French games designed to
> expect accentless input, or do they accept both?)
they can accept both, but even if flaxo can't handle accented letters,
it's not such an issue because we can tell people not to count on accents
(I think many people don't even bother enter accented letters when they
type on computer)
> It's not, but it should be simple to do. In the next version, I'm
> planning to have an XML configuration file, with support for changing
sounds great!
> Glulx is almost certainly coming;
wow! I think everybody here is awaiting all those good things :)
A tutorial for recompiling flaxo could be interesting too, especially if
we don't have any flash creator.
Blank
> On Feb 22, 6:54 pm, Eric Forgeot
> <contact_is_on_websi...@anamnese.fr.st> wrote:
>> I'm just summing up what we already discussed here, and a few other
>> things I've noticed :
>
> Thanks for this.
>
>> in some embedded way, like an archive? It could be an idea to send IF
>> games to websites supporting flash adventure games, but I don't think
>> they would allow several files formats like z5 or blb.
>
> Bundling everything into one file wouldn't be a problem, although it
> would require you to recompile Flaxo yourself to do it. (That's fairly
> painless, though, and Adobe's compiler is free-as-in-beer and cross-
> platform. Ironically, it's written in Java.) I'll put a tutorial
> together.
>
This sounds really interesting. When I played "Earth and Sky" I followed
the recommendation to set the font to Comic Sans, and it really did make
a difference to the feel of the game, I thought. So I'd appreciate a
system where I was able to do that for the player as the default set-up.
--jz