On a previous post, we’ve been discussing what makes a game feel like work to play, and what doesn’t — and a lot of the answers come back to matters of polish. Is the game bug-free, or close to it? Are puzzles well clued? Are there responses to lots of unexpected commands? Are boring, repetitive actions omitted? Is the space easy enough to understand that the player doesn’t need to map? Does the game help track important clues for the player, so he doesn’t have to take notes?
People keep recommending beta-testing as a way to find and correct such flaws. This is good advice, but it misses a point I think is just as essential:
Play it yourself.
Play your game while you’re writing it. Play it a lot. Play it over and over. Every time you start work on your game again, begin your work session by replaying. You’re coming in fresh, since you haven’t just been writing code; you’re more likely to bring a player’s perceptions to your game, rather than an author’s. Try to forget about what you know you coded, and just play your own game as though it were by someone else.
Are there commands you get sick of typing out? Create shortcuts. A description that gets boring after a few plays? Rewrite it. Odd commands that come into your head to try just because you have already seen this scene a million times? Put them in.
This may seem artificial, but sometimes I even write up a list of design flaws I experienced, just as though I were creating a beta test report for someone else.
Of course, this is easier advice to give about a short game than about a long one. If your work is a ten-hour epic, you’re not going to be able to play the whole thing though and still have time to get any coding done in that session. Which is where my second piece of advice comes in: if you have a long game, create jump-in points so that you can start the game partway through and replay just the scene or section that you’re currently focused on.
This is reasonably do-able with Inform 7. One approach I’ve taken with my more narrative WIPs:
- structure the entire plot as a series of scenes
- make sure that each scene sets up the essentials I need to play through (moving characters into play, etc.)
- to test a new scene, comment out the real scene-starting condition and make that scene start when play begins. (And also comment out the scene that normally starts when play begins.)
A related piece of advice:
The prologue text you wrote when you started the game is almost certainly not the prologue text you want to ship with. I often encourage my students to write the main body of an essay first, and do the introduction and conclusion last. (If they feel uncomfortable starting with the body, they can write a filler introduction — but it should be replaced after they’ve written the main argument.) Roughly the same principle applies to IF: even the most specific idea tends to develop as you write your game, and you may find that the starting text no longer gives a good sense of the game’s theme or major goals — so fix it. Many players see the opening of a game as the author’s contract with the player: you’re supposed to communicate what the game is going to be like, so they can decide whether they want to go on or not. There are occasionally times when this contract can legitimately be broken, but most of the time players will be annoyed or disappointed if you do, even if they would otherwise have liked the work.
This is especially true if you wind up down-sizing your idea somehow. You set out to write an epic, get through the first three episodes out of a projected 27, realize that the whole thing is never going to get done and that you want some feedback on what you have done, and re-structure the piece into a comp-sized entry. Great — but it’s best to make sure that your introduction now fits the revised ambitions of the work.
These two qualities — a high degree of polish, and a clear vision that is evident from the very first move — go a long way towards inspiring player trust. And that trust is what gets people to settle in, relax, and enjoy.