WIP Rescue

I get stuck on WIPs moderately often. So do lots of people, I think. What follows is a list of common problems I’ve run into, and some ways in which they can be resolved to get things rolling again.

No guarantee that this will be of any particular use with any particular WIP.

Impossibly hard thing to implement
Problem: an incredibly difficult-to-program thing is taking all your implementation time and preventing you from getting to the rest of the game.

Solution: is this difficult-to-program thing central to your project? If not, bite the bullet and cut it out.

Solution: simplify. Figure out which bits of your complicated simulation/whatever are necessary and which are disposable; stream-line the design until you’re left with something that you can deal with.

Solution: ask for help. Sometimes other programmers will have some advice. If you’re a novice to moderately experienced programmer, this may mean posting a coding-help request to the newsgroup. If you’re a more advanced programmer, it may be less likely that anyone else will know better than you, but talking through the problem you’re having with a friend can often clarify your thinking even so.

Overwhelming content-production tasks
Problem: you have devised a situation that requires you to produce an absolutely insane amount of content: a conversation system in which the player can ask anything he likes, say, or a world model with a lot of elements.

Solution: restrict the player’s access to this system by putting a time limit on the scene. If he only has three turns to spend talking to the palace guard, he won’t have time to poke holes in your implementation. A lot of the time, this will have the secondary benefit of preventing pacing problems that arise when the player spends too long with part of the game that isn’t important.

Solution: restrict the player’s access by reducing his freedom of action. Change the way the conversation works so that he can’t ask about anything (using a menu system or TALK TO instead); don’t allow him to pour a liquid into a container that already contains something; etc. The trick here is to give the player as much freedom as your story and puzzles require, but not so much that you wind up with gratuitous programming tasks.

Solution (advanced): mechanize the implementation. If the problem is that you’ve got (say) a finished conversation system but need to produce 3000 mostly-similar dialogue objects for it, writing out all the code by hand may be more than you can bear. Consider designing your own scripting language or form which you can use to auto-generate the code in your language of choice. This is often possible to do with a relatively small Perl or similar script.

Boring implementation tasks
Problem: you know you have to put in an item, room, etc., but the idea of doing so fills you with ennui.

Solution: cut the item. Seriously: if there’s nothing interesting about a certain object, consider whether you really need it in your game or whether you can excise it and paper over the absence. Often if you find something tedious, your players will too.

Solution: conflate objects. Sometimes it’s possible to take several different items in your game design and replace them with a single, more interesting object that will play roles in several puzzles. It’s possible to overdo this, and obviously you don’t want to hand the player a Swiss Army Knife of Universal Puzzle Solving, but this is one way to spice up generic implementations you’re not looking forward to.

Boring description tasks
Problem: You’ve got to write some room or object descriptions, but the idea of writing them fills you with ennui.

Solution: cut the item. If a room or object bores you, maybe it doesn’t need to be there? Tightening up maps so that they don’t have too many dull rooms is usually a good idea anyway.

Solution: do research. Check out real items or rooms of the type you’re writing about, and pick an unusual one as your inspiration.

Solution: shift the narrative focus to characterization or memory rather than physical description. If there’s nothing very interesting to say about the object or the room, can you instead use the object or room as an excuse for an anecdote, a joke, or some remarks that reveal the player character’s attitude? Or use it as the opportunity to hint at a puzzle solution? Or a way to convey atmosphere?

Solution: change the setting. This is a moderately drastic thing to do midway through a game implementation, but if you find yourself unexcited by most of the rooms in your game, consider whether you could move the story a little — to a new part of the world, to a new time period — so that you wind up with an atmosphere or geography you find more exciting.

Solution: get a collaborator. If you really hate writing and you have trouble generating any of the prose at all for your opus, that may mean you should team up with someone else.

Overly detailed sequence draws attention from the rest of the game
Problem: an incredibly difficult-to-program scene, richly-detailed object, or brilliantly hard puzzle is taking all your player’s attention and preventing him from caring about the rest of the game. (Often this doesn’t show up until beta-testing, where it manifests itself as your player obsessing about some piece of the game and perhaps never actually playing through to the finish of the work.)

Solution: is this set-piece central to your story, or is it just throwing the pacing off? If the latter, bite the bullet and cut it out. If there’s something awesome about the implementation but it’s just not to scale with the rest of the project, save the code for another project in which it might be more at home, like a game for the one-room-game competition or the IF art show.

Solution (less drastic): simplify the set-piece and provide more direction to the player. Make it really clear what the player’s interaction goals are (solving a particular puzzle, bringing about a particular narrative outcome) so that he is less likely to get mired in playing with it.

Solution (more drastic): raise the implementation level of everything else in the game until it matches the level of the problematic section. This is something to consider only if you think the set-piece is the best thing about your game and exemplifies the kind of interaction you wish existed throughout. It’s likely to make both the game and the project take quite a lot longer to complete. On the other hand, games with deep, involving implementation from start to finish are welcome things. If motivation should flag, try “Sunset Over Savannah”, “Worlds Apart”, or some of zarf’s games to remind yourself how much fun this can be to play.

