Some of the issue is just contextual expectations. I didn’t even notice that 80 Days was technically IF until I happened to look it up in Wikipedia. There’s so much emphasis on visual information and arranging cargo geometrically, and on selecting options graphically rather than typing them in, that the full nature of the text occurred to me.
My take is that every i-f should have a Z-machine version. Make a nice web-version and a Windows installer and whatever other versions you want to make (maybe GLULX, GLXUL, whatever they are called), but ALSO just make a basic text-only Z3 or Z5 that plays everywhere, will always play, and has better accessibility than anything else.
I can still get ZORK1.DAT from a floppy from 40 years ago and play it in any interpreter that I want to. Meanwhile I struggle to get Windows games I bought 15 years ago to run, or Linux games that I bought 10 years ago. Interactive-fiction, or at least the text-only classic text adventure kind of interactive-fiction, has this amazing property that it can run on a lowest-denominator machine that every platform will always support. I can play games on my FreeBSD desktop computer or on my Android phone. I could dust off one of my old Palm PDAs to play on if I wanted to.
Dialog does it right, generating Z5 and (indirectly) HTML versions. Anyone can just open the HTML version and play in their browser, no installer or special skills required, but others can use their favorite Z-machine interpreter from the last 40 years running on their favorite platform, and configure the text rendering (or audio output) to be exactly what they want it to be like, and with any input configuration they want to. And there is no need to worry about some bloated 2020’s technology that will usually break backwards compatibility every 6 months and good luck if you are not on one of the most mainstream platforms.
4 Likes
My possibly more unpopular opinion is that I think complex parsers are overrated and make games less fun to play. There is nothing wrong with VERB+NOUN parsers (and parsing more than the first 3-4 letters per word is optional).
I understand programmers wanting to show off and the advanced parsers many modern games have (and some old ones like the Infocom games) are amazing works of engineering and very impressive, but we have seen that now. Very clever, but the magic trick got old a long time ago. We all know the game really isn’t understanding all that much anyway, so reducing the interface to be on a level where both player and parser can understand what is being communicated.
3 Likes
When I do play in advanced parsers like Infocom or Inform, I tend to end up simplifying to VERB NOUN or VERB NOUN WITH SECOND NOUN anyway even though you can get all fancy with the commands. It’s nice to have options and I think those are good for error-checking, but rarely do I bother trying stuff like ENTER THE BOAT THEN UNTIE THE ROPE AND THROW IT ON THE DOCK THEN SET SAIL FOR ADVENTURE.
I’m okay with longer character lengths though, many games have a DOOR, a DOOR HANDLE, a DOOR KNOCKER and the author has to flip some loops if they have to make the first three letters of every object unique.
4 Likes
I think the most important use for more than two words is the verb PUT. It supports real containment, which doesn’t work with a two-word parser. I remember opening a container in a Scott Adams game, and just having a new object appear in the room.
7 Likes
I for one find it astounding that an excellent game like Zork – limited in certain ways, but highly entertaining and challenging – takes up less space than the image file displayed by the icon I select to start the program.
7 Likes
Originally Zork was a longer game residing on a mainframe and had to be split into three parts for personal computers because the entire thing wouldn’t work with memory limitations on smaller systems. They had to adjust each part slightly to be a full game.
Imagine we used to use floppy disks of the capacity that words could fill it! Many original 5.25 floppies were double sided so you could flip them over - each side held about 360k. I really liked the 3.5 disks in hard plastic that were not flippable and held about 1.4 MB. Many people frequently send emails these days bigger than that.
4 Likes
And the funny part? Floppy disks were the high capacity format in the 80s. The original Super Mario Bros. was crammed into a 40 kilobyte cart, and some games for systems like the Atari 2600 or the ZX Spectrum could be as small as 1 kilobyte. The .dat files for Zork I, II, and III being 92 kilobytes each make them pretty fat for the era… And here we are 40-some years later and some modern games take half-a-terabyte, a roughly 100 million fold increase, and by most indications, that increase is as much from no one really bothering with optimized data formatting and compression as actually including more content than was possible with older hardware… though most modern games are not nearly that outrageously big, which is a good thing since more than a terabyte of SSD storage costs an arm and a leg and platter drives not being fast enough to smoothly load large chunks of assets.
Still, it’s kind of mind boggling just how much the developers of old were able to do with so little compute.
6 Likes
I wish that was the mantra for today.
1 Like
I realize some of the inefficiencies in modern programming are as much “That level of optimization would take longer to do than the benefit is worth”, “It already runs well on the target hardware” or “The executives forced it out the door before the devs said it was ready” as laziness, but it does make one wonder what could be pulled off with modern hardware if devs targetting modern hardware were half as creative at getting the most out of what they have to work with as the devs targetting retro hardware or the devs from the 80s and 90s.
6 Likes
As someone who writes code for a living: not nearly as much as you’re probably thinking. Today’s computers are not just faster and have more memory, but are exponentially more complex. They aren’t just souped up versions of the cpu’s targeted by early C code. The days of being able to cleverly hand tune assembly and make something better than what a compiler can do are largely gone. There are (generally very small) edge cases sure, but for the most part simply compiling a high level language down to machine instructions is going to result in better optimized code than you can achieve with any reasonable amount of manual effort. You are far better served by picking reasonable data structures and algorithms in a high level language than trying to squeeze out a few extra bytes or machine cycles in some brittle assembly that fails or performs worse on a different model cpu. In short - compilers are better than human developers for all but a handful of usages.
That said: Many modern devs do use data structures and algorithms less than ideally suited for their purpose, which can result in code that is slower and uses more memory than it should.
7 Likes
In terms of playing parser IF, I just don’t know why you would want to support THEN or . and multiple commands.
Just prompt the user with “type a single SIMPLE command” not “write a short paragraph of what you’d like to do next”. The more you try and make it seem like the parser fully understands English, the more likely you’ll strand the user in the uncanny valley of parsing.
I’m very surprised that Dialog has a lot of support for this in the standard library, given that the author of Dialog has a keen interest in developing modern IF for old 6502-based computers (Commodore 64). Like, wouldn’t you like to get more story and less arbitrary-sentence parser?
The good news with Dialog is that you start with a copy of the standard library and there’s nothing keeping you from cutting out the parts your particular work doesn’t need.
4 Likes
Imo, THEN in the parser serves an important purpose: it lets you queue up a long command and execute it all at once. It’s not about natural-language processing, but about making it convenient to execute N. N. N. E. N. N. N. E. N. E. N. N. E. without losing track of where you are in the pattern!
9 Likes
Exactly. And if you have a repetitive sequence like SVT’s introductory grind of hauling pods, it’s easier to write GET POD. U. D., enter, then click the up button on the parser and go again, than having to click UP three times for each command. It’s honestly a really clever thing.
3 Likes
My hot take is maybe we shouldn’t write games that require a lot of highly repetitive commands. 
7 Likes
Allowing the player to ‘automate’ chains of actions that are well-understood contributes to the feeling that they’re developing an understanding of the game world and reduces tedium. It’s more satisfying to GET CUBE THEN BLORPLE IT THEN N than doing that in three steps.
As far as two-word parsers go, I agree there’s very few puzzles or situations that can’t be reduced down to sets of two-word commands but the feel is just worse. Even that slight step closer to natural language makes
SET MACHINE TO 35
more satisfying than
SET MACHINE
TO WHAT?
35
With the notable wrinkle that sly references to the bare hands puzzle are somewhat harder in a more complex parser.
4 Likes
Is it for most people? That’s an honest question. I’m not arguing anyone remove this capability, but I can’t think of a time I’ve done this in the 40 years I’ve been playing IF except maybe when re-running stuff I already know and even then only rarely. In a game with any random elements, you can get into trouble queueing up multiple commands.
5 Likes
Oh, also. Many optimisation games like Sugarlawn and Suspended require retrying the same game with slight changes. That’s a lot longer to type/copy into the terp with one line per command!
3 Likes
Probably? People naturally want to type some pretty interesting things at the prompt and it takes some experience with parsers to get that beaten out of you.
3 Likes
Is that slang for interpreter?
I can’t keep up with kids these days. Is bad a terrible thing again? …or is it still a good thing?
23 Skidoo! 
3 Likes