Inform 7 Extension “Recorded Endings”

Coming out of my fiddling with Alabaster is an extension for multiple-ending games. Designed for Glulx only (because it uses external files), it keeps track of all the endings the player has found and allows him to review them with an ENDINGS command during the final question.

I’ve occasionally kicked around the idea of a similar extension for games that rely on a fixed set of randomized starting parameters (like the “When in Rome” games, or “Act of Murder”). The idea would be that an external file would record which starting parameters the player had already solved and avoid giving him the same scenario again before he had worked through all of the options. But it is hard to come up with a general syntax for this. Hrm.

6 thoughts on “Inform 7 Extension “Recorded Endings”

  1. I haven’t looked at the extension yet, but perhaps it could be made to work on the Z-machine too, using V5’s extended save/restore features?

    Regarding the randomized starting parameters, perhaps the author could define a table (with whatever schema he needs) and then the extension could use I7’s table serialization to keep track of it. I think everything you’d need to check for unique rows and generate new random rows, without knowing the table schema until runtime, is already compiled into the game. Although it would take some delving into I6, and you’d need to restrict the table to certain column types (e.g. number and kind of value).

    • I confess I’m not that motivated to try to adapt this for the z-machine, but if anyone else wants to try, they’re welcome.

      “I think everything you’d need to check for unique rows and generate new random rows, without knowing the table schema until runtime, is already compiled into the game. Although it would take some delving into I6, and you’d need to restrict the table to certain column types (e.g. number and kind of value).”

      Okay, interesting suggestion. If I come back to this, I’ll see if I can approach it that way.

  2. I’m already using it. Using endings as data for the game to look at to base decisions on should also make for some interesting possibilities, beyond just reminding the player of what he/she has done so far.

    • That’s an interesting suggestion.

      It had vaguely occurred to me that the game could check the endings file and if, say, the player had already encountered endings A-F but not G, offer broader/more explicit hints about the G outcome this time around (or something along those lines). But I hadn’t really considered having the game morph in more significant ways.

      Of course, I suspect some players might find this frustrating, as it would interfere with their attempts to mentally map out how the game works. But it might be an interesting thing under the right circumstances.

      • My basic model:

        1. The game involves 5 single room puzzles.
        2. Solving any puzzle creates a game ending.
        3. The fifth room is spoilery of the other four rooms and doesn’t make sense without having played through them, so it is not available until the other four have been completed. It’s new availability is shown dramatically in new game-start text.

        I happened to already be planning to use this basic model when you released your extension, but had not started coding that part of things yet, so the timing was pleasant.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s