Some general ill-informed questions about IF directions

[kevinb]

Hi folks

I’ve had a passing interest in IF since the Zork days, but only recently had time to think about getting more involved myself. But I’ve been doing some Googling, and what I see baffles me a bit. So I was wondering if anybody has any views on any of the following (all of which might, I guess, but old chestnuts, for which I apologise):

1. is IF as a genre still alive? Google searches for anything to do with IF bring up the same small number of names. The impression I get is of a niche interest valiantly propped up by a small bad of heroes. And even then most stuff on the Web seems to be dated 2007 or earlier. Am I missing something? Is there a large number of IF authors and players keeping their heads down?

2. Is there much interest in things like graphics and sound? It seems to me that most people writing IF are not using these things very much. But I can’t figure out if that’s because they don’t want to (for artistic or philosophical reasons), or because the technical challenges are too great.

3. Is Z-code as a platform alive or dead? There seems to be a fair amount of Z5 and Z8 games, but is there more interest these days in glulx (or something else)? While I understand that theoretical advantages of glulx of Z-code, it’s not at all clear to me that glulx is superior to Z-code in day-to-day terms. Is there something that, as an author, I can do with glulx that I can’t do with Z-code?

4. While I understand the historical reason for virtual-machine systems like Z-code, I find it hard to understand why modern development doesn’t focus on up-to-date VM-based systems like Java, if wide platform support is required. I’m guessing (and it is only a guess) that translating a language like Inform into Java source code, or even direct to Java byte-code, is probably not as difficult as putting a man on the moon.

As I said, I’m sorry if these questions are old chestnuts. Any comments welcome.

Best wishes
Kevin

[Juhana]

@kevinb

3. Is Z-code as a platform alive or dead? There seems to be a fair amount of Z5 and Z8 games, but is there more interest these days in glulx (or something else)? While I understand that theoretical advantages of glulx of Z-code, it’s not at all clear to me that glulx is superior to Z-code in day-to-day terms. Is there something that, as an author, I can do with glulx that I can’t do with Z-code?

The main difference is that the Z-machine is very limited in memory and file size. Many modern games just don’t fit in Z-machine anymore. Glulx practically removes those limitations and adds multimedia support that isn’t available for Z5 or Z8.

4. While I understand the historical reason for virtual-machine systems like Z-code, I find it hard to understand why modern development doesn’t focus on up-to-date VM-based systems like Java, if wide platform support is required. I’m guessing (and it is only a guess) that translating a language like Inform into Java source code, or even direct to Java byte-code, is probably not as difficult as putting a man on the moon.

Ah, the good old “we can put a man on the moon, why can’t we do something completely unrelated” argument. I’m sure if we had a budget of 25 billion dollars and the resources of a nation behind us it wouldn’t be as difficult but alas, hobbyists working on their free time with zero budget won’t accomplish quite as much as the Apollo program.

What would be the benefits of compiling to Java compared to compiling to Glulx? What problems would it solve? Being more up-to-date than something else isn’t really a benefit by itself unless it brings along some actual improvements.

[kevinb]

@Juhana

The main difference is that the Z-machine is very limited in memory and file size. Many modern games just don’t fit in Z-machine anymore. Glulx practically removes those limitations and adds multimedia support that isn’t available for Z5 or Z8.

I’m certainly not arguing for keeping old, dead formats alive, but it seems to me that there are some fairly substantial games out there in Z5 and Z8 format. Do we have a clear idea of the pragmatic limitations, that is, in terms of pages or hours of play? My recollection is that some of the old Infocom games kept us busy for a long time back in the dinosaur days.

As for multimedia, it seems to me that it is still possible to write games in Z6 format that support graphics and sound – those tools haven’t disappeared. If I want to write something that, say, allows the user to navigate by clicking on a map, I know how to implement that in Z6 in a way that is playable on available interpreters like Windows Frotz. I presume that I can implement something equivalent using glulx – but I don’t have the first clue how. Are there interpreters available with broad platform support that can play glulx with sound, graphics, and mouse input? I presume the answer must be ‘yes’, but I’m darned if I can find out how to do this.

I could be missing something (not exactly unheard of) but there doesn’t seem to me to be anything in the glulx design that makes it intrinsically superior for multimedia that z-code is/way. We’re still talking about ‘@draw_picture’ and the like, aren’t we?

