团队合作

爱你们的游戏

团队合作成功的秘密是爱,团队爱他们正在做的游戏。尽管如此,还是有一些问题:

  1. 不喜欢游戏的人员。尽管文中给出的答案是让这些人离开团队,但一方面你很可能没有权利让这些人离开。另一方面,人是会变的,一个曾经非常喜欢玩游戏的人可能某一天就不喜欢玩游戏了,但他对游戏的洞察力和经验仍然可以支持他继续做好一款游戏。讽刺的是,游戏设计师很可能会成为这一类人,因为他们可能会发现市面上的游戏在他们眼里看来就是一堆熟悉的机制和设计,不到一天就能摸透一款游戏。但事实上这并不会妨碍他们设计出大众喜欢玩的好游戏。
  2. 团队成员喜欢其他类型的游戏而非正在制作的。这个比较难办,你可以帮他们发现他们现在做的游戏他们喜欢的部分,然后鼓励他们。但同时我觉得这个问题很可能是「成长心态」和「寻找心态」的问题。「寻找心态」的人会不断放弃现有的然后尝试寻找更完美的,而「成长心态」的人则会培养现有的,如果自己遇到了这个问题,试着用成长心态面对现在的游戏。
  3. 团队成员对游戏有不同的愿景。这个才是最普遍最困难的问题。解决方法只有沟通!沟通!沟通!不要在团队里面用民主做决策,试着说服每一个人都同意,发自内心的同意。

如果真的不爱了

作为设计者你的目的是让别人喜欢你的游戏。如果你自己不喜欢的话,有三个办法:

  1. 找到一个游戏当中你喜欢或兴奋或自豪的部分,然后拾起信心为整个项目努力。
  2. 喜爱你的玩家,想象自己把游戏作为礼物送给他们,想象他们高兴的那一刻。
  3. 如果前两条都没有用,那么你只能假装了,当我们假装去喜欢的时候,神奇的事情会发生,你会慢慢真的喜欢上它。另外,积极心理学告诉我们,当你不开心的时候,假装很开心,你会真的开心起来的。

一起设计

在设计过程中让整个团队都参与进来,你可以获得很多角度很多想法,你的团队的每一个人也感到他们是设计的一部分。一个方法是不要做过于精细的设计,开发人员们会有自己对于优美的细节决策的能力,他们的直觉往往非常好。

当然并不是说所有人一直参与设计,你可以根据成员们对于特定环节的兴趣和能力对不同环节分别建立核心设计队伍。当这个核心设计队伍决定了设计应该是怎么样之后,让其他人知道。过程如下:

  1. 头脑风暴:让尽可能多的人参与进来。
  2. 独立设计:核心设计队伍成员独立思考。
  3. 设计讨论:核心队伍把他们的想法拿到一起讨论,并决定哪些想法可行?
  4. 设计展示:核心队伍向其余成员展示他们的进度,然后其他成员批评建议,通常会变成头脑风暴的再循环。

团队沟通

游戏团队的沟通主要有下面9个关键问题:

  1. 目标。把设计思路集中在如何解决问题上面,对思路的个人偏好比如用「我的想法」「XX 的想法」并不重要,重要的是能否解决问题。用比如「太空船的想法」这样的客观描述。这种方式更清晰,而且把想法和人分离来来更容易客观地评价这些想法。另一个技巧是用「如果我们选择 B 而不是 A 会怎么样」这种疑问句的方式代替「我喜欢 B,不喜欢 A」这样的判断。也能让成员把注意力集中在客观判断上面。
  2. 清晰性。当你觉得有人说的不清晰的时候,不管有多尴尬,都要继续问不清楚的地方。第二,当你跟别人沟通的时候,用「周四下午5点前我会给你3-5页的邮件来说明这个轮盘制的战斗界面」明显比「我在周四前设计出战斗系统」有更少的歧义和更多的细节。
  3. 一致性。首先,应该用简洁直观,并且每个人都可以方便取阅的形式记录下这些东西。可以用软件、网站、打印出来的文档等。
  4. 舒适性。保证开会的地方,有舒服,安静的环境,足够多的椅子,同时有水有吃的。
  5. 尊重。保持礼貌和耐心,学习「非暴力沟通」,经常跟自己说「如果我错了呢?」。
  6. 信任。你可以看谁和谁一起吃饭,如果艺术人员和开发人员分开吃饭,可能团队有沟通问题,如果 Xbox 组和 Playstation 组分开吃饭,可能有移植问题。用开放的办公室让成员面对面交流。
  7. 诚实。舒适以尊重为基础,尊重以信任为基础,信任以诚实为基础。坦诚面对别人,即使在游戏设计之外。
  8. 隐私。如果有机会和团队的每个人单独谈一谈,有时候人们会因为觉得不适合公开讨论,而把问题藏着,一对一谈话有助于建立信任从而形成良性循环。
  9. 统一。每个对立的观点都有至少包括了两个人,尊重他们,向他们解释重要性。如果这样还失败,问他们「怎样才能让你接受呢?」。尽管解决分歧是痛苦而漫长的,但决不能无视分歧。

文档

首先,游戏文档没有神奇模板或者合适的格式。文档的目的是记录和交流。很少有游戏是一个文档就能满足所有目的的,通常需要建立几种不同的文档。

