Another Vorple Question

I may be misunderstanding the situation. If I’m wrong, please fill in the blanks for me.

It appears that Vorple exists (or will exist) in two forms – for Undum and as an Inform 7 extension.

The latter appears, at present, to suffer from a very significant limitation, which is that it will only work with Z-machine games, not with Glulx games. Thus the size of the game will be, for the present anyhow, quite limited. When a possibly large Vorple extension is added to an existing story… Also, will it be possible to test the Vorple display in the IDE, or will authors have to hit the Release button each time they want to test how their Vorple code looks; losing, in the process, the ability to take advantage of the other debugging features of the IDE?

The Undum side appears, at first glance, to be more open-ended (provided you’re willing to roll up your sleeves and learn Javascript and HTML 5) – but an Undum story can’t be saved and restored at a variety of points. You can save exactly ONE version, which will automatically load the next time you launch the story. At that point, if you decide you want to try an alternative path through the story, you have to start over again from the very beginning (and lose your currently saved story state when you do so). There seems to be no way to save a “bookmark” for the story before making what may be a significant plot choice and then return to the bookmark later and try the other branch.

If true, this renders Undum utterly unusable for any sort of serious work.

Any insights on this question, from the developers or others, would be much appreciated. I like the appearance of Undum/Vorple stories a great deal, but in the absence of a solid save/restore mechanism, I would have no incentive to learn Javascript or HTML 5.

Vorple is highly experimental, and as such is really just for those willing to get their hands dirty. In the future we can expect full IDE support for it.

However, the future will likely be based on the Glk stylesheets proposal instead.

You have the current situation pretty much covered and as Dannii said, things might and will change radically as things settle down to their tracks.

Currently it works (for some definitions of “works”) only with Z-machine, but that’s only temporary. I’m waiting for Parchment to get the Glk stylesheets implementation because it will have the VM-level support Vorple needs to communicate with Glulx stories. It wouldn’t be smart to duplicate work or create a competing non-standard implementation. As soon as Glk/Parchment gets to that point, it won’t take long to get Vorple up to speed.

You can stretch the Z-machine limits a little by moving things like in-game help menus from the game for Vorple to handle, but that’ll help only if you’re right on the border and need to squeeze in just a couple of paragraphs more. Vorple itself is a very small extension in Inform’s point of view (the core is only 546 words at the moment).

Most likely yes at some point in the future. Fortunately in most cases testing a Vorple story isn’t as big a problem as it might be, since you can test the story and game logic as a text-only version in the IDE and test the Vorple features separately in a browser. (It does get annoying to have to do the release - copy story file - reload browser again and again.)

This is true, partly because of technical limitations and perhaps partly because the save feature is meant to be just a bookmark where you can continue reading later rather than a videogame save file. Vorple won’t bring a change to this situation so you might want to make a feature request to the Undum project.

You get 5MB of localStorage data, and 50MB of IndexedDB which should be enough for many Undum saves. Except they’re both messy to deal with. I’m planning to offer Parchment’s storage library to Undum, once I’ve finished writing it.

In the meantime, it’s apparently not hard (for the Javascript-literate, I am told) to write a hacky multiple-UNDO function into Undum. (I used one in Cavity of Time, courtesy Jon Ingold.) This obviously isn’t quite the same thing as multiple saves, but for 95% of the times when you need a save it does the job.

I can see that that would be possible. I know just enough about Javascript to understand that Undum is pushing each user action into a list (which will then be saved and replayed). So yes, you should be able somehow to pop an action off of the list.

I’m definitely going to bring this topic to I.D. Millington’s attention. I understand that there may be technical issues, to do with browser security features. But for me, it’s a total deal-breaker. There is no way I would consider using Undum for any sort of creative work, because it’s essential that the user be able to store multiple save points and restore to any of them at any time. Without this feature, a branching story (which is one of the main things Undum is apparently designed to produce) becomes an absolute nightmare for your poor hapless reader.

I wouldn’t be so chapped about this if Undum didn’t provide such a wonderful UI. I really, really like what I see! But I’m not enough of a Javascript jockey to be able to figure out a slick workaround for story-point saving. That feature has to be built-in before I’ll consider using Undum.

Interesting. I found a page (caniuse.com/indexeddb) that suggests IndexedDB won’t work at all on iOS Safari or on Android. To me, that would be a good reason to avoid using it.

I’ve also learned (unless I didn’t understand what I read) that a game/story save-point stored in localStorage can’t be exported to any other browser. Which makes sense. It’s a definite limitation for IF purposes, but one that many users won’t even notice, unless they’re reading a given story at different times on their home and work computers, for instance.

It seems that using localStorage rather than a cookie ought to work well for Undum. But yes, there are details to be considered. For instance, does the user get to name the save-point before storing it?

