This is part one of a multi-part series on focus in game design, using examples primarily from Knockabout Games.

One of the first things you should ask when designing a game is “what is the game about?”.  This is an old notion, and it’s not original to me.  The purpose is to focus the project and establish criteria against which to measure ideas and features.

This question should really be asked twice, once about gameplay (functionality) and again about context (theme).  Some functional examples might be “territorial acquisition”, “exploration”, or “physical contact”.  Thematic ones could be, say,  “19th century imperialism”, “street football” or “gumdrops”.

In either case, it’s important that there be only one answer.  That doesn’t mean you have to throw out your kitchen sink list of cool features you’d like to implement, but the question you have to ask of each one is simply “how does this feature support the core idea, and if it doesn’t then how can it (or should it be dropped)?”.

I should note that it’s possible during development for all this to change.  Sometimes a supporting feature unexpectedly emerges as the core element that makes everything tick, and by extension, the core focus of the product changes too.  Given the thought put into the relationship between the original core and different game features, that can be ok;  moving the new element into the primary role probably won’t be too hard (but you will have to re-think how, and if, other features still apply).

I could give some interpretations of existing games on the market and what I think they’re “about”, but this is backward looking and not terribly helpful.  Instead, in the next series of posts I’m going to talk about games I’ve actually worked on and how we answered that question at the beginning of the project (and to what extent it held true to the end).   These are all from Knockabout Games, a mobile game development shop I founded and ran from 2002 to 2006.

Next week, the first example:  JAMDAT NFL

I find it odd that traditional game developers take a dim view of those who work on smaller platforms like mobile, handhelds and the web.  These games do tend to be simpler on the whole than their console and pc counterparts, and they lack the same level of production values.  Therefore, the argument goes, making a small game for a limited platform does not afford the developer the same quality job experience as working on a mainstream title.

I’m going to make the case it’s just the opposite.

I used to do a fair bit of sailing.  I even lived on a catamaran for about nine months.  One question that sometimes came up, if you needed crew for a longer trip, was what sort of experience you’d look for.  Sure, some open ocean experience was nice, and a guy who’d sailed everything from Olympic Solings to 65′ Swans was great.  But given a choice between someone with mostly big boat experience vs. someone with mostly small boat experience, which would be better?

Small boats are light and nimble.  They turn on a dime.  But they have fewer conveniences and tools to make them easier to sail.  They are extremely susceptible to the smallest variances in the water and wind, and every little change the crew makes — trim the sails, point slightly higher, whatever — can be felt instantly on a small boat.

Big boats are large and cumbersome.  They move and respond slowly.  As a result, they conceal many of the little changes going on around you.  If you haven’t already acquired a feel for the environment and how a boat behaves in it from sailing smaller vessels, the mistakes you make will be harder to recognize and resolve.

You can see where I’m headed with this.  Consoles and PCs have become large, bloated systems.  They have so many resources available that developers are spoiled.    Yes, more resources enable grander games and new play styles.  But there are so few limitations that developers don’t gain the necessary experience for recognizing and dealing with many problems that do arise.

Developers of mobile, handheld and web games are far more constrained.  Every little detail of these platforms matters, and resources are limited.   When we were making mobile games six years ago, we were trying to squeeze full NFL teams, rosters and playbooks onto devices with 100k-400k of RAM, 1 inch screens, keypads with 200ms latency to the OS, buggy JVMs, untested firmware updates,  and absent documentation.  Uphill in the snow both ways.

It wasn’t Madden, but it was far more challenging to produce a quality, fun experience on, say, a Motorola T720 than a PS3.  And the project’s developers learned far more about the fundamentals of game development because they were constantly made aware of, and forced to deal with, the limitations of the platform.