What would be the benefits of compiling to Java compared to compiling to Glulx? What problems would it solve? Being more up-to-date than something else isn’t really a benefit by itself unless it brings along some actual improvements.

Well, that’s my concern about glulx

As for Java – partly it’s a philosophical thing. It strikes me as a little odd that the IF world is pleased that there’s now a VM that supports 32-bit operands, when there have real heavyweight VMs like Java around for a decade. But pragmatically Java offers

1. Complete 32-bit support, and even 64-bit if you need it
2. Wide platform support, with almost complete platform-agnosticism
3. Object-orientation right at the byte-code level
4. A modern graphical UI, with more-or-less identical functionality on all platforms
5. Mature and feature-rich tools
6. A well-defined resource-packaging format (‘jar’ files)

and, perhaps most importantly:

7. A huge community of skilled developers

My gut feeling is that writing a program that would convert Inform-6 into compilable Java would be a job of nowhere near man-on-the-moon proportions. Of course you’d need to put a user interface around it and provide a library of code to do the actual grunt-work of moving data around, not to mention parsing input, etc.

If we did all that, then I’m thinking we’d probably have most of what was needed to implement IF directly in Java, perhaps with some supporting tools to assist with thinks that are not easy to express directly in a programming language.

I’m just thinking out loud, of course – I don’t really have the faintest idea of the amount of programmer hours required. But, then, I look at the amount of work that has gone into Info, Tads, Gargoyle, Blorb, etc., etc., and it seems clear to me that there are talented people who are willing to spend time on this stuff. I just wonder if the direction things have gone is a profitable one in the long term.

[severedhand]

Head to this page at ifwiki.org for a list of games released in 2010 and their formats:

ifwiki.org/index.php/Games_Released_in_2010

Also do a search for 2010 at ifdb:

ifdb.tads.org/.

The next IFComp is less than 2 months away now, at which point you’ll see a sudden appearance of a bunch of games (20+ ?) which will be state of the art. At least technically speaking

[kevinb]

@severedhand

Head to this page at ifwiki.org for a list of games released in 2010 and their formats:

ifwiki.org/index.php/Games_Released_in_2010

Yes – that’s sort of my point. I haven’t done a complete count, but it seems to me that there are at least as many entries in Z-code format as all the others put together.

I have a nagging suspicion that the authoring of feature-rich, modern-looking IF games could be made technically much simpler. But I suppose that the relatively small number of people interested in creating this sort of content have already invested substantial amounts of time in learning whatever system they use.

[dfabulich (Dan Fabulich)]

@kevinb

1. is IF as a genre still alive?

That question is debatable. Perhaps that itself answers your question.

2. Is there much interest in things like graphics and sound? It seems to me that most people writing IF are not using these things very much. But I can’t figure out if that’s because they don’t want to (for artistic or philosophical reasons), or because the technical challenges are too great.

I don’t think it’s technical challenges, exactly, as much as economic reasons. Most IF is written by a single author and distributed for free. (Typically submitted for a competition.) The author does all the writing and programming. Authors who are good at writing and programming rarely have the ability to also design high-quality graphics and sound, and can’t really afford to hire someone to do those things.

4. While I understand the historical reason for virtual-machine systems like Z-code, I find it hard to understand why modern development doesn’t focus on up-to-date VM-based systems like Java, if wide platform support is required. I’m guessing (and it is only a guess) that translating a language like Inform into Java source code, or even direct to Java byte-code, is probably not as difficult as putting a man on the moon.

There’s a chicken/egg problem here. Most games are not distributed as Inform source code; they’re distributed as compiled Z-code/Glulxe.

So if you sit down and write a Java-based interactive fiction platform like zmpp.sourceforge.net/ the primary feature is that it should run lots of games already published; what you get is a Glulxe VM written in Java, not an Inform VM written in Java.

If people distributed Inform source more often, maybe it would be better/easier to compile the source without Glulxe, but that’s not the world we live in. (And anyway, compiling Inform 7 is pretty challenging. For simplicity, cross-compiling Glulxe as an intermediate language works well.)

