今天我们要讨论的是一个甚为重要但经常被人忽视的话题。多数电子游戏开发指导和教程都没有承认沟通在游戏开发技能中的地位。(请点击此处阅读本文第2篇）

知道如何开口和有效写作与知道如何编程、使用Photoshop、遵守设计流程、创建关卡、作曲或者准备音频一样重要。这些都是某人在准备好将沟通这种技能呈现给团队之前所需要学习的技术，需要掌握的概念，以及需要完成的练习。

comunication-skill(from utm.my)

游戏开发者尤其如此

当然，世上人人都需要沟能，并且可以从中获得更多益处。但我们为何专挑游戏开发者来讲？

我并不是说只有游戏开发者才存在沟通问题。但根据过去十年与数百名计算机科学系的学生、独立开发者以及专业软件工程师打交道的经验，我可以说我所遇到的游戏开发者普遍存在一个特定的沟通问题。这也是我们所面临的一个特殊问题，因为这并不单关系到一天的工作是否顺利，我们的沟通能力还会对我们是否能够合作甚至是独立完成工作产生实实在在的影响。游戏开发者通常为自己的工作而兴奋，但无论是因为技术局限性还是因为沟通局限性而导致某些很棒的功能无法实现，那都会让游戏遭殃。

分清工作职责

如果程序员负责编程，设计师做设计，美术人员做美工，音频能力制音频，这里会有相同的沟通角色吗？

当然，甚至还有好几个。

制作人。即使是在小型业余爱好者或学生团队中，这通常也会由其他角色所包揽，制作人专注于团队人员之间，以及团队成员与外界的沟通问题。有时候这项工作会被误解为分配安排，但要制定这种分配计划则需要大量的交流和邮件往来，以及让所有人都处于同一轨道的持续沟通。

设计师。设计师在游戏开发过程中的角色之一就是通过游戏与玩家沟通。指出游戏目标是什么，哪些内容会对玩家受害或者受益，玩家下一步应该去哪里，从而传达游戏的内部状态信息——这对游戏设计的影响远大于编程。根据游戏团队的技能组合情况，某些情况下设计师与游戏的直接工作就是关卡布局或数值调整，如果大家的工作互有交集，设计师与程序员、美术人员及其他人员的沟通交流更为重要了。在一个人担任多个角色的小型团队中，沟通就成了让其他人知道游戏状况的一个必要环节。

主管。在一个拥有主管的大型团队中（常见于专业团队），主程序员，主设计师或主美术师还得具有出类拔萃的沟通才能。这些人并不一定需要是最出色的程序员、设计师或美术师——虽然他们当然需要具有这方面技能，但他们是因为能够有效领导他人而身居高位，而这又涉及所有方向的大量沟通：与上级、下级之间的沟通，甚至协调上下级和他人之间的沟通。

文案：并非所有游戏题材都需要文案，但对于那些需要写作内容的游戏来说，沟通就显得更为重要了。与那些并不身兼程序员一职的设计师相似的是，除了一些实际对话或其他游戏内置和插页文本之外，团队中的文案通常并不直接创造多数内容或功能。会写一些东西并不能算是称职的文案，文案和内容创造者还应该同他人频繁交流，以确保执行效果与自己所想象的世界完美融合。

非开发角色。这一切只考虑到了开发过程中的团队内部交流。学习如何与测试人员、玩家或者项目消费者和潜在新雇员（这里甚至还忽略了投资者和财务专业人员）更好地交流，则是另外一个巨大的挑战，如果团队规模够大的话，你还得同人机互动专家、营销专家、PR人员以及HR员式沟通。如果你是一名业余爱好者，学生或独立开发者，你就得自己扮演好这所有的角色。

我们通常遇到的沟通问题有两种。虽然它们看起来好像是两个极端，但实际上这两者之间并没有看上去那样泾渭分明。在特定情况下，其中一者甚至可能从另一者演变而来。

Interpersonal-Communication(from onetechgeek.com)

挑战1：羞怯

首个问题就是我们有些人比较害羞。我所遇到的一些极具天份的程序员、设计师、美术人员和作曲家就是害羞的人。这实际上会限制他们的创作——如果他们无法大声说出自己的想法，就可能给游戏、团队或者公司造成损失。

不幸的是，我们很容易为害羞找到借口。毕竟，这些有才华而害羞的人之所以能够发展自己的专长，就是因为他们能够远离喧嚣，独善其身地修炼自身本领。但遗憾的是，这种想法不利于帮助他们和团队从中获益。

团队成员之间的交流在游戏开发过程中的作用不容小觑。有时候你得在3D Studio Max上完成工作，有时候又需要拿出来大家一起讨论才可能完成工作。

我发现害羞的另一个因素在于，人们知道自己所在领域的出色之处，他们总能看到自己的工作要达到自己的预期，还有很大改进空间。

一个人在所在领域的人群中处于什么地位并不重要，重要的是项目中的开发者比其他人更清楚其中的不同之处。由于大家的专长、兴趣和背景各有不同，所以这就难免会成为一个问题。

挑战2：避免争执

有时候害羞看似由于过去不太成功的互动而形成的过度补偿。有人想开口来分享自己的想法，补充他人的观点，但却遇到了伤害，也没有取得什么成果。参与讨论容易让人们激动和生怒，所以有名开发者在一次无谓的挣扎之后终于放弃了。也许他们觉得自己的想法并没有得到合理的接受，甚至它根本就不值得自己卷入这种麻烦中。

我的一名大学导师曾经向我指出：“Chris，有时候人们挑战你的观点时，他们并不是真的在否定你的说法。他们只是不认同你的表达方式！如果你用不同的方法说法同样的观点，可能他们就会支持了。”

他说的完全正确。我听到这种说法后，除了突然让自己住嘴，也开始发现其他人也存在这种情况。会议、合作型课堂项目，甚至是人们的日常交流都会产生冲突，那些心地善良，无意冒犯他人之人，确实总体上会认同双方的目标和观点，而普通人无意识的敌意升级却经常引起事与愿违的反复争执。

造成这种问题的原因和行为模式有不少。在10年的研究之后，我开始更理解这一点，这种情况仍然时有发生，它仍然是我必须积极应对的情况。

这就不难理解人们在感觉自己融入团队就是麻烦的起源之前究竟遭遇过多少次这种情况。这种情况的结果就是回避，降低自己在对话中的个人投入，并服从人们在讨论中所达成的一些行动项目。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Communication is a Game Development Skill (Part 1 of 2)

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.（source：hobbygamedev）