Understanding Bad Habits in Game Design

We all have and share bad habits. They are a part of everyday life and as a result they will develop in our line work whether we like it or not. How do we define a bad habit?

For our purposes we will say that bad habits are negative routines of behavior that are repeated regularly and tend to occur subconsciously. Habituation is an extremely simple form of learning that can sometimes be compulsory.  Habitual behavior often goes unnoticed in persons exhibiting it, because a person does not need to engage in self-analysis when undertaking routine tasks.

Notice the last part of this definition “routine tasks”. If you think about it, game development is measured in recurring cycles and processes, so it is no surprise that there exist bad design habits.  But how do we define bad design habits? The answer can be as difficult as defining what a game designer does?

Well for our purposes we will say that a game design is the process of designing the content and rules of a game. The term “content” can be anything from sound, to levels, to dialog etc. Thus instead of referring to any specific job description we’ll look for those “unnoticed behaviors” that can be specific to a majority.  It is very likely that some of the items listed may apply to other creative disciplines outside of games.

The following unsorted list of bad habits focuses on mainly Game Design. It was compiled from the feedback of experienced designers as well as from other sources cited at the end of this document.  It is my hope that presenting such a list can help generate discussion and debate as well as new understanding.

 

Bad Design Habits (unsorted):

1. Unwillingness to let go

I have heard this issue come up in many ways. Its driving motivator is not limited to a single individual. Over all it can be hard to determine when a feature needs more time or when it needs to be removed.  The challenge may line in the fact that successes and errors in design can be equally driven by the excitement for our own work.

Tom Cadwell (design director Riot Games) described this as the “Too Awesome to cut” pitfall.  He believes that risk assessment can be a powerful tool in helping make this determination.  On a personal level a designer should understand that, for whatever reason, not all ideas, be them good or bad, will make it into the final product and that it is not a reflection on their ability to be creative.

2. Not planning the scope of a design

Failing to scope the design properly from the beginning will lead into many issues during production that can affect quality and the ability to complete the game. The contributing factor is that determining scope can be time intensive, error prone and becomes more challenging when there is no available data to measure against.

If the design is kept modular the team members can iterate on mini-milestones that can confirm or deny scheduling assumptions in pre-production. It is important to understand that measuring the expected time or cost for any task can be done in a macro or micro level and applies to all design tasks and is not job specific to design leads.

3.  Designing a House of Cards

For whatever reason there will always be need in production to cut something out of the design. Our designs should have flexibility to account for change without falling to pieces. Identifying the risks and scalable options for your design will require effort.

If you are designing a system that has very little room for alteration or is integral to completing the game then this system should be agreed on by team consensus so that it receives the appropriate amount of attention.  The bad practice is working in too many critical interdependencies which are not visible to the team.

4. Not being Critical enough or Being Too Critical

It can be very easy to settle on something that works well enough for a tasks but does not have the right elements to make it memorable. Self criticism is a two edge sword and it is as easy to go with consensus at times as it is to become get stuck on a single item.

Be wary of not being critical enough when time is a constraint and you would rather move on than spend more time on a design.  Faster is not always better.

On the other side of the spectrum, it is easy to be overly critical of work, especially in its early stages.  Beware that excessive criticism can devote too much effort in one area of the design while neglecting others. Try to keep an open mind to new ideas, particularly when the risk is low. If the design satisfies its intended goals set a time to come back to it when it can be more objectively compared to the most updated content.

Whether it is too much or too little criticism, if one is too close to the material to be objective it is best to ask for help and fresh set of eyes (ears or user-tester).

5. Forgetting your Design goals

Design goals are the beacon that steers our design decisions and in the chaos of development it is very easy to lose sight of them.

Always establish and refer to your design goals when you begin a task. Keep them close where they can be readily available. Discuss design goals with the team so that they too can be aware of them during reviews and presentations. If any particular goal has to change, perhaps as a result of testing, be sure to update the team and to review your previous work.

6. Designing the game for yourself instead of the target audience