Overly linear sequence makes part of the game feel slack
The problem: you’re faced with a stretch of game where the player can’t do anything interesting for a while. A whole sequence involves the player character doing something quite tedious and mechanical, such as following a recipe, packing a suitcase, or checking into a plane flight.

Solution: jump ahead to later in the narrative. Anything that’s going to be boring for the player to play through and boring for you to program probably deserves to be omitted. The jump technique is used to good effect between locations in lots of games; it’s a little less obvious that we can use it to jump ahead in time even when there isn’t otherwise a change in scene. But see, for instance, “Gourmet”.

Solution: change the interaction focus. Foreground conversation or other exciting interaction; background and automate the boring task. Instead of having the player type “ATTACK VILLAIN” five times for a sword-fight, let him throw out witty repartee, and describe the sword fight as going on semi-automatically interleaved with his remarks. This is a little bit daring, in that it takes some control from the player and makes things happen without his direct instruction, but it’s often a lot more fun than the alternative.

Narrative takes too long to get rolling
The problem: the opening of the game is rather tedious; nothing much happens until the player has wandered around a lot, and/or the player’s goal is not sufficiently obvious.

Solution: give the player an obvious starting problem, even if it’s not the main goal of the game. This can mean adding a short prologue scene to what you already have. This prologue should have a very clearly articulated goal and should also help set up the player’s character and long-term motivation, so that once it’s over, the player has a bit more momentum to take into the slower-paced mid-section of the game.

Solution: start the player off with a project already in action: in the middle of a conversation, say, or during a sword-fight, or half-way through rebuilding his Ferrari.

Game is too hard to make progress in, especially at the beginning
The problem: the first puzzle in the game is way too hard. (See “Christminster”, otherwise pretty well-balanced.) It’s important to let the player make some progress at the very beginning of the game, because otherwise he’s likely to give up; if he gets stuck later on, he has more motivation to keep playing, because he’s made a time investment.

Solution: simplify the first puzzle or two. But I assume you thought of that.

Solution: add a prologue section with an easier puzzle, ideally something that gives the player a bit of experience that he can draw on to solve what’s coming up.

Cut-scene or major event lacks impact
The problem: an event that is supposed to be narratively important feels too lightweight in play and doesn’t make enough of an impression on the player. This is particularly common when something important and game-changing happens in a cut-scene.

Solution: lengthen the scene to take place over more turns. Making the scene interactive — even for just a couple of turns — can dramatically change the feel of the event.

Solution: insert pauses into the cut-scene where the player has to press a key to continue. This is kind of a least-effort thing, and it doesn’t necessarily buy you much, but it can lend a little sense of importance to a cut. Multimedia effects can also sometimes help out here: if you’re writing a game with illustrations, it adds a sense of occasion if you put the illustrations in at important moments rather than inserting them arbitrarily. “Bolivia by Night” does a pretty good job with this.

Solution: redraft the scene; it may be your writing that’s the problem. Consider checking out some guides to writing static fiction, if you don’t have much experience in this department. They may shed some light on what is missing from your dialogue or characterization. An especially common problem among novice IF authors is the tendency to write vague or underspecific scenes, and to summarize dialogue that would be better written out.

Solution: raise the stakes by adding or changing material leading up to the big moment. Give the player character more motivation to care about what happens; or, give the player more motivation to care about what happens, by having him work toward a goal that the big moment threatens, changes, or undermines.

Uninteractive sequence prevents the player from doing anything but watch
The problem: for some parts of the narrative, the player character really has nothing at all important to do: maybe two non-player characters are having a conversation that the player needs to witness but not participate in. You’re stuck implementing what’s essentially a movie, only the player has to type Z over and over to make this go forward; or, the player has something to do during the scene but it is basically a time-waster while the major characters go about more interesting business which he is compelled to stay and watch.

Solution: trim the scene. Scenes where the player does nothing are less painful if they’re short. This does, admittedly, go directly against my advice about lengthening scenes that don’t have enough impact. But the key here is that you raise the player’s involvement if you give him something real to do for several scenes of an event; if you just give him busy-work, it doesn’t count for as much.

Solution: provide a B-plot to the scene. Is there something legitimately interesting that the player needs to do that could happen simultaneously with the main plot of the scene? Then put the two scenes together. Have the player work on the thing he needs to be doing while the non-player characters do their thing at the same time. This often takes a little ingenuity to design so that both the A plot (the non-interactive non-player-character behavior) and the B plot (the player’s task) are explained clearly, don’t get in each other’s way, and take roughly the same amount of time. Still, this can be a powerful effect if done well. (See “Delusions”.) A common variation: design the scene so that the player’s B-plot behavior interrupts or provides a finale for the A-plot, as when the player finally bursts out of his jail cell or uncovers the hidden treasure and thereby distracts the non-player characters from what they were talking about.

Solution: change the viewpoint character. There’s no reason that the player has to play the same protagonist throughout the game. Sometimes it’s more interesting to have him switch roles. This may be true even if the other character is someone whose goals are at odds with your first protagonist’s: playing alternative characters may shed some light on the motivation and world-view of the villains, for instance. (Consider “Being Andrew Plotkin”.) This technique may be jarring if it’s introduced only late in the game and only for a single scene, though, so be careful about pacing.