ifwiki.org/index.php/Wry_Humor
This game has been ported to .z5, but I’ve never seen anything so buggy on a program level! Stray characters, the interpreter crashes upon loading half the time, sometimes endless [MORE] prompts are generated… it’s so badly done it’s inspiring, I had no idea you COULD do something that lousy in Inform! Any idea on what might have happened to turn a simple CYOA into such an unplayable mess?
It was written in Frolg, not Inform.
It’s certainly not evidence of Frolg working.
Frolg is just an assembler, though. Is there a big fancy library for it like for Inform?
Ah, so created with a different assembler for use with the Z-Machine. That explains it. So it probably IS impossible to replicate it using Inform.
I have to say, so many things go wrong that it’s pretty hilarious.
EDIT - Oh wait - Frolg! The one that refuses to add Unicode and blorb support! Now I remember. Doesn’t bode well for the assembler, no.
EDIT 2 - Beh, I was thinking of aimfiz. I’m all confused. 
EDIT 3 - Fweep, actually.
Those projects are all from the same person, though, so you weren’t that confused. 
After studying it for a while, I have concluded that it is the interpreters (and, to some degree, the Z-Machine Standards Document) that are defective. Aimfiz, Fweep, and Infocom’s interpreter (the one included with the PC release of Beyond Zork) all run it just fine. There are still bugs in it though, because many of the bugs and spelling/grammar errors in the original are reproduced in the port too (although the stack overflow bug has been removed; the original had each page as a subroutine that calls another and it caused a stack overflow).
Ah. The interpreters that have been running every other game since Inform got off the ground are the defective ones. Good to check.
The thought occurs that there is a reason why the Z-Machine was standardized, rather than keep doing everything exactly the way Infocom did it.
If you’re serious then please explain how the standard is wrong.
I haven’t looked into all the issues with this game (or Solter Solitaire, which also exhibits bugs under standard interpreters), but at least one of them has to do with text encoding… and judging from the spectacular failures produced by Wry Humor, there may be several text encoding issues.
The only one I’m aware of where the standard is arguably “wrong” has to do with shift locks (codes that change alphabets until further notice instead of just for the next character). The standard states that shift locks only exist in V1-2, presumably because Infocom never used them in later versions. But Infocom did document and implement shift locks for V3+ in their own interpreters.
Of course, the point of the Z-machine standardization effort was to run Infocom’s games, not to perfectly implement the machine Infocom’s engineers envisioned 30 years ago. Even Infocom never did that: the original interpreters have bugs of their own.
Today, the role of the standard is to describe a common set of features that compilers and authors can safely target, knowing that all interpreters in common use have been tested against it. zzo38 instead has chosen to target an idealized alternate-timeline version of the Z-machine that no one but him has ever properly implemented (or in the case of what he calls V9 and V10, no one else has ever implemented at all). The quixotic purity of this effort is almost admirable until one realizes how unlikely it is that this mythical platform will ever have any games worth playing.
EDIT: Before I finished writing this message, vaporware replied, mentioning a lot of good points too. Nevertheless I decided to keep the message I wrote but in a “rant” box. (The only thing is that vaporware write “which also exhibits bugs under standard interpreters” although in my opinion it should say “which also exhibits bugs under Standard interpreters”; this spelling error is a minor issue, however.)
Both games run fine under Infocom’s interpreters (Solter Solitaire originally didn’t, but that was due to a bug in their interpreter; I changed it simply so that I could test it although as it turned out the fix also made a better written program anyways; I am thinking this may be why Infocom consequently never tested this feature).
[rant]
Unfortunately, it was standardized in the wrong way.
Actually, Infocom’s interpreters have some defects too, such as, INC 0 and DEC 0 do not work (it is supposed to work; they documented it but the interpreter just sets the result to zero by mistake). Infocom’s documentation also contains a mistake, such as saying that the fwords table contains quad-pointers, even though they are actually word-pointers. But Z-Machine Standards Document also has defects, and so do most new interpreters. I believe that the subset of Z-machine that Aimfiz implements at all, is implemented correctly without defects (although it is possible I am wrong).
And yet there are still unknown things (although I have managed to figure out how font 2 is supposed to work; Aimfiz implements it (although this is an untested feature)). One is how the joystick functions works; this was never used, implemented, or documented. Another is how exactly the MIDI is supposed to work. Infocom’s interpreters implement it in different ways which are klugy and also very buggy and only work with the MIDI files that are included with the game (although they did also implement some things that weren’t used, such as omitting the status byte if it is the same as before), and I haven’t seen any Infocom’s documentation mentioning the format of these files. I have figured out some things about it; they consist of a note on command, a 0xFF command (probably some kind of delay, although I don’t know the units (can someone help?) and their interpreters don’t implement it), and then a note off command (well, it is encoded as a note on command with a velocity of zero; in MIDI this is the same as a note off command though, even though for some reason MIDI note off commands can also have a velocity).
It has been suggested to call this (more accurate) construction of Z-machine (even though it has some extensions too (such as version 7 and 8, and some others), but they are all optional; however, some of the things the Z-Machine Standards Document doesn’t mention but which is included in this one, still are considered normal and aren’t considered extensions, such as permanent shifts, and the MARGIN command in version 5) to given a different name, but you can’t do that; this is Z-machine. Another suggestion is to use a different filename extension; but that is unknown too (I suggested “.DAT” but also suggested why that is no good, and other peoples agrees too that it is no good).
So now you see that the situation isn’t quite as simple as you may have believed it to be![/rant]
I don’t fully understand the arguments around the shift locks, but if Infocom’s own games expected zchars 4 and 5 to be shift locks, then wouldn’t we expect them to frequently use zchar 5 to return to lowercase, but which will instead produce stray punctuation in our modern interpreters?
zzo38, you could be right about joysticks and sound effects, but those aren’t crucial parts of the standard, and they don’t explain the problems with wry.z5…
For all intents and purposes other than your personal crusade, the Standard is the standard.
It seems you’re unsatisfied with the two decades’ worth of engineering efforts that the rest of the IF community made before you came along, so you’ve written some minimalistic tools and games in the past few months that aren’t compatible with community standards. But that doesn’t really change the fact that all the rest of the modern interpreters, compilers, libraries, and games have been written to community standards and will continue to be.
You’re free to pick whatever extension you want for your format. I just hope you settle on something before producing any more of these files, because when someone downloads a .z5 file and it won’t work in any interpreter they have installed, they’re going to blame the file, not the interpreter.
According to the Standard, zchars 4 and 5 are always temporary shifts, and repeating them has no special effect.
According to Infocom’s docs and implementation, 4 and 5 are temporary if encountered in A0, but permanent in other alphabets; repeating the same shift makes it permanent, and the opposite shift goes back to alphabet 0. (That is: [4, 4, …, 5] is a locked sequence in A1, and [5, 5, …, 4] is a locked sequence in A2.)
I don’t think this would ever produce stray punctuation in modern interpreters, only incorrect capitalization. (EDIT: Oops, of course it would produce one unexpected A2 char, which could be punctuation, after a locked A1 sequence.) But it doesn’t matter anyway, because Infocom never used it: they always used temporary shifts.
On the contrary, it seems simpler all the time. Vaporware summed it up as:
.
The thing about it all is that we’ve ironed out those kludgy bugs you talk about. z6? Midi? We have Glulx now, and there are portable interpreters capable of running it even.
To be fair, your pursuit of the perfect Z-Machine is somewhat inspiring, and seems like a curious project, but it won’t have any serious practical application. It’s a purely theoretical exercise, and in that light, knock yourself out, it’s like visiting an alternative universe. But in THIS universe we have excellent games we want to still be able to keep playing.
EDIT - I didn’t mean to sound harsh and discouraging, but I guess I have been. The thing is, it seems to me there are various ways in which current existing systems can be improved, and various portable systems which need interpreters of their own (I’m hankering for an iTads myself). It seems to me such a waste that a dedicated, technical minded person such as yourself chooses instead to pursue something with no practical purpose when so much good could be done elsewhere.
Well, you have made up a new system, then. That works too, but it is a different system.
Many Inform games I have tried run on my interpreters too; so do many Infocom games I have tried. (A Blorb file won’t run, but you can un-Blorb it, and then convert the pictures and sounds into Infocom’s formats.)
And anyone who wants to play the original Infocom games can use the replacement Blorb resources, or just run the original interpreters in an emulator.
You presume he’s interested in practical applications, or in what other authors and players want out of a system, or even in learning from the considerable work that was done before he came along. All evidence seems to suggest otherwise: anything with features he doesn’t personally want to use is “too complicated” and a candidate for being replaced. His drafts for what he calls Z-machine versions 9 and 10 regress some features back to V1-4, and omit others like Unicode, out of nothing but personal whim. And although he’ll ask for help finding bugs in his programs, and recommend them as an alternative to newbies who ask about Inform, suggestions from others get little response besides “I don’t like that.”
It is a shame to be focused on guessing the answers to trivial pseudo-mysteries like “how would Infocom have implemented the joystick if they had ever decided to do it”, when there are so many other things to uncover even in the field of Infocom history: reverse-engineering the VMs for Fooblitzky or Cornerstone, finishing the Hitchhiker’s Guide sequel, digging up the source code for ZILCH…
I don’t have Fooblitzky or Cornerstone (I am interested in these things, though), but I do have source-codes for two interpreters of Fooblitzky. If I have the game file too then I could probably do that.
That isn’t my job. Some group of real Hitchhiker’s Guide fans should help. Douglas Adams should help, but that is impossible because he is now dead. The people who started should help, but I don’t know them either. Maybe BBC should do it!
Actually I have implemented the features I didn’t use, which is most of them including those not mentioned in the Z-Machine Standards Document, but they are real features of Z-machine (I didn’t just make it up).
Sure you can do that, or use a interpreter that supports Infocom’s formats (some interpreters may support both formats).
Much of that work does help a lot, but not all of it is correct. Infocom’s documentation and interpreter source-codes also help, and they help a lot more.
Some of you make it seem like this means my interpreters won’t run existing games, but according to my testing, they work; both Infocom’s games and the ones made with Inform are working. (There are a few features Aimfiz doesn’t support: pictures (currently there is only very limited support), sounds (currently it supports sound 1 and 2), mouse menus, joystick. These are features I intend to eventually add, but using only Infocom’s formats (Blorb formats will need to be converted into Infocom’s formats).)
I don’t see why I should meddle around with a blorb file to run it on your interpreter instead of using an interpreter that was made to play blorb files.
There’s that idea again: that the only “correct” thing to do is recreate what Infocom had in 1987, as if the sole purpose of IF is to let us live frozen in the past, as if the needs of players and authors that led to decades of continued advancement simply don’t matter.
No, someone else made them up. So what? The features invented by one set of developers 30 years ago are no more “real” than the ones invented by a different set 15 years ago. The Z-machine isn’t “real”, it’s an imaginary computer that only exists to the extent that people over the years have mutually agreed on its definition.
You don’t have to; you can install however many interpreters you want to install.
While it isn’t true that the sole purpose of IF is to let us live frozen in the past, I am not talking about IF in general.
Of course that is true that those features are what someone made up; the Z-machine is made up by Infocom, not me.
EDIT: After some discussion, the conclusion is that this is a different Z-machine called “Quixotic Z-Machine” (as opposed to the “Community Z-Machine”, which is what Inform uses; Infocom used a subset compatible with both, and so are many Inform games actually), and that the extension should be “.qzm” to tell the difference.