I wish I knew enough Javascript to be able to help with this project. The roadblock for me is, I’m reluctant to spend a lot of time studying Javascript until I can be pretty certain that readers/players WILL be able to store and reload multiple story save-points. If that capability never becomes real, then any time I put into studying Javascript would be wasted, as I wouldn’t end up being able to use Undum.

FWIW, as a reader, I don’t give a fig about having multiple saves. I can count on one hand the number of times I’ve wanted to keep track of multiple saves in a text game (or any game, really).

However, that doesn’t keep me from agreeing that Undum’s save system needs revamping. My main problem with it is that it doesn’t allow for randomness (or for any other state change that doesn’t come from the player clicking a link).

Even so, Undum’s current save mechanism might restrict you more than you’d like. Unless I’m misunderstanding something (and I don’t think I am) you can’t rewind even to ONE stored save point, other than by quitting and then reloading the page. If you do that, the game will automatically scroll forward to the save point by loading the cookie.

If a story contains two branches that may be significant (and as a player, you won’t know which branch points may be significant), you will be unable to restore to before the first branch point once you’ve saved the second branch point. Since Undum games will inevitably be light on puzzles (as there will never be any commands that are not displayed as links in the UI), branching will assume more importance in terms of the reader’s experience of interactivity.

I understand what you’re saying about randomness. There is a random number generator, but I believe it’s seeded during your initial run-through of a game, and doesn’t change after that, thus insuring that the same set of commands always leads to the same result.

Things like NPCs who pursue their own quasi-random agendas would be very difficult to create in Undum, because, indeed, the story state is saved as a pure list of user commands. NPCs don’t exist as objects at all. (Neither do rooms, for that matter.) But I’m pretty sure that, given a decent save/restore mechanism using localStorage, one could create an NPC object whose state could be stored as part of the database. It wouldn’t be stored unless the author wrote the code, and that would mean parsing the data while restoring it, but I’m pretty sure it could be done.

I think everything you’ve said is correct, except the part about this setup being more restrictive than I’d like it to be. In a game of relatively “pure” branching narrative, player commitment to a given branch is where a good deal of the emotional engagement comes from, in my opinion–it all becomes pretty boring when there’s nothing at stake and I can just rewind to see what would have happened had I made a different choice. The commercial concerns doing branching narrative (Tin Man Games, Choice of Games, Echo Bazaar) are all set up as Undum is, with a single save game and no way of backtracking. I feel like that’s the right choice.

That’s interesting, I didn’t realize that. Replaying choices rather than saving state still doesn’t seem flexible enough to my mind…

Yeah, what I’m thinking of doing would definitely be something more like Undum++, with at least some game entities represented as program objects… The chances of my getting to it before a major life-change that’s coming this summer are pretty slim, though…

I’ve never played that type of game. Speaking theoretically, though, I would think that if a story depends for its emotional engagement on the feeling, “OMG, it would be such a hassle to start over at the beginning and go through all this again!”, that’s a pretty artificial form of emotional engagement. It’s really quite different from emotional engagement with the story, isn’t it? If I’m emotionally engaged with the story – the characters, the drama, and so on – I would probably be more likely to want to go back and find out what happens if I don’t tell Marcia that Bruce is cheating on her. (Or whatever.)

Undum already does uses localStorage, but it doesn’t always work when you’re running from file:. But Parchment’s storage system will attempt to use flash in those cases.

CYOA in general places more of an emphasis on continuous narrative flow, which is broken up by backtracking and restores. Too, a CYOA game will have far fewer player commands than an IF of comparable size, chosen from a much smaller range of commands (and probably involving less in the way of puzzle-like obstructions), so finding your way back to a particular spot is vastly less annoying.

So, yeah, multiple saves would be a pleasant enough feature, but one I doubt I would ever use as a player.

You’re saying things that I’m not equipped to understand, unfortunately. If it doesn’t always work, does that mean the Save button sometimes fails when the html file, the undum.js file, and the game .js file are all stored on the local machine? And if so, is that a known problem with localStorage, or is there something specific about how Undum uses localStorage (such as not throwing an exception???) that is not perfectly designed?

No? Excepting Echo Bazaar (the appeal of which I find hard to grasp), these are the types of games that Undum is designed to help you write. The Tin Man games are very overtly tied to the physical form of the paper CYOA gamebooks they are based on, but Choice Of games have very similar affordances to Undum games. You might want to check some out before you starting writing yourself; I think that there are both positive and negative lessons to be learned from them. You might also want to explore ChoiceScript, which while it produces HTML/Javascript games that are visually much cruder than Undum, is more friendly to authors.

From my perpective, there are a couple of errors of emphasis here. First, the player’s feeling generally isn’t “What a hassle to have to start all over again!!!” but simply “I can’t just press the back button here–I’ve got to live with my choice.” There’s a big difference.