Also, Java isn’t as popular as it used to be on the client side. (It’s a particularly bad fit on iOS.) Instead, we’re seeing more infrastructure focus on deploying IF games to web browsers, where there’s no interpreter to install. code.google.com/p/parchment/

Minified JS source is the bytecode of the web. hanselman.com/blog/JavaScrip … anity.aspx

[severedhand]

I have a nagging suspicion that the authoring of feature-rich, modern-looking IF games could be made technically much simpler. But I suppose that the relatively small number of people interested in creating this sort of content have already invested substantial amounts of time in learning whatever system they use.

Eh, I don’t think this is really the reason. Inform 7 has only existed a few years. Arguably it makes the basic tools easier to use than ever. To do really basic stuff is probably easier in Inform 7 than even in all the other languages which are considered more newbie-friendly. But the upper limits of Inform 7 are as at least as sophisticated as TADs etc.

When you see all those Z-code games in that list - even if I write something in Inform 7, if it’s small enough, it still comes out as a Z-code file. If it grows sufficiently big or complex, or I add graphics or sound or things like that, then it becomes Glulx (automatically). As an author and someone who’s only touched Inform at all as of last year, I have no emotional investment in z-code, or necessarily much interest in the file format per se, only that whatever language I use can do what I want.

I think it’s more like what dfab said - graphics and sounds are time-intensive and take special skills to add. And in the end, there’s also that line of ‘when is this still a text adventure?’ People who like parser based stuff, very broadly speaking, probably aren’t pining to see lots of graphics added.

[Juhana]

@kevinb

I’m certainly not arguing for keeping old, dead formats alive

It is a bit confusing that you say graphical IF should be written using a legacy, almost forgotten Z6 format instead of newer and more popular Glulx, but at the same time argue that Glulx should be dropped in favor of Java because it’s newer and more popular…

My recollection is that some of the old Infocom games kept us busy for a long time back in the dinosaur days.

Even Infocom had to drop a lot of content because of the limitations of Z-machine, starting all the way back from Zork that had to be split into three games. Also, the length of the game is not directly related to memory usage or file sizes.

As for multimedia, it seems to me that it is still possible to write games in Z6 format that support graphics and sound – those tools haven’t disappeared. If I want to write something that, say, allows the user to navigate by clicking on a map, I know how to implement that in Z6 in a way that is playable on available interpreters like Windows Frotz.

Sure, you’re free to use the old tools. The thing is that most of the new tools are developed for Glulx only, most notably Glimmr. The old tools aren’t obsolete, but I don’t think anyone is actually making anything new with them.

I could be missing something (not exactly unheard of) but there doesn’t seem to me to be anything in the glulx design that makes it intrinsically superior for multimedia that z-code is/way. We’re still talking about ‘@draw_picture’ and the like, aren’t we?

Again, there are size/memory limitations that prevent using Z6 in larger projects. And that most of the tools are being developed for Glulx only.

My gut feeling is that writing a program that would convert Inform-6 into compilable Java would be a job of nowhere near man-on-the-moon proportions. Of course you’d need to put a user interface around it and provide a library of code to do the actual grunt-work of moving data around, not to mention parsing input, etc.

Right: I’m still not seeing any concrete benefits (as in “you can’t do X now, but with this you could do X!”), but what you describe would definitely not be an improvement for many people. The benefit of the interpreted formats is that you can use your favorite interpreter with the look and feel that you like without having to fiddle with settings every time you play a new game. If bringing Java into the picture would provide user interface improvements over the existing interpreters, it’d be much easier to just make a new interpreter with Java that runs the existing story files. Unless having the story file as native Java bytecode instead of some other format would actually have any benefit over simply making a new interpreter, I don’t see the point in switching.

I don’t really have the faintest idea of the amount of programmer hours required.

A lot.

I have a nagging suspicion that the authoring of feature-rich, modern-looking IF games could be made technically much simpler.

Well, you said yourself that you have no experience in using any of the modern tools or what techniques they use. This is quite a bold assumption to make from that background.

[kevinb]

@dfabulich

There’s a chicken/egg problem here. Most games are not distributed as Inform source code; they’re distributed as compiled Z-code/Glulxe.

So if you sit down and write a Java-based interactive fiction platform like zmpp.sourceforge.net/ the primary feature is that it should run lots of games already published; what you get is a Glulxe VM written in Java, not an Inform VM written in Java.

