One of the things I find useful in developing a very plot-oriented piece of IF is to leverage the scenes mechanism as much as possible, designing as follows. I’m not sure this really qualifies as advice so much as some personal experience that may or may not suit others’ writing styles — people tend to approach IF design in different ways. Still, FWIW:
— Start by listing all the scenes I expect to feature in the game. If the game is too branching for a straight list, then make a flowchart instead — but know from the beginning what I think all the elements are going to be. The scene list will change and will be revised, but having something to shoot for makes it easier to motivate myself, track progress, and avoid that moment where I realize I don’t really know how to do the next bit. Besides, if there’s some part of the game plot that is a little fuzzy in my mind, that often means that there’s a problem with it that I just haven’t faced squarely yet. It’s better to deal with that at the beginning than to try to patch and compensate later.
— Create a heading for each scene; that way, viewing the contents pane will give an overview of the plot of the game, too. In comments, write up a short description of what I expect each scene to do. (Does the player have to accomplish something? Learn something? Observe a series of events? Make a choice?)
— In a separate portion of the code (usually at the beginning of the program), make headings for the settings the game has to use. The idea here is that the game is being designed like a staged play: the action may move on and off the sets at different times. I may not actually create all the settings at once.
— As I go along, write each scene to contain complete set-up and take-down information in the “when (the scene) begins…” and “when (the scene) ends…” rules. At the beginning of a scene, I move in everything that the scene needs — any prop objects, any characters that need to be in that scene. At the end of a scene, I take it all away again. I don’t expect elements of a set to stay from the previous scene. I have one phrase that moves all the non-permanent objects out of play, and I call it whenever I need to strip the sets.
This might sound a little laborious, but it helps protect against bugs if, later on, I decide to change the sequence of scenes or add a plot branch.
— Create the sets the first time each one is needed, but be mindful also of the later scenes where the same set is going to need to be used. I don’t write them all in a big clump in advance for a couple of reasons: I get bored if I spend too many hours working just on scenery with no action. Besides, the elements that need to be on the stage are often obvious only when I’ve started the scene (a vase for the NPC to smash, a fireplace for the player to burn a letter, etc). At the same time, remembering the later scenes that will use the same set helps me be sensible about writing descriptions (or remembering that the description of something may have to be conditional, to fit multiple points in the plot).
— To test sets and kick the tires properly, turn off all scenes (by making sure that the first one never starts — just comment out the ‘when play begins’ bit, if appropriate). Spend some time in the location and play around with things while there’s nothing distracting going on. Sometimes playtesting a set while a scene is going on means that objects on the set change or the scene ends before I’ve gotten a chance to give things a serious try.
— To work on scenes late in the game, and for testing purposes in general, again comment out the beginning of the first scene and instead have the game begin with the scene I’m interested in. (“Dramatic Climax begins when play begins.”)
— Develop a testing script to make sure that certain commands give sensible output in every single scene. That might include
LOOK — does the room description really fit this particular scene? Does it draw attention to the right things? Does it reflect the protagonist’s state of mind at this moment in the plot?
EXAMINE ME — does the character description sound right for what is going on right now?
WAIT, LISTEN, etc., and perhaps other commands that ought to be very reactive to change in the plot sequence, depending on
Go systematically through every scene in the game and run the test script. Revise any output that is unsatisfactory.
====
One of my remaining frustrations is that it’s not currently possible to write rules such as
When a movie-like scene begins: …
because the rulebooks for scene beginnings and endings are created specially for each scene; they don’t take variables. That’s something Graham and I have discussed a number of times, and there are some technical reasons (which may or may not prove binding) why it hasn’t changed yet. We’ll see what happens there.
Emily Short's Interactive Storytelling 
Plot in IF is one of the hardest things to code (second only to conversation)… Especially when you’re trying not to make it seem too linear.
It’s so hard to have a strong multiple choice plot, because the player is always going to come up with another idea the writer hadn’t thought of, and if you have to many branches it’s sometimes hard to keep it from stretching too thin.
Sometimes I wonder why I don’t just write a puzzle game and be done with it… But the storywriter in me refuses to give up.
It’s so hard to have a strong multiple choice plot, because the player is always going to come up with another idea the writer hadn’t thought of
Despite my various gripes about Chris Crawford’s book on interactive storytelling, I think this is an issue he gets right: you don’t have to give the player every imaginable choice. In fact, you shouldn’t. You should offer only the choices that are interesting and relevant to the story you’re telling. If you’re coming at this from the storytelling perspective, what is the conflict that you’re exploring? What choices can the player make that would reveal something interesting about that conflict?
Hmm, interesting. This is exactly the way I — well, this is complicated. I have been reaching towards finding a new way of going about writing IF, and the stageplay (with attendant stage manager, whisking sets and actors on and off, etc) metaphor is definitely where I ended up. It just made a solid sort of sense for writing a certain type of game. In a very crude way, this is how BAP worked internally. Again not surprising, since that game was both like a movie (structurally) and like a play, with one location set being reused for scene after scene.
I still haven’t started using I7, but my other meta-developmental investigations have definitely made the scene writing tools in the language highly desirable. It’s just simply how I’m thinking about the act of designing and writing IF these days.
[…you don’t have to give the player every imaginable choice. In fact, you shouldn’t. You should offer only the choices that are interesting and relevant to the story you’re telling…]
Hm, yes, true. What I’m trying to say is that plot heavy IF is almost always linear, and if it isn’t linear, and you still want a story… I mean, you have so many different elements coming into the equation. Suddenly you’re juggling all these different possibilities, and you’re also trying to keep a coherent and interesting story, while the player stretches the limits of your story.
I don’t know, maybe I’m just wingeing, or too ambitious with my stories, but if I try to think about the choices the player can make in situation x, which thus brings them to situation y or situation z, and the different choices from each of those scenarios etc etc, my head implodes.
I’m not bagging linear IF here, being a writer myself, I think that If is a brilliant way to tell a story. The fact that the player is actually involved in the plot, and that their actions keep the story rolling, keeps their interest in what happens next. IF could, quite conceivably, become the next means of novel writing. Although no-one seems to have tried to write a novel with it yet, short stories abound (photopia leaps immediately to mind).
Part of what I am getting at is that you don’t have to give the player all the options that situation X might present in real life. You also don’t have to make every choice instantly branch the plot.
Some examples: in Fate, the player choices are all about the question of how far the protagonist is willing to go to protect her child. One can imagine the plot having other choices that weren’t about that question, but by focusing the protagonist’s action in a single area, Victor wound up with a plot that felt coherent and was a reasonable size.
Similarly, sometimes a choice doesn’t change what happens next In the plot; instead it affects (say) which alliances the player will have at his disposal come the endgame. City of Secrets does a bit of that.
So I guess what I mean here is that your plot can be a bit linear if what you mean by that is following a set major arc, but at the same time offer the player a fair amount of agency and ability to affect the ultimate outcome. But to do this, you can’t approach the problem as an attempt to write all the possible branches available to a character in your initial situation. Instead you ask yourself, what is this game/story about? What are the difficult decisions faced by the main character(s)? How am I going to dramatize the important choices? How do I lay the ground for them with smaller decisions? Are there some parts of the story that I can present not as major crises but as small choices contributing cumulatively to a characterization?
That may still seem fairly abstract. An example from one of my projects: the major choices at the end of the story are where big branching can occur, but the decisions there are given weight by the relationships set up over the early part of the story. So many early scenes can go different directions, but they don’t actually split the plotline; they just set conditions for later about which characters are loyal to one another. Sometimes there are brief optional scenes tucked into the main plot, usually to make it clear when the player’s actions have resulted in a major change to one of the key relationships. But the real branches come late, and when they do they have the weight of a lot of smaller easier choices behind them.
Yeah, true. Thanks for the tips… I shall definitely incorporate those into my latest IF attempt.
I had a look at your Bronze source code and the making of, and the chart was certainly interesting.
I must remember not to be so melodramatic!
Probably the Tasmanian in me…
Hi,
the issue you talked about scenes it is one of the most important one on them, but not the only. The scene mechanisms could be really interesting, really useful, but with the actual implementation they results too limited, and finally many times i find better ignore and recreate them.
** i press the submit by mistake… i will continue here… **
In our ‘Museo de las Consciencias’, we do a strange use of scenes that you can see in its source. I have tried to use ‘scenes’ in each i-f i write in I7 and finally i had erased them from the source all the times, and used an alternative adhoc mechanism. For instance, you can see the strange result in my last i-f ‘Pronto’.
More flexible scenes could be really really great tools in the future.
If you could be specific about the other issues you’ve run into, and what you’d like Inform to do, that would help — either here, or by emailing Graham. The more detail you can give about (a) what new syntax/behavior you would like and (b) why that would help with your games, the more likely it is that your request will be dealt with soon. (Vague requests mean that we have to spend some time talking about what we think you’re asking for, and coming up with specs, getting back to you to discuss them, etc.; this takes longer and we often put off those requests until after the more precise ones have been dealt with.)
Maybe it is only me, but what makes I7 scenes so frustrating to me is that I cannot start or stop them manually. There must be a design philosophy behind this (though I wonder what it is), but all the actual implementation does is force me to write stuff like this:
The scene_1_changer is a truth state that varies. The scene_1_changer is false. Scene 1 ends when scene_1_changer is true.
And then I can write:
now scene_1_changer is true
when I would have much preferred to simply write:
now scene 1 ends.
Yes! I think you could fake this up with an extension containing some sort of scene manager object and some new I7 grammar, but I too have been frustrated by this exact same thing.
Maybe it is only me, but what makes I7 scenes so frustrating to me is that I cannot start or stop them manually.
There is a design philosophy behind it; it’s even explained in its own section in the manual, because this is something that people have brought up a fair amount. One might argue that the frequency of mentions means that the policy ought to be rethought; but Graham seems reasonably certain on this one.
And, I have to say, I am coming around to seeing his point of view on it. I’ve dealt with a lot of user frustration on this topic, but I’ve also written some big scene-based things, and on consideration of those, I can see what he’s worried about. Specifically, having the scene setup work the way it does guarantees that
a) because scenes can only change at certain points in a turn, it is impossible to develop certain kinds of bugs and clashes that would otherwise arise (say, if an action terminates a scene partway through the action being processed, resulting in report rules not firing as expected — but that’s only one of the possible faults);
b) it remains possible to build the scene index, indicating what events follow from which others.
HOWEVER, as of the next build, it will be possible to give a scene properties (such as “Foo is completed”). That’s only half-way to being what you want, because you still have to type “Foo ends when Foo is completed.” for each scene to which it applies. But at least it’s a bit more universal and less hackish than having a separate global flag for each case.
Concerning (a), I’m almost sure that is false. Isn’t it the case that I can call
consider the scene changing rules;
from wherever I like, whenever I like? This surely makes it possible to get all the bugs you mention.
And the point is of course not just that this is possible, but that people are likely to write this, because you cannot do everything you’d want to do with scenes without calling the scene changing rules at arbitrary times. If I have a menu-based conversation (all of which takes place in a single turn), and if I want different choices within that conversation to start different scenes (say, “Joe walks away” and “Joe embraces you”), and I want the next bunch of conversation options within the same conversation to depend on which scene is running, then I have to run the scene changing rules manually. And yet this seems to be a perfectly sensible thing to want to do with scenes.
If I have a menu-based conversation (all of which takes place in a single turn),
Erm, I flinch at this. As a player, I hate having a menu-based conversation that elapses within a single turn, because it means that undo takes back the whole thing at once, and because it tends to feel constrictive and inelegant. I can’t do other actions during the conversation, which makes the conversation feel more modal, which I also dislike.
That said: okay, yes, it is true that one can trigger the scene changing rules at times of one’s own choosing. Perhaps what I should have said is that it unlikely that the default implementation will produce such bugs.
I don’t feel expert enough in I7 (or english language itself). So, i don’t feel comfortable with the idea of asking a particular sintax change, sorry.
I feel the general idea to improve the scene is that they should be like any other ‘kind’ in the game: they should be organized in hierarchies, they should be used in general conditions like you said in the original article, they should be used inside table rows (in I7 i feel the table mechanism is the greatest part, i use to create very general pieces of code and put the instances in the tables, nowadays i cannot use that kind of approach with scenes), use them as attribute (so you can create a ‘kind’ of object that ‘appears’ in particular scenes with a code similar to that one:
The little net is a scene related item. The related scene of little net is Running Through the Frozen Hell.
The strange floating ball is a scene related item. The related scene of strange floating ball is Running Through the Frozen Hell.
****
Definition: a item related scene is…
When a item related scene begin:
repeat through…
move item to the location;
***
or the equivalent table approach) ,etc…
Sorry not to answer sooner — the last week has been very busy.
All good suggestions. Some are being handled already — for instance, in the build soon to be released, you can do this:
Running Through Frozen Hell is a scene.
A scene-related item is a kind of thing. A scene-related item has a scene called the related scene.
The little net is a scene-related item. The related scene of little net is Running Through Frozen Hell.
The strange floating ball is a scene-related item. The related scene of strange floating ball is Running Through Frozen Hell.
Foo is a room.
When Running Through Frozen Hell begins:
repeat with prop running through scene-related items:
if the related scene of the prop is Running Through Frozen Hell:
move the prop to the location.
Running Through Frozen Hell begins when the turn count is greater than 2.
Test me with “look / z / z / look”.
And you can also put scenes in tables, so:
Foo is a room.
Wonkiness is a scene. Wonkiness begins when the turn count is greater than 2.
Table of Scene Things
chosen scene atmosphere
wonkiness “A loud whistle blows.”
Every turn:
repeat through the Table of Scene Things:
if the chosen scene entry is happening:
say “[atmosphere entry][paragraph break]”.
So what’s missing here is the ability to make generic rules about what happens whenever any scene starts, or whenever a specific kind of scene starts — if you had that, you could create your automatic set-dressing rule.
In general, what you’re arguing for boils down to scenes being represented by things rather than as values. If they were things, they could be put into kinds, and it would also be easier to write rules concerning them. I’ve been arguing with Graham about this since, oh, 2005 or so; he remains pretty staunchly of the opinion that the memory overhead of creating so many more objects would be problematic, among other things. But we’ve also been discussing whether there might be a way to get scenes to work in a broader spectrum of rules.