ORR Home > Articles > Interactive Fiction
Project News
16 Feb 2001 |
06 Feb 2001; Dennis G. Jerz
ZPlet is a freeware Java applet that runs interactive fiction texts. (To see
it in action, play Emily Short's
Metamorphoses" online). Zplet was written by Matthew Russotto
in 1994. Since then, changes in Java and a booming online community of
interactive fiction players have prompted me to look into improving Zplet.
I'd love to see the "save" and "restore" features work in some fashion (perhaps by saving files on my own server), and I'm interested in making Zplet work better with screen readers.
This page archives some of the first flurry of news postings and e-mails on the topic.
05 Mar 2001
When I was putting up my game at <http://nomediakings.org/punkpoints> I noted two problems:
* The text would scroll one line too many before giving the [MORE] prompt, although playing with the width and height of the box remedied this * In other games running on Zplet I've noticed the status line had some overlapping text
I also really like the "Loading..." suggestion, since a lot of people click away before it finishes.
Glad to hear that you're taking it on!
Jim Munroe
rec.arts.int-fiction and rec.games.int-fiction (Zplet thread on deja-google)
[Announce] Call for Zplet bugs & suggestions for new features
02 Feb 2001
Some time ago I corresponded with Matthew T. Russot[t]o, programmer of
Zplet,
who gave me permission to update, expand, and redistribute Zplet for
non-commercial purposes.
Since then, I managed to get a small grant from my department and
university, that I have used to hire a student programmer. The student
says
he's deep into the code now, and is ready to tackle bug reports.
I have done some hunting, and haven't found any such bug list/ wish list for
ZPlet. If there is one, I'd be happy for the pointer.
So... what bugs bedevil us when we use ZPlet?
* Disambiguation problems
* Bug in the gold section of Photopia (according to Adam Cadre)
* ZPlet printes "END OF SESSION" in Photopia, after one of the
scenes where
it shouldn't be there
* Can't save or restore (not a ZPlet bug, but a Java restriction)
* What else?
More important... what would it be nice if Zplet *could* do?
* A feature that allows a Zplet window to boot up with a saved game in
place.
I might want to create a spoiler-filled website that permits people to jump
ahead to the moon chapter of Jigsaw, and compare it side-by-side with the
endgame of Trinity, for example. (Reading a transcript just doesn't cut
it.) I might want to teach "scene-setting" by having a student
wander
around in a space, after all the monster/barriers have been dealt with,
simply for the purpose of admiring the writing. Yes, such a feature would
permit cheating of all sorts, but what's a walkthrough, anyway?
Other possibilities:
* Output a running transcript in a separate window?
* Download or view transcript on a web page?
* Have a "new text since last turn" window, for screen readers?
(Audysee
readers, what do you think?)
* User-customizable colors and fonts?
* Invisiclues add-on?
* What else?
Andrew Plotkin replies to a post by Adam Cadre:
In rec.arts.int-fiction Adam Cadre <ac@adamcadre.ac>
wrote:
> Dennis Jerz wrote:
>> * Disambiguation problems
>> * Bug in the gold section of Photopia (according to Adam Cadre)
> These are the same problem, actually. The gold section of Photopia
> just happens to be where most players try to examine something that
> results in the infamous Zplet disambiguation infinite loop.
I don't suppose anyone has a clue what causes this. (I don't, I'm
afraid.)
Since parser disambiguation is part of the library, and is therefore
implemented in Z-code, there is no part of Zplet which is "the
disambiguator". It would have to be some tiny bug in the
implementation of a Z-opcode, which happens to manifest only in the
Inform library.
I then asked a stupid question, which was deftly handled by Evin Robertson:
In article <95feur$tq4$1@wiscnews.wiscnet.net>,
"Dennis G. Jerz" <JerzDG@uwec.edu>
wrote:
> In a pinch, would it make sense simply to block that feature -- just
> to say "You need to be more specific," and dump the player back
to
> the prompt, without having saved a list of likely options for the
> user to choose among?
What zarf means is that the disambiguation is not exposed to the
interpreter. To fix this, you either need to find and fix the bug in
Zplet, or recompile all Inform games not to disambiguate. There's no
reasonable way for Zplet to "block" that feature.
Has anyone tried running my http://plover.net/~thumper/test.z5
through
Zplet? No guarantees that it'd find it, but it's found bugs in other
'terps. If that doesn't show any problems, then someone needs to look
at the things Inform does when it attempts disambiguation, and test
each of them separately in Zplet. Adding lots of print statements to
the parser might be a good first try.
Matthew Russotto then replied to Evin Robertson:
Much harder than necessary. What's needed is a nice minimal piece of
code which will cause ZPlet to fail, and then a little bit of tracing
through will reveal the bug. I think someone once sent me such a
minimal piece, which I promptly lost :-(.
[another post from Matthew]
It fails the arithmetic shifts with negative shift amounts. It also
claims to be pirated, which is odd; I did that on purpose, though --I
must have thought it was a good idea at the time, because I put a
comment in the source to that effect.
It doesn't appear that the parser uses right shifts. But possibly I'm
mistaken about that. In any case, it's an easy thing to fix -- line
1052 of ZMachine5.java has the shift backwards.
Andrew MacKinnon reported a small bug:
One thing I noticed is that only the backspace works for deleting; left
arrow,
right arrow, delete, home, end, etc. don't work.
"spinf@geocities" reports that the Spanish version of Photopia demonstrates the following bugs (which were listed in the initial post):
* Incorrect decoding of unicode chars in output, when
directive Zcharacter is used
* It doesn't accept accented vowels or other foreign
characters in input
FYI, here's a link to the game file: fotopia.z5
Answering his own question about how to use Zplet, Daryl McCullough writes:
To make the game "game.z5" into a web page, just use make an HTML
document with the following lines:
<HTML>
<BODY>
<applet archive="ZPlet.jar" code="Zplet.class">
<param name="StoryFile" value="game.z5">
</applet>
</BODY>
</HTML>
Pretty doggone simple.
"Snacky Pete" responded to a reference to accessibility:
You touched on my interests with regard to screen readers. I wrote a
couple of short games for a web site that caters to persons with
disabilities. In particular, these games were for the visually
impaired, as the text adventure is one of the few computer games they
can play. The problem was, none of the text was exposed through the
Zplet in a way that screen readers could identify. In my own simple
thinking, I reasoned "It's text, so they can read it!" Not so,
according to my clients. I've been searching for an answer ever
since, gently dabbing the egg from my face as I go...
Adam Newbold wrote:
It may seem petty, but a "Loading game" or "Loading applet" message of
some sort, displayed initially and removed when the game has loaded,
would be nice. Even better would be a real-time status/progress bar of
some sort displayed while the applet loads.
from Jon Ingold:
Another bug in ZPlet - though not a particularly troublesome one - is
highlighted by my game "My Angel"'s novel mode. This mode prints text in the
main screen and accepts input in the status bar; but the word wrap goes
wrong if a previous text line starts midway through the line. Here's an
example to show what I mean:Text in main window: - "XXXXXXXX "
Type in a command in the top window, which produces a line of Y's as output
gives:Text in main window: - "YYYXXXXXXYYYYYYYYYY"
... that is, the line being printed wraps over to the start of the line its
already on; there's no carriage return. This is something quite fundamental;
JZip for DOS does the same thing as does MaxZip.
from Philipp Lenssen:
I want different fonts/ font-sizes. I talked to M.T. Russoto about it and compiled some versions myself but it's not a 1 hour job, so that's my wish. Thanks
from Zach Mattley:
Thank you for your interest in updating Zplet. Here are my two cents worth.
You mentioned the gold section of photopia. Zplet more generally has
difficulty running the set_colour opcode. I have two Inform programs that
make use of color, and do not run well on Zplet. The screen does not
always change colors, or sometimes only changes partially. I get
different results depending on the web browser and operating system.
Please feel free to take a look at my programs at
http://webpages.csus.edu/~sac59848/software/antiques.htmlAlso, why not make Zplet adherent to the Z-machine standards as
delineated on Graham Nelson's web site? I am aware of two ways that Zplet
is not standard. It does not accept mouse input nor timed input.I hope you find this information useful. feel free to ask me any questions.
from Devin Weaver
Sweet so far I'm not the only one who is trying to spiffy up the code.
About a month ago I asked the same thing with intentions of opening
the source to the public via a CVS server. And add a few feature which
I felt would be extremely cool. Unfortunately after getting the latest
source I realized that it needed quite a bit of work. (Very bad
spaghetti code) And at the same time I ran into some personal and
financial troubles which prevented me from building my dream CVS
server.First I'd like to offer my self to the project as a volunteer if
needed. I'm a professional Java Programmer and a Interactive Fiction
enthusiast.Second I'd like to take this opportunity to discuss my opinion on how
the code should eventually mutate to. The first and most daunting task
would be to pull all those classes out in put them into proper
packaging. (And make them public classes). See most of the files in
the source contain about 2-3 classes with package access. And there
is no packaging. I started this but never finished it.The next step would be to bridge the gap between the application
version and the applet version (Which the source has both) I though
the best way to do this was to define an System interface which would
contain call-backs designed for lower level stuff like playing sound
file IO etc. That way the application and the applet would both
implement it and the actual ZMachine would care which one it was
using. basically abstracting the code which requires certain
provisions (i.e. file IO).My ultimate goal would be to add sound to the system but the only why
I could think of would be to use the applet's audio methods but they
only deal with Sun's au format so all the old Infocom sounds would
need to be converted either at runtime (Lots of byte manipulating
code) or manually.I also wanted to add a new custom assembler code. In the ZMachine
standard it states that there are a few op codes left for future
expansion and/or customization. I planned on using one of these op
codes to trigger a applet event. In other word store a list of URLs
in a file each one corresponding to a number and in the inform code
call a custom op code with a number. that number would be translated
by the applet to a URL (via the look up file) and send the browser to
that URL (Target another frame and/or a new window). That way You
could have an IF website based on a real game. many have tried this
but it was all static and choose-your-own-adventure like. Imagine the
applet actually playing and you have to get the gold key to open the
west door where you find a book and as you read the book and new
window pops up with the actual book. Or you stop into a store and
examine the Teddy bear and a page pops up with the Teddy bear and an
order form. cool ehh?Let me know how I can help. I suggest highly that you place the code
into a CVS server maybe a sourceforge project or one at the
university.
by Dennis G.
Jerz
06 Feb 2001 -- first posted
12 Aug 2001
-- last updated