This is a very common mistake that perhaps can be tied to design goals combined with our sense of ownership. The difference is that, when we design for ourselves, our design goals are less likely to align with the intended audience. The only exception is when we are the intended audience and even then it is tricky to accommodate play stiles.

The root of the issue is that creating a game play experience can be a complex task.  Objectivity in final tuning it’s very difficult to maintain because the way we perceive the content we make is inherently biased and different from the end user.

The way to correct this habit is to get a better understanding of how the game is experienced by the target audience. Focus testing, discussion boards, QA interactions and peer reviews can be good sources to use.

7. Not playing, reviewing or researching competing products

Understanding one’s competition or other games in the genre is an important task that should not be neglected. Sometimes this research can be viewed as expensive, immeasurable or as an unnecessary or undesirable chore. Creating guidelines for researching and reviewing products in genre helps create achievable research goals. It also helps us avoid other bad habits such as designing the game for ourselves.

8. Forgetting the Tutorials/Introductions

The tutorial or introductory section of a game will be the player’s first impression of the game-play mechanics and content.  The outcome of this experience is one that directly affects the player’s ability to experience and contrast the remaining content.  

These introductions do not all happen in one place and will recur as more functionality and content change over game-play time.  Introducing the player to new worlds (also story, graphics and sounds) requires us to design for our audience and requires us to design in a more deliberate manner.

For this reason tutorials/introductions can be perceived as unwieldy or stressful and their design is then avoided or neglected. To avoid this issue it is important that tutorials/introductions maintain a significant priority status during production. 

If tutorials are constantly missed during the planning phase then the issue is not necessarily a bad habit but a side effect of lacking a key requirement during preproduction.

9. Over Designing

There is a point in every designer’s life where a good design will be misunderstood for a feature-filled design. The problem is that it can be hard to determine when one must add to, subtract from or outright remove a game feature.  Research, peer reviews, design goal listing and prototyping should help designers peel away at unnecessary layers and get to the core “fun” aspects of their design.

Remember that Designs have a tendency to grow in complexity on their own. This is especially true when other disciplines ask for features to enhance the way they will contribute to completing feature.

Adding more features in the beginning is not guaranteed to correct issues in a game-play mechanic. If anything it only guarantees it will cost more time to produce a prototype.  The core purpose of your design should strive to be as easy to convey as possible. A friend of mine told me once: “If you can’t explain how something works in 2 sentences it's too complex”. I find this to be a good guiding principle to strive for.

10. Dense Documentation

Writing dense documentation or lists that is challenging to read or parse is both a bad habit as well as a rookie mistake.  The amount of documentation that goes into games is massive and keeping it readable can be tedious at times.  As feature lists grow or change it can become a real feat to stay up to date with the documentation.

When trying to make documentation leaner I find it helpful to use graphs, lists and sketches. Modularity will also help with this problem, specifically understanding the various audiences that use your documents. The specifications for a feature can be broken down or labeled in a way that makes it easier for specific parties (programmers, artist and clients) to locate, comment or edit the information they are looking for.

As you break down the description into smaller chunks make sure that readers can easily find your design goals (or feature requirements) to help them understand how it fits into the final product.

11. Focus testing for focus testing sake

It is a bad practice when focus testing and its results are either:

It is very important for development teams to regularly focus test their game with its intended audience. It should not be forgotten that the goal of focus testing is to understand and document how specific audiences perceive and play the game. Ideally the results from testing should be acted upon to produce a more polished end product.

12.  Underestimating your target audience

Different people will experience your game in different ways.  Do not assume that a tester who doesn't understand your feature is “dumb” or that a tester who can't do something is just “bad at games”.  Their limitations shed light into the accessibility of your product. 

The main take away is to not underestimate the data.  Renowned usability consultant, Dr. Jakob Neilsen believes that statistically the first 5 users out of 15 will be able to find 85% of your usability problems. Personally it always hurts when a feature is not received or understood well but it is important not to let pride get in the way of being objective.

13.  Designing in a Vacuum

