爱你们的游戏
团队合作成功的秘密是爱，团队爱他们正在做的游戏。尽管如此，还是有一些问题：
- 不喜欢游戏的人员。尽管文中给出的答案是让这些人离开团队，但一方面你很可能没有权利让这些人离开。另一方面，人是会变的，一个曾经非常喜欢玩游戏的人可能某一天就不喜欢玩游戏了，但他对游戏的洞察力和经验仍然可以支持他继续做好一款游戏。讽刺的是，游戏设计师很可能会成为这一类人，因为他们可能会发现市面上的游戏在他们眼里看来就是一堆熟悉的机制和设计，不到一天就能摸透一款游戏。但事实上这并不会妨碍他们设计出大众喜欢玩的好游戏。
- 团队成员喜欢其他类型的游戏而非正在制作的。这个比较难办，你可以帮他们发现他们现在做的游戏他们喜欢的部分，然后鼓励他们。但同时我觉得这个问题很可能是「成长心态」和「寻找心态」的问题。「寻找心态」的人会不断放弃现有的然后尝试寻找更完美的，而「成长心态」的人则会培养现有的，如果自己遇到了这个问题，试着用成长心态面对现在的游戏。
- 团队成员对游戏有不同的愿景。这个才是最普遍最困难的问题。解决方法只有沟通！沟通！沟通！不要在团队里面用民主做决策，试着说服每一个人都同意，发自内心的同意。
如果真的不爱了
作为设计者你的目的是让别人喜欢你的游戏。如果你自己不喜欢的话，有三个办法：
- 找到一个游戏当中你喜欢或兴奋或自豪的部分，然后拾起信心为整个项目努力。
- 喜爱你的玩家，想象自己把游戏作为礼物送给他们，想象他们高兴的那一刻。
- 如果前两条都没有用，那么你只能假装了，当我们假装去喜欢的时候，神奇的事情会发生，你会慢慢真的喜欢上它。另外，积极心理学告诉我们，当你不开心的时候，假装很开心，你会真的开心起来的。
一起设计
在设计过程中让整个团队都参与进来，你可以获得很多角度很多想法，你的团队的每一个人也感到他们是设计的一部分。一个方法是不要做过于精细的设计，开发人员们会有自己对于优美的细节决策的能力，他们的直觉往往非常好。
当然并不是说所有人一直参与设计，你可以根据成员们对于特定环节的兴趣和能力对不同环节分别建立核心设计队伍。当这个核心设计队伍决定了设计应该是怎么样之后，让其他人知道。过程如下：
- 头脑风暴：让尽可能多的人参与进来。
- 独立设计：核心设计队伍成员独立思考。
- 设计讨论：核心队伍把他们的想法拿到一起讨论，并决定哪些想法可行？
- 设计展示：核心队伍向其余成员展示他们的进度，然后其他成员批评建议，通常会变成头脑风暴的再循环。
团队沟通
游戏团队的沟通主要有下面9个关键问题：
- 目标。把设计思路集中在如何解决问题上面，对思路的个人偏好比如用「我的想法」「XX 的想法」并不重要，重要的是能否解决问题。用比如「太空船的想法」这样的客观描述。这种方式更清晰，而且把想法和人分离来来更容易客观地评价这些想法。另一个技巧是用「如果我们选择 B 而不是 A 会怎么样」这种疑问句的方式代替「我喜欢 B，不喜欢 A」这样的判断。也能让成员把注意力集中在客观判断上面。
- 清晰性。当你觉得有人说的不清晰的时候，不管有多尴尬，都要继续问不清楚的地方。第二，当你跟别人沟通的时候，用「周四下午5点前我会给你3-5页的邮件来说明这个轮盘制的战斗界面」明显比「我在周四前设计出战斗系统」有更少的歧义和更多的细节。
- 一致性。首先，应该用简洁直观，并且每个人都可以方便取阅的形式记录下这些东西。可以用软件、网站、打印出来的文档等。
- 舒适性。保证开会的地方，有舒服，安静的环境，足够多的椅子，同时有水有吃的。
- 尊重。保持礼貌和耐心，学习「非暴力沟通」，经常跟自己说「如果我错了呢？」。
- 信任。你可以看谁和谁一起吃饭，如果艺术人员和开发人员分开吃饭，可能团队有沟通问题，如果 Xbox 组和 Playstation 组分开吃饭，可能有移植问题。用开放的办公室让成员面对面交流。
- 诚实。舒适以尊重为基础，尊重以信任为基础，信任以诚实为基础。坦诚面对别人，即使在游戏设计之外。
- 隐私。如果有机会和团队的每个人单独谈一谈，有时候人们会因为觉得不适合公开讨论，而把问题藏着，一对一谈话有助于建立信任从而形成良性循环。
- 统一。每个对立的观点都有至少包括了两个人，尊重他们，向他们解释重要性。如果这样还失败，问他们「怎样才能让你接受呢？」。尽管解决分歧是痛苦而漫长的，但决不能无视分歧。
文档
首先，游戏文档没有神奇模板或者合适的格式。文档的目的是记录和交流。很少有游戏是一个文档就能满足所有目的的，通常需要建立几种不同的文档。
document_type.png
- 游戏设计总览。设计师为管理层所写，让他们理解游戏是什么，为谁做的，也可以帮助整个团队理解游戏的总体概况。
- 详细的设计文档。用大量细节描述游戏内部所有机制和界面。设计师用来记录想法、细节、并帮助代码和美术完成他们的工作。这本文档通常是最厚的，尽量保持更新到最新状态。
- 故事概览。很多游戏用专业作家来创作对话和帮白，这些作家并不常和游戏谁团队呆在一起，所以需要一本额外的文档来告诉作家环境、人物和动作。
- 技术设计文档。通常技术组之外的人并不需要关心这些技术实现的细节，但当技术组不止一个程序员的时候，最好保持更新这本文档。
- Pipeline 概述。这本是程序写给美术看的，包含了整个游戏的实现流程的概述，尽量简单到美术只需要提出很多可以不可以的回答就好。
- 系统限制。设计者和美术通常不知道他们设计的系统有什么是能做，有什么是不能做的，程序可以把系统的极限，比如多边形的数量上限等告诉设计和美术，同时可以就此讨论如何突破系统限制。
- 艺术圣经。这是美术内部的事情，如果有多个人负责美术，那么最好有一本文档来统一人物形象，环境，色彩，界面等。
- 艺术总览。这是艺术反馈给设计的文档，主要包含早期图像，游戏外观等需要其他组员知道的部分。
- 游戏预算。开发游戏的成本，包括各项工作需要的时间和金钱。这部分是管理团队和其他各个团队讨论出来的结果，并不是管理团队内部拍脑袋的出来的结果。这部分预算用于去拿投资。
- 项目日程。设计充满不确定性，这文档也需要列出「所有需要完成的任务」「任务所需时间」「任务截止期限」「谁负责任务」还要考虑到「每人每周40小时工作时间」「任务间的依赖关系」保持这个文档至少每周更新。
- 故事圣经。故事并不是作家一个人的，设计、艺术、技术甚至玩家反馈都可以提供有趣的故事，把这些集成为一本故事圣经吧。这部分文档可以和「故事概览」合并更新。
- 脚本。由作家完成的对话旁白脚本，设计师需要审阅这些内容，以确认没有和游戏规则不符合的地方。
- 游戏教程、手册。这部分最好由设计师负责。这部分必须测试，以确保玩家理解的规则和设计师想的一样。不过现在的视频游戏反而很少有书面的教程和手册了，但游戏开发初期，还在纸上原型的时候，还是需要有这样一份手册的。
- 游戏测评。并不是只有团队才可以写文档，玩家一样可以写测评，不过这时候通常已经没有时间修改游戏了。不过在前期测试游戏的时候，玩家的反馈有必要记录下来。可以合并到详细的设计文档里面。
总结
lens #88 爱：询问自己如下问题：
- 我喜欢我的项目吗？
- 团队里每个人都喜欢整个项目吗？如果不喜欢，怎么办？
lens #89 团队：为了让你的团队齐心协力：
- 这个团队适合这个项目吗？
- 这个团队沟通的时候客观吗？
- 这个团队沟通的时候清晰吗？
- 这个团队成员间相处舒服吗？
- 这个团队成员间有相互尊重和信任吗？
- 这个团队最终意见统一吗？
lens #90 文档：询问自己如下问题：
- 有哪些东西是需要记载的？
- 有哪些东西是需要交流的？
这篇文章是我读 Jesse Schell 的 The Art of Game Design 的笔记和感悟，本书也有中文译本，名字叫全景探秘游戏设计艺术。接下来的几天，我会陆续发布最后的文章笔记。
都看到这了，留个言，点亮那个 ♡ 让我开心一下吧~~_