More importantly, when you’re discussing emotional engagement, what you’re describing seems to be the player’s interest in the author’s edifice as a whole (a natural perspective for an author to take), whereas I’m talking about the player’s engagement with any particular choice. If I know that I can easily zip right back to the previous choice (or farther), then the choice doesn’t make me anxious/expectant in the same way that it does if I know the back button is there. It matters more when I can’t easily undo it.

(Interesting shifts in the type of choice-level engagement can come about if we tweak valences a bit. For instance, Tin Man’s games (which feature permanent death, sometimes quite cruelly delivered) have different difficulty levels. The novice mode gives you 10 “bookmarks”–save points that you can roll back to at any time. But these are limited, and you can’t remove a bookmark once you’ve placed it. So now you’re still anxious about choice, but part of the nervous energy is now also about strategy–is this a place where I might need to return to? This works with Tin Man games because of the high chance that you could die outright; I’m not sure it would be a good thing in a less cruel, game-y work.)

There may well be a place for a multiple save system. But I think I’d only want to use it once I’d finished a work. “What would have happened if…” is a question whose answer is most satisfying when you already have a sense for the shape of the work.

Thanks for the suggestions. I have now tried a little of “Choice of the Vampire,” I think it was called. Stultifyingly bad – a mad barrage of cliches, and not the slightest brush with emotional involvement. I did think it was interesting that the player’s profile is built up based on the choices he or she makes. Whether that has any actual effect on the story, or whether it’s all just tossing in bits of allegedly appropriate detail, I don’t know. Nor care.

What interests me about the Undum interface is how it might be subverted in such a way as to implement something closer to IF. I can see that it’s designed for CYOA, and that probably explains the Save mechanism. But that’s not its most salient characteristic, in my view. Its most salient characteristic is that it’s a very, very nice UI. There’s really nothing like it in the Inform/TADS universe, a lack that I have bemoaned in the past, to no avail.

One more recommendation, then: Blink, which powered The Binary from the last comp. It’s not as pretty out of the box as Undum, but it seems to be designed to produce more IF-like games. The interface is also as sophisticated as that of Undum, and it wouldn’t take much CSS tweaking to get it looking just as nice (assuming you can find a good CSS tweaker!). Of course, Blink is not officially released…

Apparently the author is running a fund-raising campaign right now, actually:

indiegogo.com/Bloomengine-Blink

He really should be advertising that here, on Planet-IF, etc…

It’s a browser problem. Certain browsers (Chrome) just hate file:. But I consider file: to be a major target for Inform 7, so I can’t ignore it.

I’m not quite sure what you mean by ‘closer to IF’, but I would counsel strongly against using Undum for an IF-shaped narrative (that is, one that’s mostly premised on traversing a stable physical map, interacting with objects, and solving puzzles.) I’ve seen it done in a number of games, and it pretty much always feels like a horrible mismatch; you get all the annoying limitations of CYOA without its particular strengths.

(Even before browser-based games, there were paper gamebooks that, as far as I can tell, were basically attempts to simulate an IF game or a dungeon-crawl RPG by people who didn’t know how to code. Playing one is like watching a seal try to crump: sort of charming, but you hate to encourage it.)

Yeah, I remember gamebooks. They were extremely lame.

Can you give a couple of examples of games that tried to combine IF-style inventory and maps with a different type of interface? I had a look at “The Binary” tonight, and perhaps it qualifies. But it was the narrative that failed to engage me – that and the physical appearance of the interface, which I felt was squeaky rather than elegant.

I’m not sure what you mean by the “particular strengths” of CYOA. That’s probably just my innate snobbishness shining through, but I can’t think of any strengths offhand.

It’s clear that puzzles in an Undum story would be easy or nonexistent … although it would be quite feasible to implement story branches where the reader gets killed or just never encounters the meat of the tale, which I supposed counts as a puzzle. You could easily create secondary objects that would only show up when one examined a primary object that’s mentioned in the main text (a brass key lying in the dirt beside a potted palm, to give a hackneyed example). That hardly qualifies as a puzzle, but it does require that the reader be paying attention.

Branching conversation topics (as in “Galatea,” which I guess most people consider IF) would work quite well, I think.

It’s also clear that there would be little need for a physical map. The PC could wander quite freely from one situation to another. That’s very freeing for the narrative. The movement from “room” to “room” in IF is a rather stilted, artificial process that hampers the narrative flow, though experienced players glide past it.

Trying to create a complete IF-style inventory system would be a nightmare, because you (the author) really don’t want the reader dropping things here and there on a whim. But having a small inventory that’s listed in a box in the sidebar, with a pop-up menu for each item (look at the key / use the key / give the key to Susan) that was dynamically constructed based on the situation (in this case, whether Susan is present) should be manageable at the code level. I’m curious whether you think this would be “a horrible mismatch.”

I really would like to know more about why you feel this way! If I’m misjudging the potential of the medium (that is, the Undum-style text medium), I’d rather know about it now than after I spend three months writing something that doesn’t work.