It seems to me that the problem with ZMPP (and with glulx to some extent) is that it does exactly what it says on the box – it preserves. It does nothing to move things on, nor does it provide an easy moving-on path for people who want to take it. These VMs – glulx and Z – are tied to a procedural, console-based mode of programming that doesn’t sit very well with modern operating environments. Most people who write code these days that has a strong element of user interaction think of a user interface being object-oriented and event-driven. The Z-machine idea of treating mouse clicks as a kind of keystroke, just so the program can work like a 1980’s VT220 app, can hardly fail to raise a ‘huh?’ reaction in anybody under 40.

It’s not clear to me that a primary feature of a new IF system is that it should run lots of existing stuff – there’s already plenty of software out there that can run Z-code and glulx. It seems to me that a more important feature is that it should allow modern-looking, cross-platform games to be created with a minimum of authorial pain. Of course, I appreciate that it would take a lot to get people to drop Inform and move to something completely different.

Also, Java isn’t as popular as it used to be on the client side. (It’s a particularly bad fit on iOS.) Instead, we’re seeing more infrastructure focus on deploying IF games to web browsers, where there’s no interpreter to install. code.google.com/p/parchment/

I’m not sure that the popularity of Java is much of an issue. The Java-based system I envisage would (hopefully) require relatively little Java knowledge, and none at all of the Java UI model. Rather, I think the important point is that pretty much every desktop computer on earth has a Java VM installed, or is capable of having one installed. I’m aware of the iOS issue, and Android presents similar challenges (perhaps for different reasons). The problems with Android could, I think, be overcome with nothing more than tiresome code-grinding. I’m not sure about Apple, though.

In addition to the other advantages of Java I mentioned above, I might add:

8. Built-in serialization support, so saving and restoring game state could be trivial (and platform-neutral)
9. Widely-available IDEs
10. The ability to extend as much or as little of the built-in world model, user interface, etc., as you like via the inheritance mechanism without touching any underlying libraries (because Java uses run-time linkage throughout)

I guess my fundamental concern is that there are relatively few people working on VMs for IF and, however heroic and talented they are, they’re trying to do more-or-less single-handed what the vast resources of Sun Microsystems did over ten years.

[Trumgottist (Rikard Peterson)]

Maybe you could point more specifically to things you find missing in current games instead of focusing on their technical innards? Most people (or me, at least*) don’t care that much about if a game is running on Java, TADS, Glulx, Glulx-in-Javascript or whatever. So to me a statement like “things would be so much better and more modern if they were running in Java” is pointless. What is it that you want to see?

• That statement is not entirely true, since I happen to be very interested in the technical side of things. (I’ve done quite a bit of hobbyist programming and am considering doing a game with Unity.) But for the purposes of a discussion like this, it can be considered 100% true. I consider any other approach to be approaching things backwards. The right tool for the right job.

[kevinb]

@Trumgottist

Maybe you could point more specifically to things you find missing in current games instead of focusing on their technical innards? Most people (or me, at least*) don’t care that much about if a game is running on Java, TADS, Glulx, Glulx-in-Javascript or whatever. So to me a statement like “things would be so much better and more modern if they were running in Java” is pointless. What is it that you want to see?

Well, I guess I should try to separate my actual pragmatic issues from my philosophical ramblings…

Pragmatically, glulx does not seem to provide a way to provide the sort of graphical and user interface features that I believe would enhance an IF game/story. There doesn’t seem to be a way, for example, to provide for out-of-story actions (save, restore, open a file, undo last move, change screen colour, whatever) other than by typing commands at a prompt. There doesn’t seem to be a way to provide a drop-down menu so that the user can select "Go to->Local->Prancing Pony’ rather than typing ‘n, n, n, sw, se, n, s…’. This is perhaps less of a big deal in IF than in any other genre of gaming, because you’re exercising the keyboard all the time anyway. But I do wonder whether providing more familiar UI elements would increase the appeal of IF among people who grew up after the invention of the mouse

To be fair, at least some of this comes down to interpreter implementation, rather than VM architecture. I’m not sure that all of it does, however.

