[IF] Design and time management
A lesson about writing IF
I have started work on my second piece of Interactive Fiction, Fate, and development is going a lot faster then when I wrote The Baron. There are several reasons for this. First, I am using Inform 7, which is definitely easier and faster to use than Inform 6. Second, I am more experienced, and thus have to learn less about programming IF - although this benefit is partly negated by having to learn Inform 7. Third, I am writing in English only, and am thus sparing myself the struggles with the Dutch library as well as the final step of translation. But, although all these factors do play a role, I think the most important reason is something else, a hard-learned lesson of time management:
The time it is worth to spend implementing a feature is inversely proportional to the chance of a player stumbling upon it.
When you are writing a game, you will invariably think of strange things the player might try, and you may have brilliant ideas about what could happen when does. If implementing those ideas would cost you a lot of time, resist the temptation.
Baronic examples
Let me give you an example from The Baron, although I could give you countless examples from that work. These paragraphs will contain spoilers, but nothing to serious. There is a room, a torture chamber, which you can only find if you push aside some stones in the castle. You don't have to do this in order to finish the game, and many players probably won't.
The conclusion I should have drawn is that if I wanted to implement this torture chamber at all, I should do it quickly. Maybe just a description and one or two objects.
Instead, I created what is perhaps the most complex room in the entire game. Not only are there many objects with non-standard behaviours, I even implemented two further sequences which are very interesting, but also very, very unlikely to grace the screen of the player. One of these only starts when you have entered the cell, locked it, and threw the key away through the bars. (This is also the only moment in the game in which you can seemingly put it in an unwinnable state - but not so.) The other only starts when you enter the torture chamber, close the hatch behind you, are not carrying a light source, and type 'listen'. Depending on the state of the torture chamber, you'll hear different things - all of which are directly related to the theme of the piece, but none of which will ever be found.
Implementing this last sequence alone probably cost me about a day. I won't be surprised if no player has ever found it. Therefore, it was not worth the trouble.
What will the player find?
Understand this: the player will not play your game nearly as thoroughly as you do, or even as your testers do.
That doesn't mean that players will find bugs you didn't notice, for they surely will, and these bugs should be fixed - but it does mean that players will not in general search every nook and cranny of the game, nor try all kinds of strange actions, unless you give them a clear reason to. In The Baron, you can't get stuck, so there is little incentive for trying out all kinds of strange things; therefore, most people won't. There are seven ways of ending the first scene, but why would a player look for them? They won't. They'll stumble upon one of the more straightforward ones, and never notice all the work that went into the other ones. (Like running back to the iron doors and knocking on them once you are afire - the most interesting way to end the first scene, but hardly likely to be found.)
Remember that, and you may save yourself a lot of time.
I have started work on my second piece of Interactive Fiction, Fate, and development is going a lot faster then when I wrote The Baron. There are several reasons for this. First, I am using Inform 7, which is definitely easier and faster to use than Inform 6. Second, I am more experienced, and thus have to learn less about programming IF - although this benefit is partly negated by having to learn Inform 7. Third, I am writing in English only, and am thus sparing myself the struggles with the Dutch library as well as the final step of translation. But, although all these factors do play a role, I think the most important reason is something else, a hard-learned lesson of time management:
The time it is worth to spend implementing a feature is inversely proportional to the chance of a player stumbling upon it.
When you are writing a game, you will invariably think of strange things the player might try, and you may have brilliant ideas about what could happen when does. If implementing those ideas would cost you a lot of time, resist the temptation.
Baronic examples
Let me give you an example from The Baron, although I could give you countless examples from that work. These paragraphs will contain spoilers, but nothing to serious. There is a room, a torture chamber, which you can only find if you push aside some stones in the castle. You don't have to do this in order to finish the game, and many players probably won't.
The conclusion I should have drawn is that if I wanted to implement this torture chamber at all, I should do it quickly. Maybe just a description and one or two objects.
Instead, I created what is perhaps the most complex room in the entire game. Not only are there many objects with non-standard behaviours, I even implemented two further sequences which are very interesting, but also very, very unlikely to grace the screen of the player. One of these only starts when you have entered the cell, locked it, and threw the key away through the bars. (This is also the only moment in the game in which you can seemingly put it in an unwinnable state - but not so.) The other only starts when you enter the torture chamber, close the hatch behind you, are not carrying a light source, and type 'listen'. Depending on the state of the torture chamber, you'll hear different things - all of which are directly related to the theme of the piece, but none of which will ever be found.
Implementing this last sequence alone probably cost me about a day. I won't be surprised if no player has ever found it. Therefore, it was not worth the trouble.
What will the player find?
Understand this: the player will not play your game nearly as thoroughly as you do, or even as your testers do.
That doesn't mean that players will find bugs you didn't notice, for they surely will, and these bugs should be fixed - but it does mean that players will not in general search every nook and cranny of the game, nor try all kinds of strange actions, unless you give them a clear reason to. In The Baron, you can't get stuck, so there is little incentive for trying out all kinds of strange things; therefore, most people won't. There are seven ways of ending the first scene, but why would a player look for them? They won't. They'll stumble upon one of the more straightforward ones, and never notice all the work that went into the other ones. (Like running back to the iron doors and knocking on them once you are afire - the most interesting way to end the first scene, but hardly likely to be found.)
Remember that, and you may save yourself a lot of time.
I disagree with this somewhat. These more unusual things, if you have made the effort to the player that you have implemented such things, will be tried eventually.
ReplyDeleteThere is a particular pleasure in typing something to find out that not only does it work, but it works smoothly. This sort of attention to detail is wonderful and the sign of a master craftsman. Nethack is one of my favourite non-IF games because of this. If you can think of a strategy, it will work, because 'the dev team thinks of everything'.
Besides, there is one way to make sure that such things get found in the end, which is to put them in a hint file or an 'after the game' file. Perhaps more useful in a game-y game than a more serious work of art, but few artists can resist a small personal touch in an unnoticed corner...