11 Tips to Speed Up your Game Design Process

This guide was originally published on the GameAnalytics blog

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 document that would contain every bit of information there is to know about a game. For one, for larger teams, they are too many elements to record and keep track of to have them all compiled in a single document. Then, most 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 preproduction phase of the game. However, there are ways to limit the amount of writing we need to do and to facilitate our teammates’ jobs.

If you are working in a studio already, you’ll have leads to tell you how they want you to work. In this article though, I’d like to give you a list of general tips to design efficiently at the start of a project. It should be of use for your personal projects, your needs as a freelancer, and should work nicely with most studios’ guidelines.

1. A short prototype is worth a thousand words

A design document 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 essence of most game concepts can be developed and tested in little time. Often, it takes about as much time to code 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 a common material to critique and shares ideas 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.

The Ludum Dare gave us quite a few examples of full blown game series born of a very efficient prototype.

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, 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 clients 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. Design documents are meant to facilitate the job of your teammates. Part of your role as a designer is to understand them 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.

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 didn’t understand or if anything could help them in their task. 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 make everybody happy.

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. It is often easier to show that a mechanic or 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 prototype or 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 ideas 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. You should gather all of the raw material, the ideas you need at the start of the day.

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 that craft at least to some extent. But more importantly, this permits you to test your ideas by yourself. It makes you autonomous, more 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 small releases to prove that will have no problem finding work. If you can code, other developers won’t need to translate your documents and iterate based on your inputs anymore. Instead, you will be able to provide them with a playable example showcasing the basic healing balance you are aiming for.

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.

Game designers with strong programming skills are most wanted in the industry. Kudos if you have artistic skills on top of that.

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 ambience. You can also describe systems with easy to read diagrams better than with plaintext.

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 for the early prototypes to be kept as they are, regardless of their quality. They are often dumped because they are proof of concepts more so than products themselves. At that stage of a project, you shouldn’t hesitate to use dirty tricks and other placeholder assets and snippets of code. All 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:

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!

This guide was originally published on the GameAnalytics blog