The philosophical ramblings really come down to whether the kind of VM that currently does duty for IF is really a sound long-term proposition. I think that people who work in this genre have come to cut their coat to fit their cloth – that is, people see the way IF should work as fitting the kind of technical resources that have historically been available.

For example, I played a game recently that was entirely text-based, but had a sort of compass-rose thingie in the status bar. My first though was to click on that as an alternative to typing, but it didn’t do anything. Now, if I could navigate by clicking the compass rose in Zork nearly twenty years ago, why is it that such a facility is not generally available these days? Is it because people prefer to type? Or because it’s technically a drag to implement in a satisfactory way? Or because that’s just not the way IF authors think?

As computer programmers go, I’m an oldie. My colleagues mock me because I find it more efficient to type ‘ls’ than to pop up some garish window full of icons. So I’m certainly not suggesting change for the sake of change. I just wonder – and it’s nothing more than my musings – whether the shape of modern IF stories owes more to 20-year-old technical exigencies than it does to conscious choice. Declaring a bit of an interest here, I worked on and around the JVM, for Sun Microsystems, until recently. The JVM always struck me as a fantastic, ready-made target platform for IF languages, and it’s always surprised my that nobody took advantage of that.

I don’t know – maybe it’s just me. Looked at from outside, the world of contemporary IF development looks a bit like it’s stuck in the '80s. Perhaps it looks completely different from inside? Or perhaps it doesn’t matter?

As you say, “the right tool for the right job”. But (pardon the cliché) if your only tool is a hammer, everything looks like a nail.

[tove]

@dfabulich

Authors who are good at writing and programming rarely have the ability to also design high-quality graphics and sound, and can’t really afford to hire someone to do those things.

Hm, to be egocentric here for a bit, I’d argue that I have no problem designing quality graphics – arguably, I am better at creating graphics than writing evocative prose – or obtaining sounds (freesound.org is great for fx, and I have several musician friends, including my significant other, who are very indulgent when I ask for game-appropriate tunes), and the reason I don’t put them in my IF games is that, as a designer with a rather minimalist mentality, I don’t think I need them to make the point I’m trying to make. If the game I want to make needs to be strongly visual, I’m probably not going to make it as an IF game.

I’m not saying there aren’t games in which the images act as part of a unified whole (Everybody Dies and gravel’s WIP come to mind), but their inclusion is a conscious design decision, and it wouldn’t be the right decision for every game. And I think that’s why we see so few illustrated IF games, not just the logistical issues.

[kevinb]

@tove

If the game I want to make needs to be strongly visual, I’m probably not going to make it as an IF game.

Speaking (again) as something of an outsider, there does seem to be a bit of fuzziness about whether IF is aiming at literature or gaming. I’m not sure, but I don’t think that the people who wrote Zork, et al., thought they were producing anything other than games. Some modern work seems to be squarely in the same tradition, while some seems to be aiming at something more cerebral.

I suspect that the more modern user interface whose lack I am bemoaning might be more of an issue for people who see themselves working more in the Zork tradition, as it were. Many of these games feature map-based exploration, for example. So would it (perhaps) not be better if the player could see a map displayed graphically rather having to remember it, or draw one on paper? And if it would be better (and I accept that many people might not agree), would it not be better if the interpreter/VM/compiler produced it automatically, rather than leaving it as an authorial task?

Again, just musing.

[dfabulich (Dan Fabulich)]

@kevinb

It’s not clear to me that a primary feature of a new IF system is that it should run lots of existing stuff – there’s already plenty of software out there that can run Z-code and glulx. It seems to me that a more important feature is that it should allow modern-looking, cross-platform games to be created with a minimum of authorial pain. Of course, I appreciate that it would take a lot to get people to drop Inform and move to something completely different.

If your goal is “modern-looking, cross-platform games to be created with a minimum of authorial pain,” I’d say you’ve got that today with the Inform IDE + Parchment.

If you write a game in the Inform IDE, it outputs Parchment, which you can upload to your favorite website and just distribute the URL. Want to change the UI? Tweak the CSS in Firebug or Chrome Dev Tools. (It’s MUCH easier than Java’s AWT/Swing.)

Today’s Inform authors don’t have to know anything about Glulx’s oddities. More generally, Inform happens to output Z-code and Glulx (mostly for historical reasons) but authors don’t have to drop Inform to switch off of Glulx.

