Starting a Game Design Document, Game Mechanics and Planning

Initial planning stages of our game design document

As we had decided on the type of game we wanted to make, we needed to plan a game design document. This is important as it allows everyone working on the project to see clearly everything that is needed to develop the game. For example, the coders would be able to see where any obstacles in the game needed to be placed, and art designers can see what art assets they need to create.

Ideally a game design document should also have miscellaneous information on the style and theme of the game. For example, it might have information on the way a particular character walks or any special mechanics in the game. Essentially it forms a blueprint for everyone on the game to follow, without being the be all and end all of the design.

In your design document, don’t satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game’s soul you can envision and describe.

For example, say you’re designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You’re going to have to explain that to everybody on the development team, so they’ll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.

(Gamasutra, 2015)


Initial planning stages of the game

Before we started a final design document we decided to plan some of the finer details of the game, such as the way the game would be played and how it would be laid out.

The dangerously addictive (simple reflex, repetition-compulsion) hardcore games of the late 1970s and early 1980s are more comparable to what are now called “casual games”. These are games with simple mechanics and the potential for short gameplay sessions. In fact, many popular casual games today are the dangerously hardcore games of generations past – clones of games like Tetris or Pac Man available on an ever-expanding range of portable devices from the Game Boy (1989) to contemporary cell phones and PDAs.

Douglass, (2007)

We decided to make the game mechanics as simple as possible, mainly for two reasons. One of the most popular game genres for the mobile market is “casual” games. These games are designed to be playable in short bursts, which is ideal for a mobile platform as games played on these devices are often played when the player has some free time between doing other tasks, such as waiting in line at a shop. This also means the games need to be easy to learn as the player may only have a few minutes to play and become interested in the game. Another reason we chose to have simple mechanics was because our target audience is children, and although come children can handle quite complex mechanics, some others find it hard to learn complex user interactions. Another way age affected our considerations was that children do not have the manual dexterity of adults, so some children might find complicated manual tasks hard to perform.

In the end we decided to make the game an infinite running game, where the player character runs continuously along the screen without input from the player. The game play comes from the player tapping the screen in order to allow the character to jump to avoid obstacles. Although this is the only way the player can interact with the character hopefully we can make the mechanic challenging enough for the game to be interesting.


Notes on how we would plan the production process

We also did some planning on how the production process and what kind of game design system we would use. We decided not to use a tile based game system (as detailed here) as it would be a steep learning curve for the designers and would slow down the production process, for very little benefit to the final design or gameplay. Instead we decided to figure all the game logic using SpriteKit’s own physics system. After this planning we were ready to create a final game design document which would become the basis of the game., (2015). Creating A Great Design Document. [online] Available at: [Accessed 20 Mar. 2015].

Douglass, J. (2007). Command lines. [Santa Barbara, Calif.]: University of California, Santa Barbara.

1 Comment

Comments are closed.