It is bad practice to not include the various disciplines (programming and art) into the design process in other to quickly turn out a feature or content.  The technical and aesthetic goals of other disciplines matter and discussing the issues will help strengthen both the team and overall product. Beware of scheduling a designer into a design task devoid of interdisciplinary input.

Always discuss possible changes to the design with the other members of the team, particularly the Engineering and Art leads, to determine ramifications on other departments. Faster is not always better.

14.  Become addicted to your “researching the source material”

“Research” can become a common excuse, especially when the source material (be it books, games or movies) is very enticing and can be used as a means to procrastinate on other production work.

It can sometimes be hard to tell when to stop consuming and begin producing. Setting research goals and keeping a research journal can help keep one centered.  We all need ways to relieve stress from time to time. Be wary excessive “research” may hurt the work of others or your own standing among your peers.

15.  Avoiding reviews

This will probably be more common in places where there is no set or observed review policy. Reviews do take time to complete and often require rework. Figuring out when and who to involve will vary between tasks and projects.  Late reviews work well for an audience that doesn’t understand the iterative process and may confuse an early prototype with a final product.

Typically your peers should review your work early and often. Tom Cadwell described postponing reviews for too long as the “Grand Unveil” in his list of pitfalls. He encourages framing early review in a positive productive manner and a mistake-forgiving culture. Intentionally avoiding a review for whatever reason can lead to design defects and will affect the quality of the work.

16.  Hide in busy work

Busy work here is defined by repetitive small tasks that could perhaps be automated, delegated or postponed. Some designers may experience great accomplishment if completing this “busy work”.

The risk is that the lack of automation may be in fact setting the overall product back or that the “busy work” serves as a means to procrastinate or avoid tackling an impending task or issue.

When it comes to busy work there is a fine line between being productive and wasting valuable time. Process reviews and time tracking can help point out areas where a designer’s time will be more effective.

17.  Stagnate Design, fear of the unknown or failure

Often a type of design is revisited, reshuffled or copied several times for the purposes of iteration, innovation and polish. It can be tempting to re-cycle the previous work and features not for the benefit of the game (or audience) but rather to avoid dealing with the unexpected.

This issue can be very perceptual and it’s up to the individual, or group of individuals, to self examine the reasoning for the type of over-reliance that can lead to design stagnation. Change can be scary. A technique used when prototyping is to follow the motto “Fail early, fail often”. This will hopefully help your team know f it’s time to re-invent the wheel or not.

18.  Not playing your own game

One would think no one should be too busy to not play their own game but this is not the case.  Time constraints, lack of interest, buggy builds or unpolished quality can make strong arguments to steer clear of one’s own software. This habit can also form over time specially when testing hardware or access is limited.

The solution to developing more discipline in this area can be time management as well as identifying and removing the obstacles that may prevent one from accessing the game.

19.  Design Defensiveness

Being defensive can expand into all aspects of our lives including our work. I find this habit to be one that gets particularly common during peak crunch time. The challenge is that a person does not need to be necessarily stubborn or defensive to develop this habit. Stress and other factors can build up the pride in our work into a wall that can hurt our ability to work together.

The practice of listening and communication techniques can help improve the way we perceive and express information.

20.  Postmortem Neglect and Misuse

Postmortems and critical stage analysis occur at various stages of development in order to bring out good and bad practices within a project.  Tensions can be high during these events and they need to be handled carefully so that they can bring closure and innovation as opposed to animosity and cynicism.

 It is as bad to neglect these self evaluation processes just because they are not convenient. As time passes it will be more difficult to capture people’s recollections of events.  Paper postmortems followed by small group discussions can be useful when the development team is too big or too busy.

Postmortem data will be mostly perceptual and one should avoid using it as the single metric for planning future project. Bug data bases, budget allocations and time tracking tools (such as Personal Software Process) will fill in the details into the issues and assumptions brought up during the discussion.

My thanks to Brandon Sheffield, Dan Tanguay, Leander Hasty, Adrian Earle, Jonathan Mintz, Bret Dunham, Jonathan Russell , Mathew Goldstein, Jon Meschino, Tom Cadwell, Luis Barriga and Eric-Jon Rössel Tairn.