If you’re bored, you could take the ZMPP code and add an Inform compiler; there would be no Z-code/Glulx left. But this would not reduce the pain for authors or players.

pretty much every desktop computer on earth has a Java VM installed

This is no longer true, if it ever was. OSX Lion ships without a JVM installed. Most Windows boxes have an old JVM installed somewhere, but fewer and fewer do. And the JVM has never been widely deployed on Linux.

JavaScript is the only pre-installed cross-platform GUI technology now, for better or worse.

In addition to the other advantages of Java I mentioned above, I might add:

JavaScript has these benefits, too, and it works cross-platform, including iOS, today.

I guess my fundamental concern is that there are relatively few people working on VMs for IF and, however heroic and talented they are, they’re trying to do more-or-less single-handed what the vast resources of Sun Microsystems did over ten years.

Don’t worry. ZMPP and Parchment are written on top of high quality VM implementations. (JavaScript VMs are pretty advanced too, these days!) Parchment in particular generates JS code that the browser can compile/optimize on the back end.

Don’t get me wrong; there are bugs. ZMPP and Parchment could be even faster and more beautiful (more like Undum). Some games don’t even work in ZMPP/Parchment. But the bugs get fixed and things get better.

[maga (Sam Kabo Ashwell)]

@kevinb

Speaking (again) as something of an outsider, there does seem to be a bit of fuzziness about whether IF is aiming at literature or gaming. I’m not sure, but I don’t think that the people who wrote Zork, et al., thought they were producing anything other than games. Some modern work seems to be squarely in the same tradition, while some seems to be aiming at something more cerebral.

I think the point of IF is that gaming and literature don’t have to be mutually exclusive or in conflict: you say fuzziness, we say synergy. (But yes, there is a spectrum of opinion about the best balance.)

Infocom in its day spent a great deal of effort in promoting IF as a literary form: they generally preferred ‘interactive fiction’ over ‘text adventures’ for precisely this reason.

[gravel]

@kevinb

For example, I played a game recently that was entirely text-based, but had a sort of compass-rose thingie in the status bar. My first though was to click on that as an alternative to typing, but it didn’t do anything. Now, if I could navigate by clicking the compass rose in Zork nearly twenty years ago, why is it that such a facility is not generally available these days? Is it because people prefer to type? Or because it’s technically a drag to implement in a satisfactory way? Or because that’s just not the way IF authors think?

There’s extensions (and a tutorial!) that make it relatively straight-forward to implement a compass rose, save/quit/restart/restore buttons, etc. I am not sure about drop-down boxes, but hyperlinks are an option, so I could probably put in something similar.

As a player, it is 2-3 times as fast and less irritating to type “save” than it is to move my mouse to click the button. It’s one thing if you’ve got a game with one keyboard hand and one mouse hand, and another if 95%+ of the game is played by keyboard.

As an author, introduction of graphical elements means you’ve got to spend a significant amount of time considering the GUI. I added graphical elements to my WIP, and while I like the results, it required much, much more work than I expected, largely because I’m not very familiar with the extensions and requirements and I was making it up on the fly. I’ve seen some tremendously promising graphical work being done, though, and lots of people stepped up to make sure I could do what I needed. It’s also a little dodgy because you have to learn what each interpreter will do with your code, and sometimes the results are unexpected.

But I have not, as yet, played many games where the graphics felt like a vital part of the game and if they were gone, I’d miss them beyond the “oh, pretty”. And I haven’t played any IF where the sound really worked for me.

So some of it is, I think, very sensible design decisions - why would a game designer add something that would take a significant amount of work and experimentation but not add dramatically to the game? Something most players don’t expect and won’t miss?

I am getting the impression, though, that there’s growing interest in feelies and add-ons, at least among a certain cohort of IF writers, and that includes using the interfaces in different ways. And the tools are more and more accessible; for example, there are now opportunities to add animation to the graphics capabilities.

[kevinb]

@dfabulich

pretty much every desktop computer on earth has a Java VM installed

This is no longer true, if it ever was. OSX Lion ships without a JVM installed. Most Windows boxes have an old JVM installed somewhere, but fewer and fewer do. And the JVM has never been widely deployed on Linux.

