Development of a Game Concept

This article is intended to give an example of one way in which to develop any idea you are currently thinking about. It's certainly not the only way, and I'm sure that many other designers have developed alternative and superior approaches, but some of the information in this document may be useful for many.

The exact nature of how you develop an idea from scratch varies wildly from company to company, based on a large number of variables including available technology, resources allowed for the concept design, varying requirements etc. This article is about the development of a paper document, and doesn't assume that you have the ability to make a prototype version, animations, mock ups etc before documentation is complete.

If you DO have the resources to make a prototype version or any other contributing work, then it is my opinion that this should be done after the brief design.

The Concept

When you first sit down to come up with a game idea, you may have several constraints - game genre, environment, budget, time restrictions, team make up etc etc, and all these have to be considered in order to come up with a basic idea. Although the nature and level of these constraints will differ from project to project, they all add to a framework within which to work. Once you know these, then creating a concept becomes much easier. At this early point in the design, you can't (and shouldn't) get too concerned about the details of cost and time, but it may give you some hints - if the game is supposed to be low budget, low time, then creating the "next big thing" is likely to be impractical.

Within the framework of these restrictions, you need to create a concept idea for the game. I like to create the concept idea like a small proposal document which contains a "vision" of what you are trying to create, an idea about who you are aiming this game at, why those people would like this game and other notable ideas that make the game advisable. These reasons don't have to be consumer related, they could be to do with development advantages, such as the creation of useful technology for the future, budget issues etc etc.

At this point in time, it is useful to get some idea from the development team as to the type of game they would like to work on. Some people will be more concerned with the environmental style (sci-fi, fantasy, Western etc), others may be more concerned with technical detailing (AI systems, renderer features etc), and others will favour genres (FPS, RTS, adventure etc).

If it turns out that a large number of people would like to work on a particular style of game, then it should be seriously considered, assuming that this fits within any of the other constraints that you have. The chances of making a great game are much higher if people are enthusiastic about what they are trying to create - people will generate a lot more ideas, and care about the quality of their work more.

IMPORTANT NOTE: When you are trying to get a feel for the type of game the team wishes to make, you are not soliciting for ideas. Although you shouldn't discard any ideas that are sent to you, the game is too undeveloped for people to effectively add to it. If you try and solicit ideas without having any sort of concept ready, then you are likely to get a large number of ideas, many of which are contradictory and don't fit within the scope of the game you are trying to create. Part of the reason for doing early documents before the main design is to give the rest of the team a framework within which they can work, so you can get ideas when they are most useful. YMMV on this point, but I've found getting too much input at this stage is very counter productive.

After writing this, you have a small document that provides the focus. Ideas that come up during the main stage of writing your design document can now be compared to this to try and help avoid heading off at a tangent, following new ideas that spring into your head. It's all to easy to get excited about a new idea, and include it even though it doesn't keep to the main aim - one of the ways in which the schedule and budget for your game can expand rapidly.

So now you have your concept which briefly defines your game. Time to show it to someone technical.

Many designers (and other developers) will wonder why I would want some technical feedback on a tiny concept proposal - there certainly isn't any detail to get much useful information. This is true. However, by showing this to a programmer, you can get useful information as to the feasibility of a particular concept. Remember, it's very easy to write down an idea, but actually implementing it is a whole different world.

Most of the time, the technical feedback will be very simple, and will just result in the designer going back to work to continue developing the concept, but sometimes problems can be spotted and removed before anything else is done - if the core idea or other features of your game isn't technically feasible given your constraints, then you can alter them before you have spent much time on them. If some of the key features are more art related (e.g. it's vital that we have hundreds of different characters), then get input from an artist too. The earlier you can catch a major problem, the quicker it is to fix.

If any rework is necessary, do it, and then you're ready to move on. We'll assume that marketing and other departments are happy with the concept. If this isn't the case then the concept might need altering, or even scrapping completely.

Idea Generation

Now you've got an approved concept. Everyone involved is interested to see how it will progress. What now?

Now you want to expand on the concept. This is the real time to start letting your imagination run wild.

At this point, don't worry too much about any technical or artistic constraint, and just try and come up with fun and interesting ideas. Don't write a lot about each idea, but put enough down so that it is easy to see WHY the idea is good. A paragraph or so for each idea is suitable, but if more is required, then do it. This is supposed to be a fairly short and quick document, so don't get too involved in detail.

Encourage other team members to send you ideas if they want to. However, it is important to make sure this doesn't impact on the work they are doing at the moment - whilst you are working on the design for the new game, they may well be in a critical stage of development on an existing title. If you can, set up a newsgroup for the game, and post to this group with summaries of ideas, asking for input.

