11 Tips to Speed Up your Game Design Process

At the start of a project, everything has yet to be done. There are loads of tasks at hand, and it is hard to tackle them in the right order. As a game designer, our job involves some writing. Often a lot of writing.

The large, almighty Game Design Document is a myth. I am talking here of a hypothetical file that would contain every bit of information there is to know about a game. For larger teams, they are too many elements to record and keep track of to have them all compiled in a single document. And sections of a GDD are relevant but to a small portion of the development team.

Documents are less than ideal when it comes to assembling coherent networks of information. But we still have to write a lot in the pre-production phase of a game. However, there are ways to limit the amount of writing we need to do and to facilitate our teammates’ jobs at the same time. If you are working in a studio already, you’ll have a lead designer to tell you how to work. In this article though, I’d like to give you a list of general tips to design as efficiently as possible at the start of a project. It should be of use for your personal projects, as a freelancer, and it should work nicely with most studios’ guidelines.

1. A short prototype is worth a thousand words

A design document made of raw text leaves a lot of room for interpretation. Any amount of words can’t portray accurately the expected feel of a game. On the other hand, the essential mechanics of most game concepts can be coded and tested in little time. Often, it takes about as much time to develop a prototype it takes to write a corresponding detailed design description.

A prototype both describes and provides means to assess the quality of a game concept. To me, this is an ideal starting point for the preproduction process. Documents or discussions are too remote from the actual game, and end up wasting time. However, a playable sample gives every team member a concrete sense of what the game could be. It gives everyone an experience to give feedback on. It is also both fun and motivating to have a working prototype.

There is no need to spend a lot of time on this initial implementation though. Fancy visuals are out of the question. They would not only waste your time initially, but they might also prevent you and your teammates from properly judging the gameplay. Pretty drawings tend to mask the pitfalls of our design choices.

2. Lean documents

Everyone is busy in a game development team. Nobody wants to read through long and tortuous bodies of text. Heavy documents are the bane of our coworkers. In particular on large projects. One can only process so many pieces of information at a time. One can only retain so much about the project’s details overall. An efficient design document should focus on conveying the key information that each teammate is meant to use.

You can take example on screenwriters: the script of a movie is always written in a simple, descriptive language. The font is big and the document lightened as much as possible. Everything is arranged so the reader’s experience stays fluid all along, regardless of his reading skills. Movie scripts are designed for busy producers and coworkers to get the author’s point.

Writing efficient and lean documents does not only clarifies your thoughts for everyone: it shows your mastery of the topic at hand, your understanding of the studio’s needs. Long paragraphs and elaborate phrasing waste both your and your readers’ time. Simple is also extremely fast to write, as it stays close to a spoken language. In turn, it gives you more time to focus on other exciting design tasks. I’d personally rather be drawing or coding than writing long technical documents. Not you?

3. Write with your peers in mind

As designers, we write design documents for others. It may be for a client, a manager, developers, etc. They all have different needs and expectations. A client may not care about the details of your chosen technology for implementation. On the other hand, your developer teammates will likely need some details to estimate the technical constraints that will arise from your choices. In other words, you should adapt both your tone and content to your readers. Part of your role as a designer is to understand your teammates and their needs. Your writings are not only meant to provide the necessary resources for others to do their work. You also have the power to facilitate their job or not.

If you want to do your peers a favor, and improve your writing skills: just ask your readers for feedback! Your coworkers will be glad to tell you what they’d like to see changed. Or if anything could help them working faster. Ideally, you would want to know how each profession in the studio works. What does everyone’s job entail? That is the best way to get into the mind of others: share their craft. But well, getting feedback should be enough to satisfy everybody.

4. Run tests to prevent unnecessary chatter

This point relates to the first one in this list. Your ideas leave room for interpretation… And for discussion! This is especially true for clients who don’t work in the game industry. They might dislike a coherent and efficient design if they have no opportunity to see the resulting game first. Just because they don’t trust you just yet or had something else in mind! It is often easier to show, controller in hand, that a design choice does or does not work, rather than to explain it. It is common to disagree on a given mechanic and get bogged down arguing over the advantages of some choices.

When you are unable to take a decision over 2 options, a set of reference games can help. The advantage is that everyone in the team can experience the variation between 2 mechanics. Everyone can get a good sense of which one works best and why. Sometimes, it won’t be sufficient to solve conflicts. In that case, the easiest thing to do is to let the lead decide and move on. But often, a prototype will help to unlock the discussion.

5. Do your research at the start of the day

Looking for new ideas is a brain intensive task. It can exhaust you within a few hours. Bouncing back and forth between concept research, programming, drawing and writing will suck your juice in no time. This is a general productivity tip: if you want to stay efficient for a whole 8 hours a day, you need a short term work plan. A list of tasks to tackle in a smart order You should gather all of the raw material, the ideas you need when you arrive at the office. Or even the day before!