JavaScript is the only pre-installed cross-platform GUI technology now, for better or worse.

I can see how this could end up as one of those my-programming-language-is-better than yours discussions My personal background makes me prefer working in Java to JavaScript, in the same way I prefer a nice bottle of wine to beating my face against a brick wall. But I appreciate that opinions differ and, while I could raise what at least I believe to be knock-down arguments to support my position, I don’t suppose anybody else will be convinced (or, as has been pointed out) care much. And, in any case, I make my living writing Java code, so I’m hardly disinterested. I’ve never encountered a computer without a modern JVM installed, but I’m told that such oddities do exist

My point is that there are modern VMs. If there is a choice of modern VMs, then I think that strengthens my original argument rather than weakening it.

Taking ZMPP and removing the intermediate Z byte-code step would, as you say, benefit nobody very much. You’d still be working with something designed primarily for the console. I’m wondering whether we can (or should) severe that connection to the 80s altogether. And, if so, what the technologically least painful way to do this might be.

[bcressey]

@kevinb

Pragmatically, glulx does not seem to provide a way to provide the sort of graphical and user interface features that I believe would enhance an IF game/story. There doesn’t seem to be a way, for example, to provide for out-of-story actions (save, restore, open a file, undo last move, change screen colour, whatever) other than by typing commands at a prompt.

I believe Zoom provides all of these options in its GUI.

@kevinb

There doesn’t seem to be a way to provide a drop-down menu so that the user can select "Go to->Local->Prancing Pony’ rather than typing ‘n, n, n, sw, se, n, s…’.

You’re right that custom menus are not possible with the current incarnation of Glk. I am not sure you’ve really thought through the UI implications of this, however.

Suppose you are playing an IF game in a browser like Chrome - what would it mean to add a “Go to” menu with these choices? Assuming it were even possible, how would you justify usurping the normal application behavior?

There are many devices capable of playing IF that have nothing like the standard desktop notion of multiple windows with independent menus.

That said, some location-rich IF games (like Nightfall) have implemented a >GO TO command to ease the cognitive burden of travel.

@kevinb

Declaring a bit of an interest here, I worked on and around the JVM, for Sun Microsystems, until recently. The JVM always struck me as a fantastic, ready-made target platform for IF languages, and it’s always surprised my that nobody took advantage of that.

From the T3 Virtual Machine Design Goals:

@MJR

The Java VM lacks several key features that are essential for a text adventure application: undo, save and restore, and run-time typing (of values of primitive types) are the most problematic omissions. In addition, the Java object model is significantly different from the TADS object model, and is not as well-suited for interactive fiction applications; while the TADS object model could be emulated in JVM code, it would be considerably less efficient than implementing the TADS object model in native code within the VM.

Note that the above was written in 2006 and may not be as relevant to more recent incarnations of the JVM.

[kevinb]

@gravel

As a player, it is 2-3 times as fast and less irritating to type “save” than it is to move my mouse to click the button. It’s one thing if you’ve got a game with one keyboard hand and one mouse hand, and another if 95%+ of the game is played by keyboard.

Yes, indeed. This is exactly the same argument I use when my younger colleagues (which, these days, is all my colleagues) ask why I prefer to work with command-line tools. It’s much faster, I say, to type ‘DEBUG=1 make’ than to spend time hunting through a bunch of menus and dialog boxes to find where the IDE developer hid the option to enable debug builds.

But, but, but…

It’s a lot quicker to hunt through a bunch of menus, etc., etc., than to figure out that ‘DEBUG=1 make’ is the right thing to type when you’re staring at a blank screen and have no idea what to do next.

The ‘it’s quicker to type…’ argument really only works when your audience is computer programmers or dedicated enthusiasts. But if the target audience for IF is, indeed, computer programmers and dedicated enthusiasts, I guess that’s not a deal-breaker.

[gravel]

Yeah, that was just “me as player”, and not “me as game designer”. I agree that there should be options. Or at least I’m open to argument. I’m trying to figure out now if there should be buttons in my WIP for that sort of meta stuff. If I could come up with a look that isn’t unrelentingly 1994, I’d be more tempted.

(Can you go file -> save in interpreters? I’ve never tried.)