People often wonder why a bad game is bad. Sure, there are always obvious clues… it might have poor pacing. Or be extremely repetitive. Maybe it’s just not fun and you can’t quite figure out why. These might all be very real issues, but they nearly always stem from a single problem: a lack of focus somewhere in the game development process. The failure to establish clear priorities is nearly always the core reason for a game’s failure.

It’s crucial that the designer or project lead sit down and spend as much time as necessary to establish what the goals are for a particular feature (or the entire game, as the case may be). Maybe you’re designing a combat system in a strategy game. Do you want it to feel fast and dynamic like the German blitzkrieg of World War II? Or more of a brutal defensive slog like the Western Front in World War I? Which side wins? The one with the best tactical skill? The one fielding the best-supplied army? The one who simply brings the right type of units to battle? How important are melee units compared with ranged units? What ratio of units should most players be fielding? Should it be possible to lean heavily on a single type of unit, or should a mixed force be required? These are just a few of the dozens of questions a designer should ask himself before fleshing out a single detail or writing one line of code. And as the design comes together, hundreds more questions should be asked and answered. When you’re lost in the woods several months or years later (and trust me, you WILL be), racking your brain for the best direction to go, looking back on the answers you came up with to these questions will be more helpful than you can imagine. Just as in war, no plan survives contact with the enemy.

…

Focus is also critical when it comes to actually making the game. Producers are often maligned (what do those folks do, anyways?), but it’s often painfully clear when a poor one is helming a project. Even in the indie space, there are virtually zero developers out there who can afford to spend unlimited time and money perfecting a game. Finite resources means you need finite goals, because if you try to do everything it’s just going to end in a tragic mess of incomplete features. Not only that, nearly every aspect of game development takes (much) longer than expected (my personal rule of thumb is to take your honest-to-goodness, genuine, ‘best’ estimate, then multiply the time required by three. This works much more often than I’d like). The first rough draft for a game is nearly always terrible, and the only way it gets better is through iteration. But you need time to iterate, and the only way you’re going to preserve that essential buffer is with extreme discipline when deciding what does and does not get worked on.

The features I’ve designed or programmed over the years which I’m least happy with are always those where either 1) I didn’t have a lot of time to work on them, or 2) I was so deep into developing a feature that my sight of the endgoal grew hazy. While it’s easy to say “duh, just worry about what matters,” it’s one of the many situations where it can become nearly impossible to see the forest for the trees. The todo list when making a game is always miles long, and when you’re working on one feature it’s easy to fall into the trap of knocking out a few related ones just because they’re easy, instead of staying focused on implementing only what is absolutely essentially at that time. By far the most important trait a game can have is that it’s fun, and you want to get to this point as soon as possible. Being frequently derailed by low-hanging fruit can be catastrophic in this mission. Don’t get distracted by what’s easy or shiny. Establish goals and stick to them. Make sure to also constantly re-evaluate these goals and make sure they still reflect what you want from the game, but the greater sin by far is pushing forward without a target, or a lack respect for the ones already in place.

This kind of workflow is heavily tied into the debate (if you can really call it that) between the so-called ‘waterfall’ and ‘agile’ project management models. For those unfamiliar with these terms, the basic theme behind waterfall is that you plan everything out at the beginning, then execute on the finished plan. Agile on the other hand is more about having a rough plan and only figuring out the details every few weeks or so, and using each of these ‘milestones’ to evaluate progress and course correct as necessary. I’m a big proponent of the latter, as are many in the games industry, but it requires capable and tireless management to be successful. When poorly managed, agile can also easily fall into the trap I talked about above, where the high-level goals of a project become fuzzy and might be completely abandoned – often unintentionally. In fact, in agile development strict prioritization is even more critical than in waterfall, simply because you don’t want a project darting here and there with little regard for the high-level goals are or how close/far away they are. One again though, this isn’t to say that that high-level goals should not change, because they should when it’s appropriate. Maybe you find out that a feature you were really excited about and thought was going to make the game… is actually no fun at all. Well, it’s time to do some soul-searching, go to a park and stare at the clouds for a spell and come up with a brand new endgoal. What you don’t want is to ever be in a situation where you have no goal at all.

Sid Meier is one of the best ever at keeping focused and only spending time on whatever will do the most to improve the game – and it’s no coincidence he also happens to be one of the greatest game designers ever. People wonder why Sid is so good at what he does, and this is his secret weapon (sorry Sid!). He’s better able to get at what’s important in a game than anyone I’ve ever known. He’s refined his craft to the point that he can produce a mostly-finished prototype in a weekend or two. This is only possible if you’re wasting zero time on non-essential features. Something else important to point out is that Sid has thrown out dozens, if not hundreds of prototypes over the years because, well, they just weren’t very good. If Sid Meier’s batting average on games is that low, is it any surprise that most games (which go through much less iteration) which actually end up on store shelves fail?

If you remember only one thing from this article, take this to heart: the only parts of a game which matter are those that end up fully implemented and polished. Good ideas that never make it off the drawing board, or – worse – don’t get the love they need are at best irrelevant, and at worst can do irreparable damage to your game.

– Jon