Visuals matter, even at the playtesting stage. First and foremost, they attract testers. People will stop and ask about a visually appealing game, whereas you’ll have to work to drum people up for a game that’s scrawled on a sheet of paper.

Second, they help teach the rules. If all of your components are 3″ x 5″ cards with numbers on them, your game will seem more complicated than it is. Using some graphic design will help testers engage with the game in a deeper way, since they won’t be wasting energy trying to remember which featureless cards go on the left and which go on the right.

Don’t waste time making art for every prototype, especially early ones. When you have an idea that’s working, though, take the time to do some simple graphics for it. Your process will benefit a great deal.

There’s good juice and bad juice in video games. Good juice directs the player’s attention to where it needs to be, and clearly indicates what the situation is so that the player can respond correctly. Bad juice either misdirects the player or gives confusing feedback. Don’t simply assume that your game is automatically getting better because you’re putting more juice in; test to make sure the juice is the good kind.

As a negative example, take a look at Super Street Fighter II Turbo. The particle effect for a blocked attack is blood red, while the effect for a successful hit is light blue. Although this might sound arbitrary-but-harmless, it’s pretty confusing during a fast-paced match. Seeing what looks like blood splatter, but is actually an indication that no blood was spilled, can easily lead to wrong play. Avoid bad juice!

Think first, code second. If you launch into programming instantly, you’ll find yourself making design decisions without even realizing it; implementing a feature this way instead of that way will constrain what you can do later. Know where you’re going, at least in a general way, when you sit down to the computer; it will help ensure that you’re in charge of the tool, rather than the other way around.

Furthermore, once coding begins it gets very hard to zoom out and think about design issues. Moment-to-moment bug fixing, architecture, graphics and sound . . . an endless series of implementation problems start demanding attention. While it’s tempting to get something on the screen as fast as possible, use the time when those concerns are still in the future to focus on the design and make sure that it’s as strong as possible.

It’s possible to create a game that’s fun, not because the design is good, but because it’s built on an inherently fun activity. When working on a game whose foundation is something like Truth or Dare–something that’s popular even before your game gets involved–it’s critical to pay close attention to what your design is doing. You’ll get lots of positive feedback just because the foundation is entertaining, even if your design isn’t adding a lot of value (or, for that matter, is subtracting some value!). Listen closely to the feedback, and make sure it’s about your design, rather than the underlying activity.

While in law school, I was advised never to “whistle past a graveyard”–to ignore a potential problem. It’s equally good advice in game design. If you can imagine a problem, players will certainly encounter it, and in its worst possible form.

Playtesting today reminded me of this in no uncertain terms. I knew it was possible to move one’s general in Phalanx to awkward places in the middle of formations, and thereby prompt weird behaviors–but who would do that?

Everyone. Everyone will. And why not? The game allows it, so surely it’s good sometimes . . . .

I’ll be taking that ability out of the game. More importantly, though, I’ll be taking the lesson. Don’t whistle past graveyards. You’ll always have to go back and deal with them later.