Design Pre-Production

04 February 2020 - 7 mins read time
Tags: Games Design Personal Final Project SHMUP

An important and key aspect to designing game is not just the idea itself. Games are a large undertakings even if it’s a small one developed by a sole person. For this reason, just jumping from vague idea to GDD[1] doesn’t make any sense. If you move from a rough idea to suddenly attempting a full document without thinking about your game you’re heading for a failure. It’s important to think about the use cases of your game and it’s design. If you give some deeper thought to the game before jumping into development and actually spend some time in pre-production, the idea will not only be more solid. But might even drastically change before any actual work has been expended, thereby saving time and money. (Bethke E, 2006)

With these words in mind I’ve decided to try and take a look at some solid pre-production principles for my game as Design is one of the few fields that is actively involved within every process of a game’s development and I feel that all too often no-one takes a look at how to think about a game and what methods are used to write up a games design document or production plan.

An important part of the pre-production process for a design is that of figuring out what exactly the game is. There’s a lot of important questions that need to be asked and answered before anything else can progress. When it comes to my project Soul Engine I’ve found that I myself needed to answer these questions before I could even begin to progress on my GDD, let alone my proposal. Some of these questions are:

Having looked at the proposed game development process by Stefyn N, 2019. I took these questions and developed my initial idea around them to try and formulate more specifically what my project is. If I can reasonably understand these questions, then I have a firm foundation for the rest of the project whatever that may be.

With these questions answered I now have a basis of what my project is and so I can move onto the Games Design Document. It seems counter-intuitive at first to create a Games Design Document before the proposal has been created but creating a draft of the Games Design Document can actually help inform how the proposal will go as it becomes easier to estimate tasks when a draft of the game has been designed. (Bethke E, 2006)

The Games Design Document is integral to the project and its creation as a document varies wildly from studio to studio and there’s no set standard amongst developers or designers as it’s usage depends entirely on the context it’s written in. (DeWinter, J. and Moeller, R., 2014.)

With that said, there’s a series of GDD types that the industry uses as defined by (Rogers S, 2010)

These are as follows:

  1. One-Sheet
    A one-sheet can generally be described as a single piece of paper which provides a brief overview of your game as a whole. It’s target, it’s plot summary, it’s characters, it’s gameplay, it’s USP[2] and other market products. The sheet serves its purpose as a reference guide for financers, producers, marketers and for just getting the game across to people in a succint way.
  2. Ten-Pager
    With an outline complete a “ten-pager” as it’s called provides a strong foundation for the overall GDD. It forms a spine of the document and is the real meat of the game that publishers and others will read and draw from due to its concise but detailed nature.
  3. Games Design Document
    The Games Design Document is a fairly large document that serves its purpose as a repository of design knowledge that’s stored. It can be gleamed for reference as to enemy purposes, story intents and other such details. Art and Technical details should ideally be separated into their own respective documents to keep everything as concise as possible.

When it comes to creating a GDD there’s a varying split in how to manage or create them. Some use documents and treat it like an actual book where people can read the relevant sections and add to it on a whim and others purport the usage of wiki’s for management in teams given their robust nature of being edited, their ability to compartmentalise information into neat sections and not have a long scrolling document, as well as offering the ability to link members to the relevant sections when asked and finally they are always up to date given that they are always on a service and retain an editing history that can even be source controlled for easier data management. (Friesen A, 2014)

Having looked at wiki’s as an option I decided to opt against them simply because they’re are far more useful for teams to work on. As I’m the sole developer a single GDD is far easier to manage and control and I’m very comfortable with the interface and layout of a word document and there’s no need to begin taking risks with the management of my document when using what I know will suffice for this project’s purpose.

At this point in the project with a GDD created and formed with a good one-sheet and/or ten-pager it’s time to move onto a project proposal if required. In my case, it is. So my project proposal will follow a standard format as outlined by (Bethke E, 2006) After the proposal is done, the GDD is picked up and continued with. As stated by Bern Kreimeier in a 2003 survey game design methodology and Game Design Documents are interwoven with each other and vital to the whole development.

Even as the game continues the GDD will constantly evolve and be updated and thanks to my research into pre-production and document practices I feel safe in the knowledge that I have decent handle on my project’s ideas and how to manage my documents for it. By using a mixture of word docs and excel docs I’ll be able to keep track and update any designs as necessary throughout and with the additional planning at the start by narrowing down what my game is I have a strong starting basis to keep moving from and have far less questions about what it is I’m doing exactly.

phew this was a long one. I’ll catch ya next time for a final update as to what my project is before I submit proposal and finally begin work on it.

[1] A GDD also known as a Games Design Document is a document used by developers to document and track game ideas, designs, narrative, art, UI and more. It serves a repository of knowledge on the game usually in the form of a document.

[2] USP or Unique Selling Point Is a feature or features which give the game a unique edge within it's market. For example the first 3D platformer could consider it' s USP to be that of it's 3D technology which makes it unique at the time of creation.
Click to see Bibliography