When to stop preparing design and get to work?

Originally published on Games Architecture blog.

In indie game development, roles in a team aren't as purely diverse as they are in bigger studios. In a crew composed of several people most of them are probably doing more than one thing. When you're working alone, this is unavoidable. I noticed that the role that is the most often distributed over the team members is designer. The general underestimation of that function may be the reason. The designer's profile is often reduced to the 'idea-guy.' Most of us have many excellent ideas, so what's the point in having a designer, right? Whether your crew has a designer or not, you probably have some kind of design document or game vision that you and your partners share. Or you may think that everyone has the same image of the project, while the truth may be quite different. On the second hand, you all may be very insightful designers, that have an accurate design document, but it may be just a waste of your time and effort. The 90% of it may be just rubbish. Yes, that's a bit harsh, but I'm not telling you that IT SURELY IS trash. I'll just try to explain how can you find out without so much work being wasted.

How can a lack of a design document be dangerous?

Let's start with a more typical case. If you don't have ANY design document and a whole vision is in your head, you can't share it with the other people in a 'healthy' way. You can try, but it seems almost impossible to remember all the details and keep track of them while you're working on the game. Too many ideas pop out and mix during the development time. Your and your peer's visions will go different ways at one point. It may cause wasting time when you need to explain it to them over and over. It may also lead to conflicts, as your team pursued different game than you did.

In my opinion, having the document is important even if you're a lone wolf. First, because if you make a change in the document, you can immediately read through the other dependent sections and think if the change makes sense for the other aspects of the game. The second reason is that it is much easier to write down tasks on Trello or Jira and prioritize them if you've got a well-constructed document. I'll explain what I mean by 'well-constructed document' in a moment.

How can too much of a design be harmful?

Here I'm assuming that you're NOT working on 1 to 1 clone of some other game because in this case all their mechanics are defined, and a symbiosis between them is already tested. When you're working on a new (at least not-a-clone) idea, you can rarely be sure that all aspects of it fit each other before you actually play it. We're living in an era of unselfconscious design, which means that we lack the tools that will allow us to prepare a whole design before development. For now, design and development go together till the end (well, to be accurate, the design usually starts a bit sooner). You probably already feel why too much design can harm you, but let’s say it out loud. Too much design is likely to be a waste of time and effort because non-fundamental decisions are based on a core that hasn't been examined yet. If you'll make a playable demo at some point and you see that your main mechanics are just not fun, you don't want to have many hours spent on designing behind you.

For every game concept the margin of 'too much design' may be placed somewhere else. For example, if you're making an 'FPS with a jetpack' you can probably start to implement FPS mechanics right now as they are pretty the same for the whole genre and have been tested many times. In the meantime, you can prepare a design for the jetpack. How high it should fly (to the sky, buh-bye), what its velocity should be, and how strong inertia it should have? Does it need a fuel? You've got the point. And then you can think of a level design already because it strongly depends on the jetpack's capabilities. After that, you can go to the enemies' project, because their behavior depends on the jetpack and level design. Go to the next layer of design, if the underlying one has been well thought out.

Time for the answers!

I mentioned a well-constructed design document and layers of design. Let's start with the second one. I believe that the design has layers, just like an onion. The most crucial and fundamental mechanics are placed in its center. The ideas that are directly based on them surround the onion's core. The further we go, the less significant design decisions we make. The main menu layout or the font family cannot be totally dumped of course, but they are by far less important than your core mechanics. Maybe they're the least important in the whole project? In that case, those are the onion's shell.

Note, that design layers depend entirely on a particular game. Sometimes even the Audio may be the core.

And now, knowing that, let's answer the question 'What a well-constructed design document means?' For me, it means that the beginning of the paper is the onion's center. It explains fundamentals of your game. Further, you can read about these fundamentals' details and later about mechanics that are based on these pillars. What do you get by constructing the document this way?

First, the reader (teammate, publisher, future-you) has a much easier time trying to understand the vision because it goes from fundamentals to less relevant details that only support primary mechanics. The next thing (but not less important) is when you're changing something on the very top of the design, you must go through all of the following sections and rethink them. You have just shaken the pillars, so you should check if the rest of the vision didn't fall down. The further part of the design you're tweaking the potentially less you have to check because the fewer decisions are based on that changed detail.

And you'll make changes to make your game entertaining. Even if you've got the most beautiful art style, if the whole game is just not fun, "the loser is you."

Knowing all of this, let's answer the question in the title.

'When to stop preparing design and get to work?' or on the other hand, 'How much design do you need, before you can start?' If your core mechanics are based on a universal concept (input and movement in FPS, point 'n' click, real-time strategy, etc.), preparing a design document is not necessary before starting implementation. Instead, you can do them in parallel. The first most important mechanics, that is not that common, require design. You can go layer by layer in design-develop-test iterations. And you can do as many iterations within one layer as you need, to make sure that the current layer is solid and fun. With each iteration, you can do more and more design before starting to implement (but you don't have to, though, as coding is fun after all). Why? Because the closer to the outer shell of our onion-game you are, the weaker dependencies between mechanics become. The main menu and font are less dependant on each other than player's movement and level's structure. Plan and design every non-obvious idea before implementing and don't go through design layers in one iteration.

[DLC] 2 more tips to the design document

As an introduction sections to the paper you may consider two things:

1. First page(s) may be filled with your game's inspirations. Try to explain how your game's mechanics are similar to the existing and well-known titles. Try to put screenshots that show the similarities.

Example:

'I took a camera perspective from the Mass Effect: Andromeda [screenshot] (it's a good game!) Instead of traditional weapons, there will be weapons like in the Worms series [screenshot]. Players will have to cooperate in fighting AI enemies and building fortifications, like in the Call of Duty: Zombies [screenshot]. The building aspect will be taken from the Minecraft [screenshot].' It's just a few sentences, but you can immediately imagine a final and non-trivial product. Sure you can put more examples of a game to one mechanics there!

2. After that you can prepare FAKE player's and magazine's reviews you wish to read and hear about your game. It will tell the reader what the essence of your game is, and what the design document should pursue.

Examples:

"The story is incredible! Deep, real and heart-warming."
"This is the fastest racing game I ever played. Online matches are intense and spectacular!"
"It's like playing a mix of Assassin's Creed and Thief. The freedom of the AC, sneaking's tension of the Thief.”

That's it. The article is based on nowadays' uncertainty of design, personal experiences and lessons learned from them. What do you think about it? Do you have your own workflow or pieces of advice you want to share? Write a comment!

It may interest you as well: