How to code Aisle/single-turn game with multiple endings

I’m wanting to create a single-turn game with multiple endings in the style of Aisle. How would I go about creating that system in I7, with the small “end story” text and all.

Any help at all would be appreciated.

1 Like

Hi! I think there are probably two main ways to do this, and which you want to use depends on how you’re planning on constructing the story.

The first would be to just have an every turn rule that ends the story each turn, with varying text depending on the results of the player’s actions. So something like this (note that this won’t compile since I’m referencing some unimplemented conditions by way of example):

Every turn:
	Say "Whew, that was intense!  You're happy you wound up with [romantic partner of the player], though!";
	If the lime is in the coconut, say "And you got the lime in the coconut!";
	End the story finally saying "Congratulatory text goes here".

The other approach would be to write rules ending the story after every action the player can take:

After jumping:
	Say "Hop!";
	End the story finally saying "At least you went out jumping."
After examining the bureau:
	Say "It actually looks more like a dresser.";
	End the story finally saying "How bureau-cratic!"

The first option will probably require you to juggle a bunch of different conditions, and might make it a little more complicated to get exactly the response text you want. The second would be easier on that front, but probably would wind up more laborious if you want to make sure nothing slips through the cracks (though of course you could write broader rules, like “after taking something”, or even “after doing anything other than jumping or examining or attacking…” as a sort of catch-all).

Hope this is helpful!

Oh, and this bit of the recipe book might be worth perusing.


This is going to be a lot of work however you do it. Partly, it depends on what you mean, exactly, by “in the style of Aisle.” It’s also going to depend on how many of the endings you want to have their own ending text.

Essentially, you’re going to have to re-write every response the parser gives by default to any action for any object so that you use one of the end the story phrases described in Writing With Inform 9.4. You’ll also have to use that phrase in any action-handling code you write for each object.

Here’s a sample to give you the basic idea:

City Park is a room. "There is a swing set and a bench here. The grass is green."

The swing set is in City Park. Understand "swingset" as the swing set.
Instead of examining swing set:
    say "Two swings, too small for your adult body to fit into, hang by chains from a metal frame.";
    end the story saying "You have examined the swing set.".

The bench is an enterable supporter in City Park.
Instead of examining the bench:
    say "It's made of wrought iron and painted an ugly green.";
    end the story saying "You have discovered that the bench is painted green.".

Instead of entering the bench:
    say "You sit down on the comfortable bench.";
    end the story saying "You have sat on the comfortable bench.".

You might find *Writing with InformI 14.10, “Responses,” to be a good place to start looking for information about what the default responses cover.

The good news is that you won’t need to worry too much about world modeling, because a game that always ends after one term doesn’t need to worry about the world state changing between turns, which is why I just went ahead and used instead rules everywhere above.

You may also want to use an every turn rule to catch any oddball actions that you’ve forgotten. every turn rules run at the end of the action sequence, so anything you have redefined should happen first unless you’re doing something else weird and unusual:

Every turn:
    end the story saying "And that's what you did in the park that day before the gas line exploded.".

I’d be leery of trying to use an every turn rule on its own unless you want to give the player the same ending message no matter what s/he does, though.

EDIT. Mike ninja’ed in ahead of me.

Also, meant to say: part of keeping the workload manageable is probably going to involve designing a sparse world in the design process.