Choice of choices

Since I'm programming a choice-creating / CYOA extension for Inform 7, I have not been able to help but notice the large number of other choicey tools that are either out there already, or that people are making or releasing right now. For authors, this means they have a growing choice of choices. For me, I know it motivates me to some kind of competitive freshness in my own extension.

This particular post isn't an exhaustive list of choice engines. I'm not doing any research here or being super-helpful. I'm just typing in what I'm aware of to show which ones are on my mind:

– Twine
– ChoiceScript
– inklewriter from inkle
– Ink from inkle
– Undum
– Raconteur, a spinoff of Undum which creator Bruno Dias describes as 'Undum with batteries included'
– Salet, a spinoff of Raconteur which is a spinoff of Undum, of which creator Oreolek says: 'It’s actually Undum refactored and rewritten in CoffeeScript with some bits of Raconteur sprinkled in.'

(Homer Simpson: "I just hope we put in enough steampunk, whatever that is.")

To demonstrate the value of competitive motivation, I'll tell you the story of Oreolek's promotional post about Salet. There was one line which said just you wait until I finish the inventory management (those words were italicised in the post).

My first reaction was, 'Oh geez, I haven't programmed my own deeper inventory management system yet.' And my second was, 'Oh yeah? Well how about YOU wait until I finish MY inventory management system?!'

I don't know if the second reaction was a question, or a challenge yelled at people not even listening to me or in the room at the time or who should even have to tolerate such nonsense, so to cover both contingencies I have put both a ? and ! at the end of it.

I then ran off and created an inventory management demo and game for my extension. To make it interesting for myself, I included a glass basket, a transparent container. Then I had an infinite recursion problem –

'The apple (in the glass basket (containing an apple (in the glass basket (containing an apple)...'

– and then I got rid of the infinite recursion problem.

I'm continuing to develop examples and mini-games for my extension. This is turning out to be quite fun, and makes me wonder why I don't place the idea of deeper implementation on a bonfire and just make more games like these ones. I suppose it's because of the split between the things I enjoy playing versus what I would like to make myself. I have enjoyed a huge range of IF, but if I mobilise to make one, I feel like I want to go to a lot of trouble in certain directions. The extension examples are excused for their simplicity, in my own mind, by being examples.

Here is some source from a simple moment in one of the games:

A node rule (this is the bridge-crossing rule):
if cyoa-node stage is prose:
print "The bridge creaks as you place your foot on it. The whole length of it wavers, all the way out over the abyss.[paragraph break]Do you feel brave enough to continue?[paragraph break]";
if cyoa-node stage is choices:
link 1 to "No";
link 1 to "Maybe";
link 2 to "Yes";
if cyoa-node stage is react:
if cyoa-choice is 1:
say "Then you'd best not until you feel bolder. The faint of heart are likely to fall.";
switch to the parser;
if cyoa-choice is 2:
say "You place your other foot on the bridge. The structure is so long and mist-clouded that you can't see the far end. There'll be no escape if it collapses. All you can do is proceed carefully. ";
create a continue moment;
say ".[line break].[line break].[line break]";
switch to the parser in room Over the bridge;

Like at least two similar examples people have pasted from similar choice tools lately, it's pretty clear what this one does and easy to follow even if you don't consider yourself a programmer. It comes from an example demonstrating how to stud a parser game with CYOA moments and conversation.