Student Post-Mortems

In a class I taught that just finished, I had the students make a complete, full-featured, production-quality board game from scratch over the course of a month (this was the major project in the middle of the course). At the end, I asked everyone to do a personal "post-mortem" by listing the things that they felt went right and wrong in development.

The list of things I see are astonishingly similar to the professional post-mortems that you see on Gamasutra when people make video games, and I feel echoes of previous classes I've taught where students made video games. So, I think a lot of these lessons are generally applicable, and worth sharing.

Rather than breaking it down into things that went "right" or "wrong" in this particular class, I'll list these as general points of advice that were repeated themes throughout the class. Some students listed these as things they did well and were thankful for; other students listed the same things as weaknesses that they wished they had paid more attention to. For our purposes it doesn't matter; this is the advice that my class would give you and your students.

• Playtest your game regularly, several times a week. Start as early as you possibly can. The earlier you start, the more time you have to make radical adjustments. You can never playtest too early or too much.
• Playtest with a variety of people, not just the same group of friends. Test with family, classmates, complete strangers, anyone you can think of. New playtesters offer new insights. The wider variety of testers you have, the broader the appeal of your final game.
• Start with a simple, strong core concept. If you don't know the purpose of your game or where the fun is supposed to come from, you'll have a hard time getting there. On the other hand, if you have some basic gameplay constraints that you create for yourself, a lot of gameplay will come naturally from that and it will feel like the game is making itself.
• Be wary of oversimplification. In general, it is harder to simplify a game than to make it more complex, and you should strive to make your game as simple as possible. There is a flip side to this: if you are overzealous about streamlining the rules, it is possible to accidentally remove player interaction, interesting decisions, and strategic options. When you remove rules from your game to simplify, pay attention to the play to make sure you are not removing a critical element.
• Observe people playing your game, without interfering. The learning curve of a game is critical, and the only way to gauge this is to have new players sit down and try to play without your assistance. Watch them struggle and see where they fail. This is one of the only ways to identify critical holes in your game in the end stages; as the designer, you are too close to your own creation to see the obvious flaws yourself.
• Don't neglect theme. In an effort to build the best gameplay possible, don't forget that a strong theme that fits the mechanics can make the game easier to learn, and a fun theme can generate player interest from the start. Include something that players can personally identify with in the game, to make it easier for them to feel like they're "in the game."
• Some mechanics are higher risk than others. If you are doing something that has never been done before (or has only been done rarely), the final project will take a bit more time, and you should be prepared for that. There is probably a reason why it hasn't been done before, and the reason is probably that it is hard to get it to work! If you are heading into uncharted design territory, expect to spend at least double the time on the project that you would have otherwise.
• Pay attention to readability. Some color combinations make your game difficult to read (I've seen black text on a dark blue background which was nearly impossible to read, and also yellow text on a violet background which was just painful to look at). If you haven't studied color theory, at least look at all of the text and icons in your game and make sure you and your playtesters can read them without eye strain. Test in both bright light (e.g. outside in the sun) and low light conditions.
• Leave time for "polish" at the end. When you have a month or two to make a game, it feels like you have forever. Realize that you would ideally like to have everything "done" earlier than the final deadline, so that you have plenty of time to make the game look more professional. Little details matter in the final presentation, but you will only have time for them if you don't procrastinate and if you build this expectation into your schedule. (Even then, it is often hard to do.)

There were also a couple of hints that are specific to board games:

• If you are making any custom components, do "proofs" before paying to print the whole thing. For example, if you're printing many sheets of cards, print a single sheet to make sure everything lines up right and that the colors don't bleed.
• Avoid printing double-sided if you can, because it's hard to get everything lined up. If you must, add a thick border which will help mask any cutting errors.
• Allot plenty of time for creating final game components. Even if your rules are finalized and you know exactly what you need, the process of actually building everything (which might involve painting wooden pieces, printing at a local copy shop, cutting pieces, and any number of other things) takes a lot longer than you think it will, so don't leave it for the last minute.