I found it better to do it this way rather than asking people to post directly to the newsgroup as it is very easy for things to head off at a tangent, or too much time get taken up by poor ideas. Although it may sound overly dictatorial to say that in the early stages you moderate the ideas that people talk about, as a designer you have to take some responsibility for filtering the ideas that come in. Sometimes you'll want to work on an idea a little more before you post it, sometimes you "know" an idea is unworkable, or has too many con's for the pro's - there ARE reasons to not post every idea. As the game moves on, this restriction is lifted, as the game is far more defined and it is easier for people to come up with suitable ideas.

Remember to evaluate each idea as it fits in with the game concept, as well as it's stand alone potential. If you don't do this, it is easy for the idea to get away from you. However, don't discard these ideas - some may be strong enough to warrant changing the concept slightly and others may not suit this project, but would be fantastic for a future one. At this stage, the game is not approved for development, so you may need the other ideas sooner than you expect!

The ideas generated in this part need to cover most aspects of the game - although new ones will come up during the process, to continue or not is largely based on the quality of the work generated.

The idea generation phase is fairly informal, and happens concurrently with the next part.

Brief Design

The brief design phase is the point at which you gather all the accepted ideas, and form them into a mini design document. The brief design needs to cover the features of the game, how the game progresses, including mini descriptions of levels or missions if applicable etc. The information within this document is the core from which the full design document is built, and therefore it should be easy to see how the game will progress by examining this doc.

This document will also be used to help evaluate technical, artistic and design resources required, so it is important that it is well thought out, accurate, and very importantly, as unambiguous as possible. Ambiguity is a huge problem in games design - phrases such as "realistic AI" creep in, which are almost impossible to judge from an implementation standpoint, resulting in wasted and misplaced effort. You won't be able to remove all ambiguity - that's what the full blown design document does - but you can, and should, reduce it wherever you find it.

A very important part of this document is an idea of how important each part is. Ideas can be important in two different ways.

	The idea itself is one that provides a real boost to the game.
	The function that the idea provides, or problem it solves is important to the game.

Although the two are similar, the difference in the way you treat the two is significant. They both deal with the importance of features within the game BUT, the first deals with an idea, the second deals with a solution. Most games require solutions to various issues, and therefore a solution is vital but the actual nature of the solution is less important. This might seem like splitting hairs - a lot of the time great ideas are solutions to problems, but when it comes down to deciding where to concentrate effort during implementation, this difference can save you a lot.

Note: To give an example of this, I remember hearing from a scriptwriter about a script he had written for a television programme. He mentioned that at one point he had written that a character leaves a cabin, and after leaving, it burnt down. This cabin was in a wooded area, and the writer turned up for filming to find a number of fire engines, ambulances etc etc, which were all required for such a stunt. The burning ended up costing a lot of money when it was only an off the cuff idea from the writer.

If, in the script, the writer had mentioned that this idea was unimportant, then a lot of time and money could have been saved, and used in alternative areas.

Remember, at this point in time, you have created a "blue sky" design. You haven't worried overly about the practical nature of your ideas, just their potential and ability to make a great game. However, since you have designed the game like this, areas of it are likely to need rework in order to turn this into an achievable game design, and knowing which areas you are most and least keen on makes this process much easier.

After your initial creation of the document, you need to get feedback from people as to the features and ideas contained. The feedback should tell you how resource intensive your ideas are, and their opinions as to which ones will work best and worst. Having got that feedback, you can go back to your document and reevaluate. Simplify areas of your design that seem to require more work than the reward they give, as this will allow greater effort to be put into the truly important areas.

It may seem strange that in the idea generation section I talk about not worrying about technical and artistic constraint, and I'm already talking about reworking ideas that aren't practical, but most features that are impractical can be simplified down. Once you have worked through to the kernal of an idea, you can try and capture what makes it great whilst lowering the cost.

Some designers may think this is just an extra, unnecessary step, but I feel it is very helpful.

As with the concept document, it provides focus - you know exactly what you are trying to achieve, and won't deviate without good reason.

It gives the company an idea as to the resources required to create such a project. It won't be very accurate, but the decision makers will be able to see roughly how much new technology would be required, whether the game is likely to be low, medium or high budget etc.

It gives the framework for the detailed design document. It is important that the detailed design is as all encompassing as possible, providing all the necessary information required to create the game. This is a complex undertaking, and a brief design document can aid with this, providing a framework that needs to be filled in.

It is easier for the team and other connected people to get an early feel of the game before too much time is spent.

The designer can evaluate the game in it's entirety, as opposed to being concerned with individual ideas or sections - you can see whether the the features all fit together, how complex the required UI will be, whether the game is still fitting within the constraints laid upon the project.

After creating this design, you have a summary of the detailed design document - a non technical and easy to read document. Making such a document also shows the areas that need working on for the complete design document.

Once this has all been done and approved, then you are ready to move on to the full detailed design, and the foundation of the team is ready to put together! But that's a topic for a different article...