Today’s subject is an incredibly important one that gets a lot less attention than it should. Most videogame development guides and tutorials fail to acknowledge that communication is a game development skill.
Knowing how to speak and write effectively is right up there alongside knowing how to program, use Photoshop, follow design process, build levels, compose music, or prepare sounds. As with any of those skills there are techniques to learn, concepts to master, and practice to be done before someone’s prepared to bring communication as a valuable skill to a team.
Game Developers Especially
Surely, everyone in the world needs to communicate, and could benefit from doing it better. Why pick out game developers in particular?
“…sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it!”
I don’t meant to claim that only game developers have communications issues. But after spending much of the past ten years around hundreds of computer science students, indie developers, and professional software engineers, I can say that there are particular patterns to the types of communication issues most common among the game developers that I’ve met. This is also an issue of particular interest to us because it’s not just a matter of making the day go smoother; our ability to communicate well has a real impact on the level of work that we’re able to accomplish, collaboratively and even independently. Game developers often get excited about our work, for good reason, but whether a handful of desirable features don’t make it in because of technical limitations or because of communication limitations, either way the game suffers for it the same.
Whose Job is It?
If programmers program, designers design, artists make art, and audio specialists make audio, is there a communication role in the same way?
There absolutely is. There are several, even.
The Producer. Even though on small hobby or student teams this is often wrapped into one of the other roles, the producer focuses on communication between team members, and between team members and the outside world. Sometimes this work gets misunderstood as just scheduling, but for that schedule to get planned and adjusted sensibly requires a great deal of conversations and e-mails, followed by ongoing communications to keep everyone on the same page and on track.
The Designer(s). One way to think about the designer’s role in game development is to communicate with the player through the game. Indicating what’s the goal, what will cause harm or benefit, where the player should or shouldn’t try to go next, expressing the right amount of internal state information – these are matters of a game’s design more so than its programming. Depending on a game team’s skill makeup, in some cases the designer’s only direct work with the game is in level layouts or value tuning, making it even more critical that within the team a designer can communicate well with programmers, artists, and others on the team when and where the work intersects. On a small team when the person mostly responsible for the design is also filling one or more other roles (often the programming) communication then becomes integral to keeping others involved in how the game takes shape.
The Leads. On a team large enough to have leads, which is common for a professional team, the Lead Programmer, Lead Designer, or Lead Artist also have to bring top notch communication skills to the table. Those people aren’t necessary the lead on account of being the best programmer, designer, or artist – though of course they do need to be skilled – they’re in that position because they can also lead others effectively, which involves a ton of communication in all directions: to the people they lead, from the people they lead, even mediating communications between people they lead or the people they lead and others.
Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.
The Writer. Not every game genre involves a writer, but for those that do, communication becomes even more important. Similar to the designer that isn’t also helping as a programmer, a team’s writer typically isn’t directly creating much of the content or functionality, aside perhaps from actual dialog or other in-game and interstitial text. It’s not enough to write some things down and call it a day, the writer and content creators need to be in frequent communication to ensure that satisfactory compromises can be found between implementation realities and the world as ideally envisioned.
Non-Development Roles. And all that’s only thinking about the internal communications on a team during development. Learning how to communicate better with testers, players, or if you’ve got a commercial project your customers and potential new hires (even ignoring investors and finance professionals), is a whole other world of challenges that at a large enough scale get dealt with by separate HCI (Human-Computer Interaction) specialists, marketing experts, PR (public relations) people and HR (Human Resources) employees. If you’re a hobby, student, solo, or indie developer, you’ve got to wear all of these hats, too!
There are two main varieties of communication issues that we tend to encounter. Although they may seem like polar opposites, in reality they’re a lot closer than they appear. In certain circumstances one can even evolve from the other.
Challenge 1: Shyness
The first of these issues is that some of us can be a little too shy. Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.
It’s unfortunately very easy to rationalize shyness. After all, maybe the reason a talented, quiet person was able to develop their talent is because they’ve made an effort to stay out of what they perceive as bickering. Unfortunately this line of thinking is unproductive in helping them and the team benefit more from what they know. Conversation between team members serves a real function in the game’s development, and if it’s going to affect what gets made and how it can’t be dismissed as just banter. Sometimes work needs to get done in 3D Studio Max, and sometimes it needs to get done around a table.
Another factor I’ve found underlying shyness is that a person’s awareness of what’s great in their field can leave their self-confidence with a ding, since they can always see how much improvement their work still needs just to meet their own high expectations. Ira Glass has a great bit on this:
It doesn’t matter though where an individual stands in the whole world of people within their discipline, all that matters is that developers on the project know different things than one another. That’s inevitably always the case since everyone’s strengths, interests, and backgrounds are different.
Challenge 2: Abrasiveness
Sometimes shyness seems to evolve as an overcompensation for unsuccessful past interactions. Someone tried to speak up, to share their idea or input, just to add to someone else’s point and yet it somehow wound up in hurt feelings and no difference in results. Entering into the discussion got people riled up, one too many times, so after one last time throwing hands into the air out of frustration, a developer decides to just stop trying. Maybe they feel that their input wasn’t properly received, or even if it was it simply wasn’t worth the trouble involved.
As one of my mentors in my undergraduate years pointed out to me: “Chris, sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it! If you made the same point differently they might get behind it.”
He was absolutely right. Once I heard that idea, in addition to catching myself doing it, I began to notice it everywhere from others as well. It causes tension in meetings, collaborative classroom projects, even just everyday conversations between people. Well-meaning folks with no intention of being combative, indeed in total overall agreement about both goals and general means, often wind up in counterproductive, circular scuffles arising from an escalation of unintended hostility.
There are causes and patterns of behavior that lead to this problem. After 10 years of working on it, I’ve gotten better about this, but it still happens on occasion, and it’s still something that I have to actively keep ahead of.
It’s understandable how someone could run through this pattern only so many times before feeling like their engaging with the group is the cause of the trouble. This is in turn followed by backing off, toning down their level of personal investment in the dialog, and (often bitterly) following orders from the action items that remain after others get done with the discussion.
Coming in Part 2: Practical Strategies
In either case – shyness or abrasiveness – and in any role on a team, nobody gains from having one less voice of experience, skill, and genuine concern involved. Simply tuning out isn’t doing that person, their team, the game, or the players any real benefit. The issue isn’t the person or their ideas, the issue is just how the communication is performed, and just as with any other skill a person can improve how they communicate.
Failing to figure out a way to overcome these communications challenges can cause the team and developer much more trouble later, since not dealing with a few small problems early on when they’re still small can cause them to grow and erupt later beyond all proportion.
In Part 2 we’ll go over some practical strategies, more considerations, and outside resources that I’ve found helpful in making continual progress toward become a better communicator, and by extension, a happier and more productive videogame developer. My hope is that some of these will speak to some of the challenges that you or your peer developers are up against, too. See you then!
[Update! Part 2 is now posted]
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!