What Next?

As with any skill, if you want design games and retain the ability to design games, you need to constantly be practising at the same time as researching and seeking inspiration. If really you want to be a game designer then you need to start designing immediately. Of course it’s also easiest if you start off designing as on as small a scale as possible and as simply as possible.

Your early ventures into game design and even your later ventures needn’t be designing video games though. When I started studying game design the first thing I did was work with a group of other people to improve on an existing design of a combat-themed card game. Try as I might I couldn’t quite understand what this had to do with video games but after not too long I understood the way in which all games are related, and that if we as a group couldn’t succeed at working with a very small turn-based game using a very simple number of elements, then we couldn’t begin to handle the task of creating something as complex as a video game. We tested the game, improved the game, wrote documentation for it, and I was actually surprised by how much effort it took to complete just this simple task.

I think it’s a perfect example of why it’s important to start small. It’s easy to rush in and go for something above your level but if you start off simple you’ll be able to better focus on specific aspects of the game design process and get down the fundamental skills without getting overwhelmed. Board games, card games, just about any games you can think of as long as they’re reasonably simple are a good starting point.

Prototyping

With the myriad of ideas a game designer can have buzzing around inside their head at any one time it’s difficult to know which of these ideas really will work in practise and which won’t. Creating simple micro-sized games based around single features you wish to try out will help you learn more about those features. Without testing out what does and doesn’t work you’re essentially making complete guesses about what will be viable and effective when designing your game, and so it’s important to have an isolated environment where you can dry run your bag full of ideas.

Remember, unless you’re checking to see whether your prototype is too taxing in terms of technical requirements you don’t need big fancy computer programs to test out your concepts. As long as your prototyping method fulfils all necessary testing requirements, you want something that will allow you to create prototypes as quickly and as easily as possible.

Game Maker is a tool that can allow you to build simple games with no prior programming knowledge, with little effort, in a relatively short space of time, and can be a fantastic playground for testing out game mechanics (it can also be good for getting to grips with some of the basic concepts behind programming itself). Our friend Schell even recommends using paper prototypes for some games, and prototyping narratives by showing concept art and written character designs to target audiences.

Sadly prototyping can also be a time where you discover that ideas you were highly enthused about are just not viable for implementation in your game and need to be drastically changed or scrapped entirely. While as a game designer you must be enthusiastic about your ideas to allow them to blossom, sometimes you just have to let go of an idea you loved and admit it’s not possible for implementation.

Design Documents

With early, very small-scale game design projects it’s often possible to create games with no more than a set of notes or a list of rules to guide your design, in fact some of you may find it possible to create a game with no written design whatsoever (not that I recommend that) but the matter of the fact is design documentation is an integral part of creating a game.

What goes into a design document? Well, everything. You’ll need to detail every aspect about every enemy, every feature, every object, every level, and everything else that you’ve come up with. If you thought video game wikis went in-depth they are nothing compared to a game design document. It may sound like a daunting task but it’s been proven that it’s a highly necessary one. When you start dealing with the depth and complexity that lurks below the surface of a retail-size video game there’s way more information than a designer can deal with without having it all in print. What’s more you will need to communicate every detail of your design to the dev team you are working with.

In fact it can often be useful to think about design documents from the perspective of another member of the development team, usually the programmer makes the best candidate for this kind of thinking. Imagine the programmer looking through your document and having to code everything based on what you’ve written. Remember, the programmer can make absolutely no assumptions about what you wish them to code; their job is to follow your plan exactly. If the programmer was looking through your document and noticed that you hadn’t specified exact jump heights for all of the enemies in the game then they’d screech to a halt and have to enquire as to why the design document is incomplete. A good design document is thorough but communicates your design as clearly as possible.

Testing

Once you have the first iteration of a game complete the next step is to test it. In fact with any game you create, the earlier and more often you can test the better. The creators of a work are by default some of the worst judges of it and whenever possible you’ll want your work tested by an outside group. Be wary of testing with friends because social obligations and bias can work its way into the mix, tainting the testing process, even if you try to make sure it doesn’t happen, however almost all testing will highlight strengths and weaknesses within your game. When testing early iterations of your game many of these strengths and weaknesses often become apparent almost immediately.

So, how do you go about testing a game? Well, if you’ve got a non-video game or a video game with no implemented tutorial or instructions screen then you’ll need to have some clear, well-written instructions printed out for the player/s. Once you have your players there give them a quick briefing on the testing, but be wary of telling them any of the rules beforehand, letting your instructions speak for themselves will prove whether you can really convey the information about the game that the player needs. Once the player or players are taking part in the game simply study their play and record what you can about their play session. If possible record video of the play session as you can then go back and observe the way the players interact with the game as much as you want and make notes from that. If recording video really isn’t an option then just take notes directly from what you observe.

During the testing process it’s essential that you do not interfere with play unless it’s absolutely necessary for you to do so to ensure that testing continues. You may feel an urge to intervene in the testing if the player is not playing the game in the way you intended but it’s important that you do and say nothing. If you do interfere you’ll ruin your testing by disallowing the weaknesses of your game to be highlighted.

After the play session find out how the player felt when playing your game by asking questions about their experience. Really think about what feedback you need to improve the game and write questions that address the issues with your game you need to know about. When writing questions also remember to refrain from using leading questions and take into account that it isn’t the tester’s job to work out what is right or wrong with the game, and that they may not understand many of the exact issues with it anyway. It’s up to you to really get inside the tester’s head and deduce from their experience what is right and wrong. In general, during the testing process you should be very open to the players’ actions and opinions. Think very carefully before deciding that they are “playing it wrong” or “not getting it”. If they’re not satisfied with certain aspects your game then the case is probably that your target audience wouldn’t be either.

Once you’ve analysed your notes and your interview results you should be able to compile a list of modifications you need to make to your game. You’ll need to make the good aspects of your game shine through better, work out how to fix the bad aspects, and in some cases scrap parts of the game altogether. It may be the case that you think you’ve built a great game overall and then you see it fall apart the moment it gets into testing, but don’t get discouraged, all game designers fail and it’s a way in which all game designers learn. Remember, documentation on what needs to be revised in the game should be just as neat as all other design documentation.

So, what after you finish the testing and you have the new version of your game? Well, you test it again, and change it again, and test it again, and change it again, and so on, and so on, until you have your final product. In fact you may notice a point in your testing where you realise you could make almost infinite modifications to your game design. For the moment don’t spend months working on one game when you could learn a lot more by creating new games on a fairly regular basis. Additionally don’t be too alarmed if you find the whole testing process a bit daunting at first, as time goes on you’ll gradually become better and better at it, and you might be surprised by the amazing results a bit of testing can yield.