Game design Toolbox – Good and Bad practices

Bad Practice

Designing a new game is such a complex intellectual enterprise that the people involved in it are falling into predictable pits:
-They will think the design is finished,
-They will add details to the parts already well understood,
-They will fail to add all the numbers.
I know I personally fall for all of those regularly, so I am not trying to distribute blame here, but just trying to make us aware of the issues.
Let’s describe each one of those issues in more details:

The Design Is Finished

Since we do not have very good test for design completion, it is a fairly common error and one difficult to evade. Yet we all know than when the game is finished and shipped, we look back at the time we thought the game design was finished and laugh at how much more had to be done.
I suspect that the leading cause of failure at this point is that people have their nose too close to the problem. So a good test for completion is to get others to review the design in details. In part this is what made the technical design reviews successful in the earlier days of EA, it was forcing design issues earlier in the development process.
So, here is the rule, the game design is finished when the game is shipped, not before. Until then the designer has to work and clarify details of the design.

Adding Details To The Well Understood Parts

When choosing between a difficult task and an easy task, most people will choose the easy task (when they are not watched). I see us explaining detailed inner working of parts that are not very important in the game, when sometimes more than half of the game is not understood at all. Why do we do that? Because we can!
So I challenge all the designers to find the largest segment of their game they do not understand and to work on that segment. That’s how you should start your day, every day, until the game is shipped.

You Will Fail To Add The Numbers

I have seen many designs in the past that got killed altogether because the designers had not added all the numbers implied by the design, and did not realize that the game did not fit in any computer on the planet.
And this usually happens when the team is creating some really cool technology that makes everyone feel like the game will be a major hit because no one has ever seen anything like that before. And there is a reason for that: it can’t be done!

So how do we avoid those dangerous pits? We do it by developing confirming experiments. For all the aspects of the game and all the assumptions about how things are done we develop tests that prove that it works. This is should drive a lot of iterations and should be done in a way to reduce the number of moving parts in the design one after another.

Good Practice

Watch What They Do, Not What They Say

Everyone has opinions about everything. In our development environment, everyone has an opinion about how the game should be or behave. This drives people to provide feedback that is not what they have truly experienced.
I think the typical story about this is a focus group run by Sony about the Walkman, they asked groups of young user if they would rather buy a new model in yellow or black. A large majority answered yellow. After the focus group they were given the new Walkman, and could choose between a yellow and black. Most picked up the black model.
Back to game design, this means the designer should monitor what the users in his own team are doing with the game before listening to the feedback. The funny thing is that you can even monitor yourself for changes in behaviors. There was a critical moment in the development of “The Sims” where I started to “Save” the game I was playing. This was the best indication that I was viewing my play time as a meaningful investment in my characters.

In another part of this document below, I go into a little more details about how much of that user tracking is done in coin-op and pinball games.

Lately with the development of online games where we can watch even more what the users are doing, we started to think about a new way to define what users care about. Build a prototype of the game at the roughest level possible and add one extra control in all the components you think might deserve a more detailed control by the user. Just connect that extra control to a counter that memorizes how much the user is using it. Then watch which controls are being most used by the users, that’s where you need to focus and add more controls.

Design Equal Minimalism

Will has a Japanese quote to describe this best. “A Japanese garden is not complete as long as you can remove something”. This applies perfectly to our game designs. Anything that is not reflected and used as an essential part of the game should be removed from the design. Any extra stuff will only confuse the user, add cost to the project. I think that when we see bad games, we can almost always find a lot of badly connected components and elements that make you just wonder why they are so badly done. They are things that just should not be in the game.

Easy to say, tough to do. Especially if that part that you have now figure out should not be in the game has already been implemented at some level in the game. Unfortunately, I do not have a solution for that.

Learning From Young Kids

The cool thing about using kids between 6 and 9 years old to test your products is that they lack experience, and they are not afraid. The combination of the two makes that when you have them test your game, they will magnify a lot of the problems you have in your design. Adults will have a tendency to hide the problems by avoiding them to not look stupid or to be careful to look nice. Kids won’t do that, even though they will always tell you the nicest things about the game.
The younger they are the less sophisticated their filters are, and the easier it is to extract the valuable information.

I have been using my kids a lot, and now that they are growing out of that age range, I’ll sure miss those harsh testers.