Writing a nonlinear interactive story is a lot of work. Making it realistic is even more work.
I’ve started working on a story (using Inform 6) whose plot splits neatly into two parts. The first part is basically puzzle-free — but it’s not devoid of relevant events. At least two, and possibly as many as four, things need to happen in the first part of the story in order to set up the second part properly. And yes, there will be some puzzles in the second part.
The simplest way to structure a narrative in which several events need to take place is to make it linear. Set up some “gatekeeper” functionality of some sort that will prevent event B from happening until after event A is safely out of the way, delay event C until event B is finished, and so on. But the gatekeeper functions can seem rather contrived and artificial. Besides, if you structure it that way the story isn’t quite interactive. It’s on rails. The rails may be somewhat wide-gauge and wobbly, but they’re still there.
In a truly nonlinear interactive story, the author may prefer to let the significant events happen in various orders — A-B-C, or C-A-B, or B-A-C, and so on. But if the story involves realistic characters (and we hope it does), they may react or behave differently during event B if A has already happened than they would if A hasn’t already happened. So the code for each event needs to be structured in such a way that various texts can be printed out depending on the state of the story as a whole.
With two significant events, this isn’t too difficult. We need two paths through event A: In one path, B has already happened; in the other path B hasn’t yet happened. And the same for event B — event A may or may not have happened. So that’s four different vectors, total, through the events. The differences may be minor, or they may be large, but in no case is the author absolved of the responsibility of figuring out what the differences are.
Now add a third event. While coding event A, we may need to know whether B has happened but not C, whether C has happened but not B, whether both B and C have happened, or whether neither has happened. (For purposes of discussion we’ll ignore the possibility that if both B and C have happened, it may matter what order they happened in.) We now have four possible vectors through each of three events, or 12 event vectors to consider in all.
Add a fourth event, and the number of event vectors that have to be evaluated rises to 32. Some of them may require no special coding, or only a single if-test here or there. Other combinations will lead to more far-reaching variations.
Mathematicians call this the combinatorial explosion. Every time you add a single event to the story, the number of possible combinations more than doubles.
And we’re not done yet. Any of these events may (or may not) have an effect on any of the conversation topics in the game. If you start with five characters and 20 possible conversation topics, that’s 100 conversations to begin with. How many of them may need fine-tuning based on whether or not any particular event has happened?
Those are not the only factors affecting conversations, either. How many conversation responses may need to change based on which other characters are in the room and can overhear the conversation? Might there be variations in some of the conversations based not on what events have happened, but on whether a given character knows that a given event has happened? Tracking NPC knowledge is a piece of cake, basically. It’s just a matter of setting up a few flags and then remembering to set them when an event takes place. But figuring out what a given bit of knowledge may mean in terms of how a conversation unfolds — that’s not quite so simple.
I’m not complaining. This is actually kind of an interesting challenge. I’m just thinking out loud. If nothing else, this line of thought suggests why writing IF is a specialized endeavor. It’s writing, it’s programming … and it’s also fitting together a jigsaw puzzle. Juggling while riding a unicycle while reciting the Gettysburg Address.