Get the latest Education e-news
 
  • Minimal Risk Designs: How to Design a Game When You Don't Have the Time

    [08.06.09]
    - Brent Ellison
  •  It happens all the time near the end of the independent and student game development cycle: your original design gets cut down to its basic premise due to a lack of time or coding resources necessary to embellish on it. Or you get all your designs in the game but lack the opportunity to test and tune them for balance, so all those complex systems you implemented are either ignored or unexplained, and either way, serve only to frustrate the player.

    You can plan better or try to arrange for testing resources well ahead of time, but it's very likely that this will continue to a problem due to inexperience of the team and upcoming deadlines (on student projects), or growing lack of interest and motivation (on indie projects especially, but frequently student projects as well). Polish is difficult and time consuming, and even most commercial games don't get it right. When you're a passion-driven team of first-timers, it's nearly impossible.

    So, although you should plan and budget time for polish in your project and make every effort to squeeze it in, your best bet is to plan for this eventuality ahead of time. This approach to design is about building your game around "guaranteed fun" -- using mechanics that are fun at their most basic implementation. It doesn't mean copying other proven designs, and in fact student and independent games should be doing the opposite, as discussed later.

    Rather, finding guaranteed fun and therefore mitigating production risk is about identifying the elements of designs that hook a player immediately and require little resources or polish to execute well. If you succeed, you can work on your project knowing that whatever product you end up with (even half-finished) will be compelling. And at the final stages of development, you'll have the luxury of being able to choose whether to stick with what you have or add other mechanics, instead of still desperately trying to find the fun in the last few weeks before production ends.

    This requires some work up front, with a willingness to be pragmatic and shoot down good ideas that you know carry too much risk in the scope of your project, but it can save you a lot of headaches when your deadline approaches. Your goal in this process is to get great gameplay right out of the gate, that doesn't need too much tweaking to be fun. With that in mind, the rest of this article will aid you in picking a design that leaps off the screen and impresses in the first pass (maybe even leaving time for polish!).

    Get in the Right Frame of Mind

    Before even thinking about what sort of game you want to make, you should identify your goals. If this is a student project, are you trying to showcase some particular aspect of yourself or your team, like art or design? Are you trying to win IGF? Knowing your goals for the game helps frame your design and identify risky design decisions immediately, from difficulty curve to input scheme.

    From there, you can brainstorm like crazy, but don't get too attached to any single idea. Any worthwhile designer has tons of ideas anyway, and must be capable of identifying and building on good ones from other people. Explore promising avenues and abandon them when they don't seem to be working out. Planning and brainstorming like this takes very little time relative to the rest of the project, but has such a huge impact that there's no excuse for not making the most of it. Be sure to get a very wide pool of potential designs, and think long and hard about production risk before picking one.

    All of this should be standard for making any game, but establishing a good process like this gets you in the right frame of mind to think realistically. This is important because you don't want to pick the design that could make the best game in an ideal world, but rather you must go with the design that strikes the best balance between what is fun and what is feasible with the available time and resources. Coming up with (and culling) ideas is the cheapest part of game development, whether it's 100 people or one, and so deserves mention as an easy way to minimize risk up front.

Comments

comments powered by Disqus