Starting Out: The First Step of Game Design

For me, one of the most enjoyable parts of working on a game is the first step.  There’s nothing more thrilling than starting the design process over, and working from a clean slate with nothing but possibilities ahead. It can, however, be a dangerous temptation – to abandon work on an old project to start work on a new one. In a way, James and I have been fortunate that the original energy that pushed us through our first alpha of sqube still remains months later, even when starting work on a new game.

In reality, we were careful to keep our amibitions in check, even from step one, and to be as efficient in our process as possible. Part of this has to do with working from a practical starting point, and using that to dictate the timeline for the rest of the project.

No two games necessarily start out the same way. The design process a game goes through should be dependent upon what is most important to the developers. Prioritizing in this fashion can keep a project focused, and maintain the momentum beyond the first big bang of ideas.

As I see it, there are three primary starting points from which a game can be approached:

the rules of the game
the toolset required for the game
the players needed in order to play the game

These three primary starting points for a game are also, in my mind, the three pillars of the design process, which are required in any game, and must be balanced out in order to achieve maximum playability with minimal waste.

The approach chosen by a designer should depend on what their eventual intent for the game is. Based on this intent, the designer can choose which of the three pillars to start with. The primary pillar becomes, in this process, the most static of the three elements, and least variable.

Starting the process in this way keeps the design from becoming too chaotic. It’s best to think of the primary pillar as the “control” in a game design “experiment.” If it becomes necessary to make changes to this pillar, then it becomes necessary to designate another as the “control,” and never let all three elements become variable at the same time.

When James and I started working on sqube in November 2005, we started with a very basic concept: to utilize traditionally two-dimensional gameplay mechanics in three-dimensional space. James worked this into a rough but playable demo, of a line which could be drawn around the six faces of a cube. This offered us the starting point of a defined toolset (a line and a cube), and a basic rule of gameplay (that the line was restricted to movement on the cube’s surface). The design process was able to continue when we devised the ‘intersecting lines’ mechanic, which solidified the ruleset. From this, it followed that the game would be a single-player experience.

In an inversion of priorities, our current project is centered around the idea of having a larger, multiplayer experience, with the competetive gameplay scalable from 2 to as many as 16 players. The rules and toolsets are still currently in a variable state, as we determine the best method of matching – if not surpassing – our original intent.

With regards to the above methodology, so far so good, but obviously there are exceptions to every rule. Concepts are great starting points, but sometimes must be abandoned when the mechanics determined for a game drive the development in a vastly different, perhaps better, direction. In this case, it might be counter-productive to adhere to initial concepts, as they might be holding the project back in the event of a ‘better idea.’

I’ve also only applied this process one-and-a-half times, so there’s a very clear possibility that it’ll prove worthless in the midst of a third or fourth project. At the moment, however, this process is proving extremely worthwhile, and has thankfully held up in spite of the large, geographical distance between myself (designer) and James (coder). I might have to start thanking iChat in the credits for these games…