document_type.png

  1. 游戏设计总览。设计师为管理层所写,让他们理解游戏是什么,为谁做的,也可以帮助整个团队理解游戏的总体概况。
  2. 详细的设计文档。用大量细节描述游戏内部所有机制和界面。设计师用来记录想法、细节、并帮助代码和美术完成他们的工作。这本文档通常是最厚的,尽量保持更新到最新状态。
  3. 故事概览。很多游戏用专业作家来创作对话和帮白,这些作家并不常和游戏谁团队呆在一起,所以需要一本额外的文档来告诉作家环境、人物和动作。
  4. 技术设计文档。通常技术组之外的人并不需要关心这些技术实现的细节,但当技术组不止一个程序员的时候,最好保持更新这本文档。
  5. Pipeline 概述。这本是程序写给美术看的,包含了整个游戏的实现流程的概述,尽量简单到美术只需要提出很多可以不可以的回答就好。
  6. 系统限制。设计者和美术通常不知道他们设计的系统有什么是能做,有什么是不能做的,程序可以把系统的极限,比如多边形的数量上限等告诉设计和美术,同时可以就此讨论如何突破系统限制。
  7. 艺术圣经。这是美术内部的事情,如果有多个人负责美术,那么最好有一本文档来统一人物形象,环境,色彩,界面等。
  8. 艺术总览。这是艺术反馈给设计的文档,主要包含早期图像,游戏外观等需要其他组员知道的部分。
  9. 游戏预算。开发游戏的成本,包括各项工作需要的时间和金钱。这部分是管理团队和其他各个团队讨论出来的结果,并不是管理团队内部拍脑袋的出来的结果。这部分预算用于去拿投资。
  10. 项目日程。设计充满不确定性,这文档也需要列出「所有需要完成的任务」「任务所需时间」「任务截止期限」「谁负责任务」还要考虑到「每人每周40小时工作时间」「任务间的依赖关系」保持这个文档至少每周更新。
  11. 故事圣经。故事并不是作家一个人的,设计、艺术、技术甚至玩家反馈都可以提供有趣的故事,把这些集成为一本故事圣经吧。这部分文档可以和「故事概览」合并更新。
  12. 脚本。由作家完成的对话旁白脚本,设计师需要审阅这些内容,以确认没有和游戏规则不符合的地方。
  13. 游戏教程、手册。这部分最好由设计师负责。这部分必须测试,以确保玩家理解的规则和设计师想的一样。不过现在的视频游戏反而很少有书面的教程和手册了,但游戏开发初期,还在纸上原型的时候,还是需要有这样一份手册的。
  14. 游戏测评。并不是只有团队才可以写文档,玩家一样可以写测评,不过这时候通常已经没有时间修改游戏了。不过在前期测试游戏的时候,玩家的反馈有必要记录下来。可以合并到详细的设计文档里面。

总结


lens #88 爱:询问自己如下问题:

  1. 我喜欢我的项目吗?
  2. 团队里每个人都喜欢整个项目吗?如果不喜欢,怎么办?

lens #89 团队:为了让你的团队齐心协力:

  1. 这个团队适合这个项目吗?
  2. 这个团队沟通的时候客观吗?
  3. 这个团队沟通的时候清晰吗?
  4. 这个团队成员间相处舒服吗?
  5. 这个团队成员间有相互尊重和信任吗?
  6. 这个团队最终意见统一吗?

lens #90 文档:询问自己如下问题:

  1. 有哪些东西是需要记载的?
  2. 有哪些东西是需要交流的?

这篇文章是我读 Jesse Schell 的 The Art of Game Design 的笔记和感悟,本书也有中文译本,名字叫全景探秘游戏设计艺术。接下来的几天,我会陆续发布最后的文章笔记。


都看到这了,留个言,点亮那个 ♡ 让我开心一下吧~~_

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

如何成为一名成功的程序员

编程是一个仅靠兴趣仍不足以抵达成功彼岸的领域。你必须充满激情,并且持之以恒地不断汲取更多有关编程的知识。只是对编程感兴趣还不足以功成名就——众所周知,我们工作起...

752
来自专栏java一日一条

成为架构师的7个关键思考、习惯和经验

本文作者秦迪,微博平台及大数据技术专家,13 年加入微博,负责微博平台通讯系统的设计和研发、微博平台基础工具的开发和维护,并负责微博平台的架构改进工作,在工作中...

422
来自专栏数据的力量

自我导向学习:学习的3个维度

773
来自专栏大数据文摘

程序员界年度人口普查:6成以上开发者日工作超9小时,且从不运动

1135
来自专栏非著名程序员

微信小程序背后的套路,其实挺深的

是的,今天微信有更新了,这次的更新反响依旧是很大。其实对于微信一个月活 10 亿的产品来说,一个微小细节的变动,乘以 10 亿这个基数,都是属于变动非常大的,引...

773
来自专栏SDNLAB

别慌!SDN并不强制要求编程能力

从网络管理者的角度来看,软件定义网络(SDN)令人不安的一个方面就是企业网络不会像编程一样受到管理。这让网络管理者充满了担忧,认为多年来他们赖以生存的技能会被编...

3348
来自专栏java一日一条

程序员每天都在使用的6个惊讶的软技能

如果你想要开启作为web开发人员的职业生涯,那么你需要涉及的不仅仅是知道如何写代码。

331
来自专栏Java架构

如何从三流程序员成长为一名年薪50W的架构师?1.源码分析专题2. 分布式专题3.微服务架构专题4.性能优化专题5.工程化专题6.电商项目实战

1433
来自专栏SDNLAB

开源势力正在扩大的五大标志

如果你目前还是觉得开源技术没有专有软件那样可靠,或者是安全性不够的话,我认为你是时候开始学习一下数字革命带来的巨大变化了。在过去的几年里,如 Google、Fa...

2648
来自专栏Java学习网

程序员每天都在使用的6个惊讶的软技能

如果你想要开启作为web开发人员的职业生涯,那么你需要涉及的不仅仅是知道如何写代码。 有一些通用的软技能几乎可用于每个领域——包括技术行业。 成为软件开发人员涉...

2595

扫码关注云+社区