Inverted Parser

Upon watching the video celebrating the end of the GMTK Game Jam 2023, and seeing many games incorporating the "Roles Reversed" theme, I wondered: isn't it possible to create an IF game where the computer gives you the commands, and you have to answer them as you go, with the aim to make a satisfying game for your artificial player?

I didn't have any idea about a narrative that would be fitting, but I still decided to create a prototype, a sort of proof of concept. It is unfinished, and bug-ridden, but I think it works at conveying the idea. Since I'm unlikely to make something really worth playing out of it anytime soon, here it is as a seed.

You can chose to only use the core idea, or to follow some of the design principles I used for the prototype, or pick the prototype itself and rewrite it properly. I'm quite curious about what people will be able to make of this.

Design principles

I decided to use a storylets system to simulate the player. Each command corresponds to its own storylet, and each turn, a single storylet is picked, the corresponding command is printed, along with a few choices for the human player about what to answer. The storylets properties are used to determine, each turn, what actions are possible and reasonable at that point in the game.

Storylets properties

For the prototype, I used ink, with Calico and an improved storylets patch, which has the following usable properties:

• open:

  a boolean which decides whether a storylet is available at all. It allows you, for instance, to make sure that the TAKE APPLE storylet won't be picked if the apple hasn't been described yet, nor if it is in an unreachable place, nor if it has been picked already.
• exclusivity:

  an integer. When picking the next storylet, only the ones with the higher exclusivity are considered. It can be useful to trigger timed events, or to make sure that when you are on a chair, you can only get down or do certain chair related tasks.
• urgency:

  an integer. Once only the open storylets with the higher exclusivity are chosen, the remaining ones are sorted by urgency. Since we only pick one at a time in our scenario, it kind of behaves like a second layer of exclusivity. The implementation allows for variable urgencies (and exclusivities), which is very practical in this case. I used that mostly to prioritise certain actions over others depending on the last few turns. For instance, each storylet urgency decreases when it has been visited recently, to avoid picking the same over and over, but visiting a storylet can increase the urgency of other, related storylets, to give the impression of an actual reasoning. For instance, if a drawer is mentioned when examining the desk, the urgency of drawer related commands increases if the desk has been examined recently. Similarly, sucessfully unlocking a door should increase the urgency of the open door storylet.
• frequency:

  an integer. I haven't used that one all that much, I sticked to fixed values, to make common, non risky actions a bit more likely than weird, risky ones, all things otherwise equal. It could perhaps be used to create different artificial players personalities, some would favour examining and searching, while others would move or attack more often. If you envision all of your storylets like a deck of cards, while openness and exclusivity determine which cards are in the deck or not, urgency sets which get on top and which stay near the bottom, frequency determines the number of copies of each card there is in the deck.

Handling the state of the world and the artificial player

There are a lot of things to keep track on: where the player-character is, where objects are, what objects does the player know about, are the doors open, closed, locked, are the switches turned on or off, is the player frustrated, does it feels like it made progress, etc. 

Most of the knowledge of what things exist can be handled by the knowledge of which knots/choices/gathers have been visited. Make sure every piece of text where something important is mentioned for the first time is named, and you'll be able to know whether it was visited (and how many times, and how long ago) in the future. Numeric variables can represent things like progress and frustration just fine, they just need to be incremented whenever something relevant happens. Variables can also handle things like remembering in which room the player is. For things that are a little more complicated, such are remembering the state of a door or a switch, I used a list of states, common to all objects that behave similarly and variables set to one of the corresponding list state, they are updated when the state changes.

It is a bit tedious, to handle all these things manually instead of relying on already existing grammar and world model.