That is one of the most basic productivity hacks. Always plan all structure your work. It permits you to focus on the big picture, on arranging ideas all at once. It almost relieves your mind from that heavy-duty for the rest of the day.

Propositional concept artist start their work with thumbnails. Animators with rough animations. Composers with the chord progression or a thematic structure. And writers with an outline. Only that way can we keep working at it can stand, satisfying pace, over the course of a whole project.

6. Learn how to code

To me, gameplay programming is part of the fundamental skillset any game designer should have. For one, we have to communicate with developers often. Because of that alone, it’s useful to understand what coding entails. At least to some extent. But more importantly, this permits you to test your ideas by yourself. It makes you more autonomous, knowledgeable and efficient overall.

A game designer who codes is also an ideal match for most game studios. You just need to know your basics and to have a few samples of your work to prove your skills. With that, you will have no problem finding work. If you can code, other developers won’t need to translate your documents and iterate based on your input anymore. Instead, you will be able to provide them with a playable example showcasing the basic healing balance you are aiming for. You will be able to stay productive throughout the whole game development cycle.

Strong programming skills are extremely useful if you are looking to progress professionally. A good lead needs to be not only skillful, but also versatile to some extent. And anyway, there are plenty of stable positions available for developers out there. They are sought after, contrary to artists and marketers.

7. Use pictures

“An image is worth a thousand words”, or so they say. The saying is often right, provided that the picture is relevant. You can illustrate a level’s layout and challenges well with a plan. There is nothing like a concept painting to give a good sense of your future game’s ambiance. You can also describe systems with easy to read diagrams better than with plain text.

Coming up with good figures for your documents may take a while. But they can both clearly convey your ideas and greatly enhance your teammates’ reading experience. A lovely picture will even help to sell your writing. This is a sad truth, but a truth nonetheless: the overall visuals and feel of your documents will affect your peer’s perception of your work. It is not enough to come up with a great concept. You also have to know how to properly present it.

8. Shorten that iterative loop

Don’t wait to have a whole slice of gameplay to put your game in the hands of testers. By then, you could have wasted time polishing poor controls, focused on a technical aspect that doesn’t matter to your players, or worked on the system so big that you can only backtrack at an unpleasant cost. In any design related job, it is critical to iterate, and to do so fast.

An iterative workflow means that you should tackle a limited set of rough features at a time and get feedback before you polish them. It takes hours of focused work to code or design a small set of mechanics. But only a few minutes for your peers to ensure that your work is going in the right direction. So if you haven’t already, shorten that loop!

9. Use analytics early

Regardless of how many testers you have at hand, including yourself, you can track all sorts of useful data with an analytics API. How many times did any tester fail on a given level? How many got through a given challenge? Those simple pieces of information give you a sense of how well you balanced your game. They are hard to track by hand. Yet, they are especially useful on the early stages of a project. And they stay relevant during your beta test sessions… And even after the game’s release!

A tool like GameAnalytics will track and plot all of that data for you. If you’re using unity, the SDK is even available as a convenient package to load into your favorite IDE.

10. Work with efficient tools

Some IDEs are more efficient than others when it comes to prototyping. Until now, for 2d prototypes, my tool of choice has been the HTML 5 IDE construct 2. On any given project, within 1 to 2 hours, I can have a simple yet precise working prototype with it. Because it’s HTML 5, it gives me the ability to forward the game to a remote teammate for feedback extremely fast.

The actual developers of the corresponding game can pick any other engine to code the final product. Obviously, within a fixed team, it is ideal to all work with a common set of tools. As you certainly know, a tool like Unity is great for both prototyping and long term work. A perfect fit if you are going for native games. If you’re a lone game designer or a freelancer like me, technologies like HTML 5 or Haxe are great for rapid prototyping as well.

11. Use placeholder content

The early pre-production phase is no time to fiddle with unnecessary details. It is unlikely that the early prototypes will be kept as they are. They are often dumped because they are proof of concepts more so than solid bases for a product. At that stage of a project, you shouldn’t hesitate to use dirty tricks and other placeholder assets and snippets of code. The only thing that matters, as far as a game concept is concerned, is that you find the right design direction. And it does take some trial and error to get there.

Those last notes may seem basic to some of you. But trying to stay efficient across the board does require a shift of mind. I see it often enough: using and reusing placeholder content is not natural or intuitive to all fellow professionals.

Summary

Overall, this list can be summed up in 3 general points:

1. Use and abuse prototypes
2. Write and code with your teammates in mind
3. And don’t neglect the clarity of your presentation

Is there any tips or advice you would like to share with everyone? Did we miss anything essential? Let us know on twitter or Facebook!