Communication: The Designer's Real Job

The game player just pops in a brand new game. How does he control his avatar? Where is he suppose to go? What does he need to accomplish? Who does he need to defeat? The player needs to be communicated this information or else immersion is lost and frustration starts to fester.

Frustrated unhappy players curse, throw controllers, change games, turn off the machine or drive to the nearest "evil" used games dealer to trade in their game. To avoid those clearly undesirable outcomes the designer needs to communicates to the player. In order to actually communicate to the player, the designer needs his team. He needs programmers to make things work. He needs artists to make things look and sound great.

He needs quality assurance to make sure the player enjoys the experience. He needs production to keep him on schedule. He needs marketing to let the player know about the game. That's a lot of different groups that need to hear different information. Designers need to effectively communicate with the player and the team to make the best game possible.

Communication: The Player

The principle that is applied to communicating with the player:

To understand how considering people are "stupid" helps improve game play, lets first examine stupidity with the following television shows

These shows are filled with examples of people who make poor decisions with their real lives with real consequences. If people make poor decisions in real life with real repercussions that affect their lifestyle, freedom or life itself, how then can we expect players to know what to do or how to behave in a digital world that they are experiencing for the first time? With no repercussions to insure they read the game manual, properly play the tutorial while listening to all the instructions? So game play itself needs to instruct the player.

Two methodologies stem from understanding "stupidity" to improve my skills as a game developer:

In addition to the importance of a good tutorial, any new mechanic introduced during game progression needs to be taught and communicated to the player. If you need new ability "x" to defeat the next boss, then introduce the mechanic before you get to the boss. Design an enemy that can also be defeated using the new mechanic.

This way the player gets practice at using the new abilities and basically taught in a relatively safer environment before relying on the new skill to win or lose versus a boss. Don't just throw a player into a situation to sink or swim. Rather guide them through their experience so they can spend their time playing and enjoying the game instead of trying to figure out what the developers wanted the player to do.

Communication: The Team

The actual means of communication to the player will vary depending on the genre and intentions of game play but include text, dialog, animation, special effects, and sound. Anything that the player can see, hear and feels, with rumble controllers, can be used to convey game play information and mechanics to the player.

So in order to communicate effectively to the player, the designer must first communicate to the rest of the team. A designer communicates with the rest of the team through writing documents, verbal discussions and by listening.

Writing

This has to be my least favorite part of being a game designer. It's much more fun and exciting to brainstorm ideas and put the final tuning of a design.. It's work to commit all ideas into text form only to have to debate, rationalize and rewrite the design documents. However what's said verbally can be forgotten.

A room full of people can all participate in the same meeting and agree to results and an hour later forget the details. What's committed to text form can be re-referenced. Any misunderstanding can lead to wasted man hours. Ripping something apart to only have to rebuild it a different way morale crushing not to mention inefficient and thus costly.

So be as clear as you can and write under the assumption that the reader has no prior or specialized information to help them understand the document. Basically write the document for the suits in the industry that don't really know or understand the ins and outs of design or game development. It's a fine line of providing enough information to be useful without getting into intricate details that overwhelms the reader. 

Discussion

Not every discussion needs to take place in a meeting on an official basis. Sometimes taking the time to have a 5 minute chat in person can save days and weeks worth of work. Understanding basic ideas isn't enough when it comes to implementation of a design and the effect of lost man hours. A programmer or artist may read the design and understand the basic principle.

However they may not understand the design inside and out and therefore may execute the task "incorrectly" due to misunderstandings. So it's a mistake to leave the other departments alone until their tasks are finished. Simply stopping by their desk and asking if they need anything, have any questions or would like any feedback before they steer too far off course.

Listening

Simply listening to other opinions and ideas goes a long way in the team trusting the decisions the designer makes. If I'm willing to listen to game play ideas and critiques from the other departments and from different levels of experience then the team understands and gains confidence that the decisions I make are well thought out and not knee jerk reactions.

Although an idea as first presented won't work, its still a new way of looking at a problem, or an outside the box solution. Make adjustments to the idea to get it to either feasible or to align it to the direction of the game play vision and target audience. That's the strength of working in a team environment. Collaborative solutions or game play mechanics that couldn't be conceived by the lone individual. The point is every idea can have value but you won't ever get there if you never listen.. 

Two reasons why ideas never make it into game play:

So listening to an idea give feedback and critique what was good about it, and then explain why it doesn't work or fit into current development plans. Taking the time to listen builds up team confidence and morale. Developers don't want to feel like their nameless cogs in a machine that needs to blindly follow orders from above. Instead we're passionate and creative individuals filled with our own ideas about what makes a game successful and fun and being able to express themselves can keep morale and productivity positive.

Everything in Moderation

On the flip side, communicating more doesn't equate to communicating more effectively. If the player feels like you're holding their hands too much and provide too much information, it breaks their immersion and overwhelms them detracting them from enjoying the game. On the same token, your team doesn't need you watching over their shoulder every second of the day to make sure everything is done right. As a designer you want to communicate but not to unrealistic proportions that it takes away the fun in playing and developing games.

The second pillar of my fundamental truths in game development is Communication. Without gamers there would be no games industry. Proper communication to the player is vital for understanding and enjoyment.

Games can't be made without a team. So making sure the team knows the vision allows them to properly do their jobs. Thus stressing the importance of communication to the player and to the team is essential for most effective results. It's a soft skill that plays a bigger role in the success of game development.I want to make the best games I can make. Thus making communication my real job.