全局目录

15. 使用 UNITY 开发 VR

By Corey Johnson (Unity Technologies)

（这个人口癖太多，断句瞎断，说话经常说一半就说别的，主语乱换，脑子想到哪里就说到哪里，所以我经常是懵比的）

图15.1

谢谢大家来到我的演讲，『使用Unity开发和优化VR』。

图15.2

我的名字是Gorey Johnson。我在Unity的PM（Product Management）团队，意思就是我的工作室跟……基本上你们所有人，进行谈话，获取你们的反馈，搞清楚你们最需要什么，搞清楚我们可以做什么来让你们受益，并且搞清楚我们的人该干什么来最有效地帮助你们，并对其进行优先级排序。

我在这个行业里已经11年多一点了，我做过很多不同的事情。我差不多在每个系统上尝试过代码，除了音频以外。我喜欢做游戏设计。我专注于Unity的技术领域是：图形、VR、AR和性能领域。

这个是我的email，如果你——我没有放在结尾——如果你想给我发email，请尽管发给我，这个就是我的名@unity3d。

以上就是关于我的一点信息，那么关于你们，你们有多少人用过Unity呢？能不能举个手？（很多手）噢，好的，很好。有多少人正在积极地做VR内容？（也不少）好的，cool。

图15.3

我今天要讲什么？我会讲Unity的VR工作流。我猜在这里（转了个身）。我会讲如何开始，当我们做的时候是在发生什么。我会讲一些设计的东西。我跟很多的VR团队谈过，我们看到了很多共同的东西——我不会非常深入设计，因为大概有17k个VR会议有设计演讲，而我不是那个人——，但是我会指出一些共同的东西。有些会非常明显，比如我们实际看到人们在做的，我们好想把他们锤回家。然后我会谈到优化，我们都知道稳定帧数下的性能非常重要，所以我会谈一谈我们看到大家该做却没有做到的优化。

图15.4

我们先从工作流开始。

好消息，VR工作流跟开发任何的3D Unity程序的工作流是一样的。如果你们已经在使用Unity了，那么你们已经知道如何做VR程序了。

图15.5

唯一的区别，我要指出的唯一一件事就是——我看到很多人第一次接触VR——，你们要确认你们的素材在比例上是1米等于1个单位，这个是Unity认为1个单位在现实世界中的大小。这样你们就不会看到在场景里放去一片面包，但是大小却是一辆BUICK什么的。这是你们在素材商店之类的地方会碰到的一个问题，比如你觉得『哦，我要买这个花，把它放到我的东西里面』，确保你的流程中会检查这个东西的比例，因为有些艺术家会构建一个10米高的花，这样他们就可以控制和保持逼真度了。在一个比例下开发所有内容，确保这个比例是1米对应1个单位。

之后我会谈到我们有VR编辑器，我会在这次演讲结尾的时候讲到它是干什么的。编辑器的工作流，抱歉，VR的工作流会稍微有些改变，我们只好会提到。

图15.6

假设说你想把一个Unity-Chan Dance Party（估计是MikuMiku Uity-Chan Dance吧，四斋蒸鹅心）应用做成VR，你需要做什么呢？我只需要在你的『Player Settings』（播放器设置）里面点击这个按钮：『Virtual Reality Supported』（已支持VR），然后开发、部署、发布就可以了。我知道这里大多数人都开发过游戏，还要做一些东西，之后我们会讲到。

我们尽量让它简单，所以我们只需要你选中复选框就可以。你会看到一个『Virtual Reality SDK』s（VR SDK）的下拉菜单，点击『+』按钮，加入你想要支持的平台就可以了。这个列表会随着你是否在移动端而发生改变，比如Andrioid下会有Daydream和Cardboard选项；在PC上就是上面这些选项。你也可以随时调整这个列表，列表的顺序是怎么样的，我们初始化SDK的顺序也就是怎么样的。在这个例子中，我们会找Oculus，如果没有，它会接着找OpenVR；你可以开发一个比较臃肿的可执行文件同时支持这两个平台并发布，或者你也可以给每个平台开发特定的可执行文件。

图15.7

这个工作流在所有这些合作伙伴平台上都可行，你可以看到这些都是我们已经宣布的合作伙伴，我们在未来还会宣布更多的合作伙伴——我们想要无所不在。意思就是，它（在这些平台）直接就能工作，你只需要勾选复选框，而不需要做别的任何事。你可以直接点击『Play』按钮，只要你有一个——比如PC上的Oculus或是Vive设备，带上头显，摄像头可以被追踪——类似的东西，那么它就能工作。

当然还有一些其它的工作流，比如输入之类的，之后我会谈到这个。

图15.8

对于不在我们的合作平台上工作的人来说，我们也想支持他们。既然你们大多数都是Unity用户，你们应该知道我们的插件和素材包。

这就意味着任何要做VR头显的人，只要他们使用的是OpenVR，那么它就能工作——作为一个被支持的平台。原因就是我们支持OpenVR——也就是SteamVR，我猜我应该指出这点。这就是OpenVR，（回到了图15.6）也就是SteamVR，我们在很多昨天的演讲里听到过了。（回到了图15.8）

这就意味着每个在制作定制硬件的人，他们通常会为你制作一个Unity package，它可以提供给你透镜的正确着色器、双镜头系统的设置、IPD等等他们想要用户设置的东西。它通常都比较繁琐，但是如果你要DIY的话会难很多。

图15.9

一点你点了那个按钮，会提供给你什么选项？在镜头部分，你可以有这么些选项，3个选项，『Stereo Separation』（立体分离）、『Stereo Convergence』（立体收敛性）和『Target Eye』（目标眼睛）。这些是用来干什么的呢？

如果你要设置『Stereo Separation』，那么这个就是你的IPD，Interpupillary Distance（瞳孔间距）。通常你都不需要在这里修改它，大部分平台在都会在用户方面帮你设置，不过如果你想要覆盖掉它，那么你只需要放一些UI，然后用这个覆盖，用户们就可以用这个设置他们的瞳孔间距了。

『Stereo Convergence』在你制作立体3D显示器或者是电视的时候才需要的，所以你们大部分人都不需要做这个，它不是技术上的VR。你只需要知道这个是能深入到显示器表面的深度，那里就是收敛发生的地方。如果你知道这个的意思，你可以用一用；如果你不知道，那你也不需要考虑这个。

『Target Eye』是你们可以用的一个很有趣的东西。默认是双眼，也就是在这个镜头中——镜头位置是玩家的头部位置——你会给双眼渲染，然后就会有一个标准的立体VR显示。你也可以将它设置为『Left』（左眼）、『Right』（右眼）或是『None』（无）。左眼和右眼就是你需要给双眼渲染不同的内容，或者是别的情况比如你想让他们的像看望远镜一样，把一只眼睛的画面关了，给他们很棒的体验，等等情况。最酷的就是你将它设置为『None』，这个镜头再也不是一个连续镜头，它会渲染主显示器的内容。如果你想要做异步的游戏流程，比如坐在PC前使用键盘鼠标的人想要看到不同的视角，，你就可以『镜头渲染设置为None』，然后你就可以控制这个了。这是个很好的方法，如果有人……因为每个看过VR demo的人，他们都是『喔，太棒了』（来回转头），而在外面的人则是『我看不到，我不知道发生了什么』，那么这时候你可以给他们另一个镜头。这个尤其在PC上是可行的，因为你要渲染另一个镜头，但是在现在的PC上这通常是可行的，而这对于看别人玩VR的人的体验来说会更好。

（咳嗽），抱歉。

图15.10

还有一些你可以在『Other Settings』里设置的东西。我猜我可能禁用了这一页幻灯片（就是上面这张），不我会在这里讲一讲。你可以『Other Settings』里设置的有『Graphics Jobs Experimental』（实验性图形工作）和『Single-Pass Stereo Rendering』（单通道立体渲染）。『Single-Pass Stereo Rendering』是默认开启的，不需要改它，除非你做一些特定的东西而不需要它的时候，比如做你自己的硬件、而你也不需要我们这么做。这个的作用就是，每次调用绘制的时候，CPU上会有所有的设置工作，然后传递给GPU，然后GPU绘制出来，而『Single-Pass Stereo Rendering』做的就是为每一次绘制、每一帧都运行一次，在尽可能晚的时候我们会『顺便，不是渲染这个物品一次，我们会从这个角度渲染一次，再从那个角度渲染一次』。不过我们会将这部分东西都进行分享，也分享两眼间的着色。我们会做一个巨大的可以容纳下双眼的菲涅耳方程（Fresnel），这样我们就只需上色一次。我们也分享阴影（Shadow Pass）。

你们可能会用到『Graphics Jobs』，尤其是在Vive上。它是我们最新的纯模式渲染器（pure-mode renderer），也是我们用来做多线程渲染的方法，它运行得更快，也支持DX 12和Vulkan。对于较老的API，你需要测试它来确保（能用），因为你可能只想要使用以前的多线程渲染器——目前是另一个复选框，马上就会被一个下拉菜单取代。

图15.11

以上就是工作流，还有一些东西我会在设计层面谈到，比如设置你的输入之类的，来谈谈设计。

图15.12

（清嗓子）在这个部分，我会尽量将主题设为连贯性。看看我到时候做的怎么样，因为我还没做过这个演讲。（喝水）

图15.13

为了易于理解连贯性，我会先从我们的老朋友重力开始。在这里的每个人都应该知道这一点。连贯性就是，不管你展示给你的玩家是什么，（观众笑，因为幻灯片里的孩子摔倒了），不管他听到了什么，不管你展示了什么，不管你让他做什么，重力总是在提醒他是站着的，重力总是在往下拉，就是这样。所以你需要跟这个事实保持连贯性。

我们看到很多的应用有高速的汽车追逐、或者是过山车之类的东西，突然之间会有转弯。如果你的车拐弯很快会发生什么？我是**过来的，我也知道你们明白，你们会因为向心力而被向外拉对吧？但是你的内耳不会这么觉得，你只会感受到一个向下的力，所以如果想要避免这个情况，你至少要让他们在一个能倾斜的飞船或是飞机里，因为在你倾斜玩家的时候，他们的身体会认为『我感觉到了这个力，但是（合力）还是在垂直向下的这条线上的』，这就是用来避免的方法。

当然我还要覆盖到所有的基本操作。一直保持头部跟踪，即便是在暂停菜单。不管什么原因丢失了HMD跟踪，消失变为黑色。不要把你的用户放到小船上——我见过这个，我通常不会感到恶心，我做了很多的VR，但是身处在海洋里的一艘小船上对我非常的不利（可能会感到恶心）——，保持稳定的地平线。不要用脚本覆盖镜头，让跟踪系统控制镜头。

伴随着重力，人们无法感知到速度，而只能感知到加速度。也就是说，如果你在一辆车或者飞机里，你能感受到起步，你会被往后按到你的座位里，但是一旦达到了满速、稳定速度的时候，你不会感受到你在移动。记住这个，因为这就是大脑告诉我们的，他们没有在动。如果你要玩家在一个非常快的车里驾驶，这是没问题的，但是你不需要的是很慢的加速度，让他们慢慢运动然后有整个加速的过程。尽快给他们一个稳定的速度就行了。

图15.14

焦点。你需要保持一个连贯的聚焦范围。这是我在internet上找的一张图，我在幻灯片最后加了credit，我保证在后面有。这张图就是人们在VR中看的地方的热力图（原图为动图）。你可以看到大部分都是往前看，这是个好消息，因为我们也不想让他们疲劳。有东西的时候他们看得会稍微漂移一些。

人眼很容易就会疲劳，它们喜欢保持专注看向正前方的一个固定距离。这就意味着，你需要确认你需要他们关注的东西，尤其是快速运动的东西，要保持他们面前在这2-5米的距离里。你不能做到是『哦，你看看远处的是什么』，不仅仅是因为看向远处的时候会丢失立体透视，而且如果你要他们看向房间远处的、然后再回到面前、再看向远处，他们的眼睛会因为聚焦而疲劳——因为这背后还是有肌肉拉伸之类的东西。保持他们的聚焦范围在2-5米，是我们知道的阅读文本的最佳距离，这是好事。另一件关于文本的事情，众所周知在VR上渲染是很困难的，尽量保持它对玩家是在这个距离里的一个竖直面，不要让他们阅读远距离外放在桌面上的东西，因为这样的体验非常差。

图15.15

输入。关于这个有一些要讨论到的东西。

我们有跟踪手柄这样的新的输入样式，非常棒。它跟你同时开发的移动端应用和PC应用的区别并没有那大，它有完全不同的样式，你会有触摸界面、键鼠界面，而现在我们又有了手部跟踪界面。所以你只需要做的就是跟移动端和PC上一样的技巧，抽象化所有的输入。你的代码不应该是『当这个按钮被按下时，给玩家一个让他跳的力』，而应该是『当这个按钮被按下时，发送一条信息给玩家让他跳』，然后玩家会说，『哦，你是想让我跳吗？我会施加这个力的』，这样就很容易地交换不同的输入类型。跳跃可能不是最好的例子，因为这是头部追踪的VR，所以你叫他们跳，他们就会跳。这个可能在VR里也不是个好主意。

关于输入的另一点是，这个很适合创新。这（幻灯片中的动图）是我在Alchemy Labs的朋友做的，他们让你退出游戏的方法，可能你们都玩过了。他们有一个『退出卷饼』（Exit Burrito。Burrito是墨西哥卷饼），而我非常希望这个变成一个标准，所以……加入一个『退出卷饼』吧。

既然讲到了输入，还有一件我要在这里讲的事情，那就是人类非常擅长于站立。如果有人给我钱，我可以整天都站在这里。而我不能做的事甩我的手臂甩上一天，因为我从来不锻炼。如果我需要，比如说进行很多『指』的动作，然后要保持我的手指，『指』着，几秒后我（手臂）就会掉下来了。记住这一点，跟眼睛类似的，手臂也会疲劳，所以不要尝试，除非——你可以这么做，我看到过一些很棒的激光剑（light saber）战役、剑术战斗、还有Audioshield这样的游戏，非常有趣——但是你要记住你需要给他们休息之类的，因为，对，我们都很懒。还记得Wii出现的时候，我们都是（大幅度挥着手臂）『耶，这太棒了』，而现在你玩网球就像是（扭动手腕），就这样。（观众笑声）人类都是很懒的。

图15.16

确保你给了他们一个代理（象征之类的？反正就是代表你这个人的）。保证你的手部跟踪是最好的——我非常高兴的是Valve宣布他们会让制作手部跟踪的东西的人更容易。保证你至少要做一双手，你不需要担心身体剩下的部分。我们看到很多人做了整个身体的化身之类的，他们不——IK系统（这是啥？）不知道这个^图15.17和这个^图15.18的区别，所以会有打破并不符合现实的可能，如果能给它们提供一些东西来区别这些会非常棒。很多的人，可能在这个房间里的人，都在开发能够帮助做到这一点的东西。整体来说，手和头的跟踪基本上就是所需要的全部了。我个人认为情况马上会变得更好的，但是现在别这么做。

图15.17

图15.18

我们看到给你化身的另一个问题是，你会被固定在驾驶舱里，所以他们给了你整个身体，当你抓住东西控制之类的时候，它是可以匹配的，但是当你向下看的时候，你看到了你的胸腔里面，就显得有点可怕了。幸亏在解剖学上是不对的，不然我会觉得更好？更坏？我不知道。反正你记住你不需要担心这个就可以了。手通常是最好的，它们是跨平台的，也即是说你不需要担心设计问题，『我要给他们显示触摸手柄吗？要显示给他们Vive手柄吗？』不需要担心这个，他们只会看到抽象的手，而且跟人类的有关（五个手指咯），对于沉浸感也更好一点。大部分平台会给你CAD模型，所以你可以很好地给他们展示手柄。

图15.19

关于不需要身体，有一件你需要考虑的是，当你站着的时候，如果我向下看，除了我很讨厌因为下雨所以我要穿上裤子以外（？平常不穿吗），我知道我在哪里。我知道我离物品有多近，我知道我走过去要多少步，因为我知道我在这个世界中的位置。所以尽量给他们一些这样的外观，我们看到很多人一点都不给，给他们一点点阴影来表示『嘿，这是你开始的地方』。做一些脚印来显示你目前是在这个区域，那个是你面对的，如果你往前走，我就知道我在世界中的位置了。在我四处看的时候，这就非常好地让我对自己进行了定位。因为这就是我向下看的时候关注的『这个是地面，我在这里，别的东西都在哪里？』，对吧？

取决于你要怎么让他们移动，这个方法可以告诉他们你们将会移动镜头的路径。如果你不这么做，可能不是一个好主意。你可以说『你要这样走过去』，它就会给他们显示『嘿，如果我这么做，这就是我要去的地方』，然后它给反馈给他们连接，比如『嘿，我知道怎么走，我也知道怎么到那里。』如果你告诉他们这个，他们仍然有一样的感觉。（这段我没听懂？为什么明明没有不认识的单词，但是就是不懂要说啥呢？）。

\

图15.20

最后一个就是VR幽灵。（图中的手能穿过那个东西）我讲的不是渲染或是像素相应时间这样的东西。我要讲的是可以互动的物品。VR目前还是非常新奇的，每个人都『这个好让人吃惊啊！我在这个世界里』，突然，最无聊的东西，比如他们之前理都不会理的老派第一人称射击游戏，在这个世界里是最神奇的东西。就像是（拿起杯子）『哦，看！这是一个马克杯！我可以拿它这么做！』他们就会做这个，在某写时候，有人会跟你的世界里的所有东西互动。所以请牢记这个，不要把不能互动的东西放在那里，这个对CPU什么的负荷也很大。目前不要放凹进去的物体，比如这个马克杯，做这样的事情（把笔放到了马克杯里）。在VR，这个非常困难，因为这是一个实际物品——我的意思是我现在需要一个实际物品来做这个，和来回旋转。（不能）允许这样复杂的交互显示了现在的物理引擎还只是近似数，甚至——即便他们可以太快太协调地合作，人脑也可以瞬间就挑出来。

另一个就是，如果你有一个背景角色，在干他们自己的事情，比如在侧面做女士园艺，然后他们上前说『嘿』，开始踢她然后经过她，然后也没发生什么事情（？？？）。这立刻就会破坏沉浸感，让他们觉得它是不存在的（你说的都是什么啊，人称代词瞎**用）。避免这样的事情。我看过一个我们做的demo，最后我们没有发布它，不过其中发生的一件事就是，一个人走上来跟你的角色聊天——这是跟我的互动——，然后我是在这里（移动到左边），他还是对着那边说话（指向原来的位置），我就『哦，好吧』。如果你要有这样的场景，确保你在跟踪玩家的位置，尤其是在房间这样的大小下，因为他们可能站在任何地方。然后你再对此做出反应。

图15.21

我想谈最后一个就是现实。现实是非常平滑连续的，我们有过一种叫既视感（deja vu）的概念，这时候我们会注意到大脑在告诉我们的东西。现实不会变慢——除非你嗑了药——，也不会断断续续。而这部分就是我下一节要讲的内容，优化。

重复说一次，以上就是当我们去尝试很多VR的东西的时候，我们看到的人们经常做的设计，而我们就觉得『啊，你不应该这么做』。我看到了很多，所以我只是——最好你们之前都听过了，如果没有的话，最好你们也学到了什么。

图15.22

大家都知道性能非常重要。我们需要保持90fps，这像是……在不到两年前，这还是60fps，而现在我们需要90fps，同时还要渲染所有东西两次。那么你们能做什么来保证能保持一个稳定的帧数呢？

我已经讲过这些了（图15.10），『Graphics Jobs Experimental』和『Single-Pass Stereo Rendering』，它们会对你的性能产生可观的影响。我要重申一次，如果可以请在这些复选框打上勾，你会开心的。

图15.23

总体来说，做每件事不要超过一次。我们已经渲染所有东西两次了，所以每一个能限制任意一个流程的次数的行为都是更好的。不要使用图像效果，除了抗锯齿。我会讲讲这个。你可能知道图像效果对屏幕上的每个像素都有效，而现在所有人都想要一个4K显示器、而我们还讨论到了8K显示器，还有5K电视机之类很可笑的东西。要处理很多的像素，所以如果你这么做了（加效果），你就不得不做两次，因为你要为每只眼睛都做一次，而这很糟糕。我们新的电影图像确实支持VR，而且他们也做了一些明智的事情来让这些是可行的。这里的大多数人，我假设你们都是用基于PC，呃，高端的基于PC的东西？如果你做了图像效果——我需要指出的是我现在说的东西不是绝对的，如果你像是要『我必须这么做』，那么也尽管去做——我的观点是你要知道所有东西都要成本，花在你最能收回成本的地方。我能想到的一件事情就是，一直使用抗锯齿。你们坐在那里，盯着我，你们的头会有微小的运动，你会伸个懒腰，你会哼哼唧唧（hemming hawing）什么的。所以你的头总是在动的，这就意味着，因为你的头是被追踪，所有锯齿上的缺口，你知道的『da crawl』（？？？），会一直在动，而这会非常的明显，一样的，我们不想搞得他们觉得自己嗑了药——除非你想，呃，想开发啥就开发啥吧。确保你将抗锯齿打开了，因为它会帮助改善锯齿，这是这个规则的例外。而剩下所有别的，你要知道你在干什么。

减少绘制调取。我之前说过，我们有单线程渲染、共享绘制调取，做了我们能做的。而你能做的是后台使用LOD（Levels of Detail，多细节层次），确保你打开了Culling（用于判断物品是否可见的渲染技术）。你可能会惊讶于我看到的出于某些原因关闭Culling的人的数量。他们从来没有开过这个，而你就会（啧了一下）『不，你需要Culling』。没有理由去渲染那些你看不到的东西。标准的流程，atlas texture（或者叫texture atlas，纹理合集，很多纹理图像放在一个文件里）和共享材质。你需要有一个大的材质，呃，一个大的纹理文件、一个你在多个物品中共享的材质文件。一个附加说明是，我看到人们经常没做好的是，确保你优化了光照贴图。如果你的光照贴图分辨率一团糟的话，你最终会有多个光照贴图。这就意味着，如果一半的物体在房间这一边，而另一半在那一边，中间我有一个光源贴图接缝的话，这就意味着这些东西才也不能重批处理，因为光源贴图——尤其是你使用标准着色器或是你自己的着色器——在你使用光源贴图时，它是被算作批处理的纹理部分的。有了光源贴图接缝就意味着会打破批处理，而没有发现这个问题的人会觉得『为什么这些东西没有批处理呢？』这可能是由于你的光源贴图变成了两个不同的光源贴图，而这引起两个绘制调取。

减少皮肤网格。（没有展开说，真的）

图15.24

静态光照。我有个感觉就是这里的大部分在明年我们再来看的时候已经废弃了，可能都不用等到两年半后那个的SDD。不过就现在而言，静态光照、所有东西保持静态是最好的。你不需要动态地生成东西，这会节省很多时间。使用Blob/No shadows（Unity的阴影选项），使用我们的light probe（光探针）系统。有些人可能不知道光探针是干什么的，它们就是在空间的特定位置采样光照情况，然后你做一个环绕你的世界的网格，然后在动态物体经过的时候，我们就采样它们所在的区块——有点像金字塔形——，我们就能知道『我们的光照条件怎么样？』，之后我们基于这个会把光照应用到物体上。这样你就可以让一些动态的物品移动进出阴影，而不需要动态的光照了。

避免CPU峰值，也就是垃圾收集器（garbage collector）的峰值。所有的标准的东西，比如使用对象池（object pooling），不实例化对象等等。如果你想知道更多，我可以在Q&A阶段讲得更详细，但是（我现在不讲）。考虑使用协同程序（co-routines）。如果你有长期、超长期的东西，或许使用协同程序在几帧上面断开。可能有些人不知道，协同程序是一种时间分割，是一种算法，差不多就是『我要做点工作，然后等一会儿，然后我再做点工作』。如果你需要计算敌人到玩家的路径之类的东西，那么就可以『如果敌人不在3帧里有反应，玩家也不会注意到』，那么可以在这3帧上计算。我要说的是，确定你知道你用协同程序在干什么，他们会产生一些内存，所以请节约的使用它们。

图15.25

减少渲染纹理的更新。如果你有什么类似于舞台摄像机和背景摄像机的东西，确保你不需要在每一帧更新，可能这个在你90fps的情况下以30fps运行——这取决于你的图形有多真实和你的玩家会花多少时间看它。渲染纹理是完全渲染，代价非常的高。

考虑简化你的图形：更是的对象、更慢的多边形网格、使用高分辨率的纹理来提供更多细节、平面化着色。我认为之前的幻灯片中提到的有一点很好，对我们来说，人们不在乎有多么的超现实。我们都知道恐怖谷（Uncanny Valley）理论，你越接近它（恐怖谷），尤其是在他们都知道他们在VR中的时候，他们就能越快地注意到这一点，所以要将它们进行卡通化什么的。同样地，只要它是连贯的，只要你没有进行连锁设置，只要你说『重力是这样的』而重力一直保持这样，那么一切都好。考虑使用平面化着色，除非你要做建筑的东西，这个需要一点真实性。

图15.26

分析（Profile），我去了很多工作室，问他们『分析器（Profiler）是怎么说的？』，他们就一脸『啥？』分析、分析、分析，你需要的所有答案都在分析里。所以确保你们使用了分析器，它可以帮助你找出你产生的内存都是哪些，你可以生成快照、按照产生最多垃圾排列，然后进行清理。你还可以找到你想用比如非分配版本（non- allocating version）的地方，或者是用字符串传递状态名的地方，你可以用一个数字替换出来，这样就可以节省很多内存、也不会经常收集垃圾了。

使用我们的Frame Debugger（帧调试器）。我们的Frame Debugger可以让你搞清楚在绘制什么、顺序是什么，可以帮助你找到在哪儿破坏了批处理。你会发现类似『为什么那个东西现在在被渲染？它不需要被渲染』，然后搞清楚原因。你也可以用它帮助你优化你的着色器之类的。

最后一点就是动态性能。我之前也说过，我说过『不要做这个，你做的这个是错的』这样的话，如果你这么做，它们的代价比你想象中还要大，所以请考虑这些东西。我可以说很多人都觉得『我要做这个，我必须让性能状况在整个体验中都需要是稳定的』，其实你可以进行挑选。比如如果你有一个怪物撞进墙里之类的，你可以挑选你的战斗，你知道的，基于……显然地……测试情况。你可以打开更多的粒子特效，你可以有更多的图形特效在他们所关注的东西上，而把后面他们不会注意到的一堆东西都关了。你不需要觉得自己必须在全程都有一样的性能状态。在你做任何的移动内容的时候，这是尤为正确的，因为在移动端，性能等于发热和电池寿命，所以同样地如果你需要的话，你可以牺牲一些很棒的特效。

图15.27

我最后要讲的是线路图。这是个高层次的东西，我不会给出什么日期之类的。我要讲的第一个是Editor VR（VR下的编辑器）。Editor VR提供给你一种方式，让你能在头显的进行移动、操纵、想世界中实例化新物品并放置它们，以及进入和退出游玩模式，等等这类东西。我们马上就要公布新内容了，所以在未来几周里请保持关注有关这个的消息。Editor VR的目标是帮助你的迭代次数。我们正在将它做成可配置的，这样你们就可以加入你们自己的工具之类的东西了，就像你用Editor一样。我个人认为这非常适合迭代你的玩家会的地方。我的例子就是，你有一个恐怖的森林场景，你的玩家会走过或者是站在里面。你不会去放置每一棵树——虽然你可以这么做，也挺简单的，只后我们会展示一个棋盘，你可以使用标准做法，我们有工具将树绘制到场景里什么的——，你会做的是，你会找到一颗应该高大到让他们觉得自身渺小害怕的树，然后你可以站在那里比划『这里应该更大。好的，移过来一点。太远、太近』，你可以调整这些东西，而不需要离开VR、编辑、再回来这样的重复操作。你只需要过去说『这样做会感觉比较好』，然后做就可以了。这就是Editor VR的目的。

我们在做一个VR互动套件（VR Interaction Kit）。这些是类似你可以放到对象上的组件，定下『这是个被追踪物，它正在被左手或是右手追踪，它还在做什么什么』。我们想把它变得对你来说非常简单，不需要考虑使用什么输入设备。现在有很多新的输入设备，我们不能做到全部，但是这样定下『这个对象是被追踪的』会简单很多。也可以让输入能在触摸手柄和Vive手柄上都有布局，搞清楚你在用是哪种输入。比如如果我举起一个东西，然后把手放到了桌面，我需要的反应是什么？我们有三种不同的互动模式供你使用。同样地，我们马上会进行公布，也会开发到我们的即将带来的最新输入系统里，比之前的那个要好多了——我不说你们也知道，之前那个太旧了，就放在那里吧。新的输入系统非常棒，它允许插入『嘿这是我的硬件，我要发送这个数据了』，你就可以读取原始数据、或者是进行互动，比如『我想关注的只有开火按钮什么时候被按下了』，提供给你硬件的人可能就可以给你提供一个嵌入到输入系统的插件，而你不需要做什么事情。同样还有一个手势识别器，这样就可以定义『这是圆形手势、这是星星手势』（画了个圆和五角星），然后人们就可以提供给你解释程序了，并且是可嵌入和开源的。很棒。

性能。我们总是关注性能。我们已经和NVIDIA和AMD合作整合VRWroks（NVIDIA的VR组件）和LiquidVR（AMD的），所以在明年年初，你很有可能就能看到实际的应用以及你能用到的部分了。我们在性能上的其他研究通常是在每个平台的，我们跟合作伙伴进行了很多工作来确保我们为他们的平台进行了优化。我们在研究比如凹面渲染之类东西，不过我们也不是100%确定最好的游戏会在哪里。

最后就是改善移动端工作流。同样地，这跟Editor VR有关，但是专门是针对移动端。你需要开发、部署它到固定设备上，拔下它，把它放到其它任何设备上，放到头上，『哦，这个不能运行』，然后重做，或是撤销、重做。我们现在就在积极地寻找改善这个迭代速度的方法，这可能是另一件事情了。如果你在Q&A阶段有什么特别的问题，尽管问我。

图15.28

如果你需要的话，我们会进行一个12个月的专业订阅内容的抽奖。如果你前往这个地址——这个是区分大小写的——，我们会在展会结束后给中奖人发送一封email。地址就是bit.ly/sdd-sea，sea我猜是Seattle。大家都明白了？

图15.29

好的。谢谢。

（Q&A部分）

Corey：

现在开放提问时间，这里有些递话筒的人（micro runner），你们只要举手，我就……前面的这个人已经有一个（话筒）了，然后我会把他叫出来，在我们交谈的时候留在那里——以防止你们没搞懂。

提问者1：

谢谢。很好的演讲。我有个问题，你提到了光源贴图的优化。

Corey：

嗯.

提问者1：

你是怎么把对象……你是怎么处于特定光源贴图下呢？还是说不用？

Corey：

基本上，你只需要调整分辨率。通常你尽量需要你的分辨率是一个大的光源贴图，不过如果你要一个非常高保真度的光源之类的，你可以试试看。你不需要将你的整个世界到处移动来进行匹配，也不需要移动光缝，它只要——不用放大整个地图——放大地图中的单独的物体、让他们合适就行了。现在差不多是黑魔法一样。

这里有个人，我会这么叫过来。

提问者2：

很棒的演讲。Unity太棒了，对吧？（观众起哄）

Corey：

停一下。

提问者2：

伙计，你太（棒了）……尤其是有很多可以学习的东西，很多关于优化的东西。当我检查我的分析器的时候，我经常看到的是，物理学占据了很大一部分。我记得在你的另一个演讲里，你谈到过覆盖物理学，人工地做这些部分。你能稍微再多一点地谈一下这个吗？有没有什么代码库之类的？

Corey：

可以。回到我『所有东西都需要是可互动的』这一观点，VR是非常新颖的，每个你能触摸的东西，他们都会想要去触摸。

首先就是不要在你的场景里放类似一堆回形针之类的东西，因为人们会想做一些疯狂的事情，比如做一个回形针链，那么你的生活就会非常非常艰难。这是第一点。

第二点就是，如果你只有简单的物理学，比如你只是到处移动，所有东西都是用动画表现的，你推动物品时也是动画，那么你就不需要太多的物理学，除了掉落什么的。你不需要使用我们的物理学组件。比如重力是9.8（N/kg），你可以加进去然后用自己的脚本进行动画。如果你这么做的话，我们就可以剥离出更多代码。对于PC来说，这不算是个问题；但是对于主机，我们看到很多……主机上的物理学非常的困难，因为这个跟CPU相关。所以我们也在进行，我之前也跟我们的物理学团队进行过讨论，我们会搞清楚我们能做些什么。我认为物理学整体上作为一个游戏技术，还需要下一步（的发展）。我们讲了很多关于硬件和软件的内容，但是我们还需要谈到物理学，VR意味着我们要有更多动态的东西，我们需要有更好的准确性，而这是……我认为这是作为一个行业需要进行工作的，我现在也在准备让我们开始内部进行着工作。

现在的情况是，如果你要扔一个东西之类的，GameDev.net上有这个代码。你可以去找到它，开发你自己的小插件，进行优化，这样就不需要处理一大堆物理学上的事情了，你就可以去考虑别的东西。你在那里也可以找到一些很好的优化。

这边的这位先生。对，就是你。后面，后面，就这里。

提问者3：

谢谢。对于在一个版本中将多个HDM作为目标平台，你有什么推荐的吗？你提到了掉落的指令。

Corey：

这个确实取决于你是否想要管理多个版本。你可以设置你的……启动成本可能是非常小的，『哦，这个平台上没有SDK，那么去下一个平台』。我们谈到过PC，安装包大小也没有关系，基本上就是你是不是想要一个干净的版本给……你提交到Steam上的那个不支持Oculus，或是仅通过OpenVR指出Oculus——这也是另一个可能——，或是你想要在Oculus商店提交……它无所谓是哪种方式，因为他们不会让你从他们的商店发布到HGC5（？）。如果你不在意SDK成为可执行文件所要的几兆内容的话，你可以有一个只有Oculus的版本。总体上来说，你只需要将你关注的HMD加入到列表中，然后初始化，然后……其实你不用做什么事情。勾选选项，加入SDK，发布就可以。

如果你有一些没有在列表里的其他东西，而你又想要支持，你需要写一些代码说『嘿，你叫一下SDK的初始化』之类的，这差不多就是你能用在新东西上的脚本了。当然，如果你说的是PC，我一点也不担心这个。你想支持什么，你只要确保它在列表里就行了。顺序……如果你想做一个大的东西，顺序才会有影响，因为如果你用OpenVR，它可能在Oculus上运行OpenVR版本——因为你知道的，这是OpenVR所以能支持这个——，所以这个时候你会想要把Oculus放在第一位。这样如果你将这个版本提交给Oculus的时候，它就会那么运行；然后如果你提交同一个版本到Steam，他们用的是Vive，它依然能运行，玩家们也不会注意到区别。

穿白衬衫的那个人，差不多在后面的中间。有顶黑色帽子的那个。后面，后面右边。对。

提问者4：

谢谢。我在想你能不能将实验室渲染器的东西放到原生Unity中？

Corey：

是，但是不是你想的那样。我们即将有一个功能叫做『Scriptable Render Loops』（脚本渲染循环），我们正在将所有控制渲染循环设置的代码移动到C#中，让它成为开源代码。我们也用这个方法部署了实验室渲染器，实际上这是我们的第一个测试用例。这个允许图形工程师或是平台拥有人可以任意定制渲染流程。这部分都是开源的，这就意味着如果你想写一个我们没有的4+渲染器，你可以用我们的4渲染循环再加几百行代码就可以了。

所以，是的，会有的。我们的目标是最终实现它，这样你们就不需要平台上的插件，只要尽可能做好就行了。我们跟Valve有非常亲密的合作，来确保能够实现。这里的例子就Mecanim（Unity的一个动画系统）。几周后我们会有Unite（Unity课程），我们会谈到更多关于『Scriptable Render Loops』的内容，我们会有课程讲它的工作原理。

提问者4：

谢谢。

Corey：

呃……这个人，哦不，等等，对不起。这个人已经有了话筒了。就先他了。

提问者5：

谢谢。我有个关于VR中的profiling的问题。

Corey：

好。

提问者5：

我现在在开发一个Vive游戏，使用的是OpenVR，我们已经开始遇到性能问题了。就跟GrayBox一样非常简单的图形。当我们去看CPU的分析器的时候，我看到了很大的、基本上连续不断的峰值写着『VR.WaitForGPU』，看上去是跟GPU有关的。而在GPU（分析器），它写的是『other』，而这才是大部分时候的主要因素。这就很难识别出瓶颈是什么了——除非我不用分析器，猜测、检查，把东西不断关了又开。

Corey：

据我所知，我不知道什么是在『other』这一类下的，我能做的只能说带回这个反馈。不过我记得是，在11点的那一节会有Vulkan渲染器的讨论组（演讲18），Mikko也在那里，他是我们的渲染工程师。所以我会在那次讨论组结束之后找到他，然后browbeat（逼问？）他『这是怎么回事？』

提问者5：

好的，谢谢。

Corey：

我就这么卖了他（Throw him under the bus）。这边有个人举手有一段时间了。那个穿着运动外套的衣冠楚楚的先生。走你。是运动外套吗？为什么人们叫它运动外套，我不懂，它们并不是啊。

提问者6：

我也不知道……无论如何，谢谢你的演讲，我们都非常感谢。你有提到在VR中的手势，这是要被添加的，还是已经存在了的？

Corey：

这个是……新的输入系统可以让你嵌入手势识别器。就是你可以写一小个脚本，将进入的原始数据进行解释，然后随便一个人就可以定义一个手势的意义。这基本上会一直拉取输入，当手势被识别出来的时候，它们就可以发送一个活动。我要说的是，我们加的不是『嘿，他们做了个圆』（画了个圆），我们加的是，将输入系统设计成别人可以说『这是画圆的临界值』（画了个圆）。所以它会被加入，但不一定非要是我们。我们希望提供输入的人可以有识别普通手势的东西，尤其是如果他们最终也要参与进这个系统的话。

提问者6：

好的。所以这个是一个在你已经说的基础上的额外的插件，还是一组输入标准？

Corey：

它会是你可以写和用——嵌入到输入系统——的脚本。输入系统不是一个插件，它只是一些脚本、API，你可以用在上面写『我想要调取数据，一旦这个情况发生我想要做这个』，而且也很容易抽象化到代码中。你的游戏代码很可能就是『他们画了一个圆』，而你不需要担心它，它会保持自己独立。如果你在一个不同的平台上，那么——因为可以手部跟踪——你就可以有移动版的VR内容了，这个可能一年内就可以实现。它（代码）可能就是『在这个平台，这个的意思是触摸，我会找触摸活动，而不是在这个世界中的3D位置』，所以我们要确保有一个很好的抽象化层，我们也在提供它，你们只要填满空缺就行了，这样找到开源的手势识别器也会非常的容易。

提问者6：

很棒，谢谢。

Corey：

在前面这个人，然后我们会这样扫过去。

提问者7：

我看到的一件事，Job Simulator上最强力的一部分是和物品的互动，以及是多么的流畅。

Corey：

是。

提问者7：

我在想，这些互动是通过基于实物和手部模型的互动实现的，还是当你足够靠近一个按钮的时候——按钮被按下的时候，触发动画？换句话说，通常最好的让它们流畅、互动受制良好的最好方式是什么？

Corey：

我跟他们（应该是Job Simulator开发者）谈过，不过我忘了，所以我不想跟他们讨论。Devin应该在，可能不在这个房间，不过Devin和Alchemy Labs的人都在这里，所以找到他们、去问他们。

这里面有几点，最主要的考虑是，再说一次，我把一个东西拿手里会发生什么？我能把手穿过一面墙或者是别的不能移动的东西吗？有几种方法。有些人会让你掉落（这个东西）。有的人会有一个关节，物理关节，你捡起一个物体的时候，它是在关节上的；它可以是弹簧关节，所以当我的手移过的时候，物体会保持在这里，如果我手移动到一个点，我会断开这个的连接，它就掉下去了。其它的就是，它会待在这里，当我回来的时候，它会跟着一起走。还有就是，仅仅施加这个力，那么就会出现一些稀奇古怪的事情。

这些都取决于你，以及和你想要在游戏里的感觉。我之前提到过的交互套件也有一些——我记得是三个——不同的选项，这样你就可以说『这个物品上被抓住的，它的定义是什么』；也可以说『我想要个关节约束』，然后你就可以调整关节了；又或者是『我只想让这个东西离开』——因为另一件你能做的就是关闭它的碰撞，然后它跟着我走，但是如果我让它出了这个世界，会发生什么，懂吗？所以这取决于你，以及你需要在游戏里的交互。

最简单的一种是关闭碰撞，只需要更新被跟踪的手部位置就行了，但是这样人们会把东西掉到世界外面。所以如果你有一个机制来处理这个，或者这个也没关系的话——因为你可以仅仅产生一个新内容，把东西扔来扔去，或者你无所谓，那么……因为你在生成所有这些内容，你需要一个方法来摆脱它……那么好吧。

再说一次，我们会提供给你选项，所以这真的取决于你。

我们会慢慢扫过去。这个人在你前面，抱歉。是有两个话筒吗？另一个话筒在哪里？好吧好吧，我们会点一下后面的人，然后再回到前面，会回到前面的。

提问者8：

谢谢。刚体扫描可能也会有用。

Corey：

是的。

提问者8：

我的问题是，你有提升编辑器性能的建议吗？因为我发现我禁用了Gizmos（Unity脚本API）后，我需要破解第三方素材画定制场景视图，哦，不是场景视图，不好意思，是工具栏。我的游戏帧更新时间是5ms，而我还是能看到很严重的掉帧——如果我不禁用掉这些的话。

Corey：

你说的优化的方法是禁用内容，是吗？我很感兴趣你能不能分享一下你的项目，发个email给我或者提交一个bug都行。我不知道你的项目有多大。如果你可以测试……因为如果你给我email，我可以发给你一个脚本来剥离你的素材，比如声音、纹理之类的，让它可以打包。这会是个很有趣的测试来看代码是不是在运行，或是数据大小对不对。我们会追踪的，找人看看并搞清楚，因为我们不想……我们想让Editor有流畅的性能。再说一次，我的email是corey，c-o-r-e-y，@unity，所以给我发email，我们会跟进的。

提问者8：

好的，谢谢。

Corey：

后面是有人有问题吗？有吗？那个人，那个人很想问他的问题。

提问者9：

好的。关于分析器，关注……尝试不同的渲染器、尝试不同的批处理，我想要一个能定量比较的方法。所以我曾经尝试做过一个时间demo，可以让头显以一个特定的模式飞行，但是我不能——你知道的，你不能……我不能接管跟踪系统。有什么方法能做这样的严格的AB测试吗？

Corey：

其实你可以接管跟踪系统，只要不要有人在头显里就行了。只是，如果只是……

提问者9：

是的。

Corey：

如果你只是看数据，而不是实际体验的话，这是没关系的。在这个例子中，这是一个很好的应用案例，让镜头到处飞来看场景的那部分是更耗资源的。这个可以，只要确保你不会把测试人员放到头显里就行，不然就会很糟。

提问者9：

好的，我会继续尝试的。

Corey：

嗯。轮到这个人了。

提问者10：

简短的问题。你提到了AA（Anti- Aliasing，抗锯齿）有多么重要，我很好奇，我们要一起使用镜头脚本AA和项目画质设置AA吗？

Corey：

我会用我们最新的电影图像效果（Cinematic Image Effect），它们是我们现在积极致力于的最新的技术，我们也花了最多时间在这上面优化VR。所以这些就是我会用的，我可能不会使用画质设置里的那些，只用这些。

提问者10：

谢谢。

Corey：

在后面的（那个人）。

提问者11：

你提到了渲染性能，比如三角、纹理大小还有批处理。我有些疑惑的是，有没有一个顺序，比如，有个东西可以稍微更高（优先级）一点？或是说，我把这个调高了，这个就可以调低。好的顺序是怎么样的，比如三角比纹理大小更高，或者实际上……

Corey：

呃，不，这是你需要自己调整的。让你的技术美术到处调试。所有的东西，我是说我们在PC平台，所以三角非常的廉价，所以……

提问者11：

这就是我的假设，三角总是最廉价的，但是我不确定我是不是做出了错误的假设。

Corey：

我的建议是整体上的，我会加入一些移动端（上的）。在PC上，我会说三角是最不需要优化的，但是除此以外，确实非常取决于……因为你做的每个微小改变都会影响游戏的样子，所以你需要搞清楚这些，哪里要付出代价。

提问者11：

好的。还有个非常简短的问题，你提到的电影图像效果是在标准素材包里有的吗？还是……

Corey：

是的，会有……不，它们不再标准素材包里，它们作为单独的包在资源商店上。它们也在GitHub Open Source上，你可以下载它们，它们都是开源的。我们刚刚发布了一个叫『Uber Effect』的素材，它们优化地更好。如果你要使用多个，我们也让它们互相之间能共享passes。因为之前我们开发技术的时候它们都是独立的，我们刚刚将它们放进了一个『Uber Effect』里，这样如果你使用它，当你打开A的时候，我们会确保它们以最正确有效的顺序，然后是B，我们就可以共享它们的passes，这样它们就可以比单独加入它们更高效了。它们都是开源的或是在资源商店上作为包的形式，我们为此非常自豪，它们看起来很棒，我们也有力最好的性能，因为我们在它们上投入了很多工作。

提问者11：

不好意思，『Uber Effect』是综合性的图像效果吗？

Corey：

是的，你不用向镜头加入多个脚本，你只需要加入一个脚本，然后你就可以选择开关各个特效了。它运行的方式就像标准的着色器，在你没有加入特效的地方，我们会用编译版本来进行编译，所以这样就优化了。

提问者11：

你仍然推荐对它使用AA，对吗？还是自己搞？

Corey：

在PC上……我倾向于稍微谨慎点。在PC上，你可能需要抛弃一些别的东西，尤其是在已经完成，并进行了一些优化之后。但是还是那句话，AA是最基本的。加入别的东西仍然还是很昂贵的。不过还是一样的，这是由你自己决定，性能是不是值得这个——因为如果你有一些非常卡通、平面着色的东西，又或是你在一个柱形世界里，它们运行的就像是『当然，为什么不开花，谁在乎？』如果你不在乎，你懂的，你要抛弃什么都取决于你。

提问者11：

谢谢。

Corey：

谢谢。大概还可以有一个问题。那边的那个人。

之后我会到边上——如果你们想继续问问题——，或者我会在外面。我会在外面。

提问者12：

目前推荐的可以用于发布同时有VR和传统游戏支持的游戏工作流是怎么样的？比如不需要VR库被加载？因为现在，如果你想要给OpenVR发布什么东西，但是要去掉它，那么实际上是没有什么好方法可以每次运行都不启动OpenVR的。

Corey：

对。Em……很好的观点。你可以用脚本来控制VR支持，但是如果你没有勾选，它会被剥离。在剥离的情况下开发，并且有一个非常高优先级初始化的脚本在你最开始的引导载入或是引导程序场景的物体上，然后说『嘿，关掉它』。

（听人在说话，但是那个人没麦）哦，你说的没错，谢谢，我刚刚忘了。如果你支持了VR，在你的镜头里，就是这个，将它设置为『None』，它就会是一个标准镜头，你就不需要担心这个了。一旦你开启了VR支持，不管你的过程是什么样的，你只需要将你的镜头改为『Both』，然后你就有了VR内容了。当然，你需要担心跟踪等等，不过是的，这是实现它的方法。

好了，这就是最后的问题了。我会在房间外面，如果你有后续问题（请来找我）。谢谢大家。

（观众掌声）

16. 开发THE LAB

By Kris Katz、Jeep Barnett、David Sawyer、Tejeev Kohli、Don Holden、Paul Thuriot、Matt Charlesworth (Valve)

（自动忽略了一些口癖）

（观众掌声）

Kris：

早上好，欢迎来到开发THE LAB。在我们开始之前，我们先让每个人介绍一下自己，并稍微解释一下自己在Valve的工作内容。你那边那头开始。

Don：

我是Don，来自Valve。我是个程序员。

Tejeev：

我是Tejeev，也来自于Valve。我也是个程序员设计师。

Jeep：

我叫Jeep，也是个程序员。

David：

嗨，我叫David Sawyer。游戏设计师，程序员。

Paul：

我叫Paul Thuroit。我是角色技术总监（Technical Director）。

Matt：

我叫Matt Charlesworth。在The Lab中做美术和设计。

Kris：

我是Kris Katz，我基本上什么都做了一点。让我们开始吧。伙计们，为什么我们制作了The Lab？

David：

在早期的时候，Valve有一个硬件团队，在里面也有一些制作内容的人参与，探索……制作demo来验证硬件、作为内容制作者来探索这个领域、学习如何开发VR内容。The Lab团队和作为产品的The Lab是一直以来随着我们的这些实验和demo、随着我们开发硬件、随着我们自身学习这个领域，一起慢慢成长起来的。这非常的顺理成章，在一个时间点我们明确地意识到我们想要……我们不想学一堆东西，然后到达一个重置点，决定产品是什么；我们想要发布我们这里一路来开发的体验，找到一个方法接触到我们的顾客，让他们跟我们一样的一直开发的体验。

Jeep：

对。有一件让人惊讶的事情就是，在我们刚开始的时候，我们不知道怎么做一个VR游戏。我们在前进过程中学习，而我们做的每次实验，我们都会为什么能运行、什么不能运行而惊讶。我们想要顾客们也能在VR里非常有趣的东西类型是什么上，有这种惊讶的感觉，能跟我们有一样的体验。对于内容来说，它更大的意义是回到The Lab开始的时候，那是两年前的SDD，我们做了The Room demo。自此之后，我们开始知道，在一个无交互情景下，什么东西是在运行的。而人们喜欢的场景、以及我们想要开发的东西，是包含了很多最精彩的部分，然后在这个上面加入交互。我们开始的之前……在一年后的GDC上我们展示了Robot Repair，Aperture Robot Repair（Portal 2 VR，后面他们都简称为Aperture）。在我们展示这个demo之前，我们其实做了Secret Shop（Dota 2 VR），里面有一个神秘商店……

Paul：

商店商人。

Jeep：

对，神秘商店商人。

Paul：

在我们最开始的时候，我们（团队）非常的小，我们……正如他们说的，当时还是很早期，我们不知道什么是VR，我们对我们做的所有东西都非常兴奋。我们想做的就只是进行实验，将这个中心游玩区域变成所有人都可以做出贡献和尝试东西的地方。由于我们的规模很小，我们需要尽可能地重复利用来看看能做出什么。我们想要……我们非常感兴趣的其中一个实验就是，将你放到一个房间中跟另一个CG角色放到一起。我们在素材库里找了找，就发现了我们有这个高分辨率的商人，已经设置好了面部系统和所有其它东西，所以我们就决定在这个的基础上开发。因为还在非常早期，所以即使是最简单的东西也能让人兴奋。我们先做了这个商人在房间里跟你互动的内容，我们只加入了一个非常简单的东西，就是他的头部和眼睛会追踪你的头和头显，而这点就非常让人兴奋，光是看着这个就非常有趣，每个人都非常的兴奋。附带说一句，不管那个对话都需要加入它的，它非常的基本，但是就是这么让人兴奋，它一直发展到我们之后进行的实验中。

David：

这个阶段最初期的时候，是我成为开发者以来最兴奋的时候。

Paul：

是的。

David：

非常荣幸能参与到最初的阶段，而且能使用最早的硬件，成为第一批探索这个领域的人。我觉得这个过程有一种作为设计师的快乐，而我想要给我们的产品的其中一个主要感觉就是那种探索的童真快乐，学习新的领域、学习新的可能。

Paul：

在那里跟一个东西在一起，能够将它捡起来，甚至在这之前看着它，能绕着它走，都是非常的有趣。

Jeep：

在Secret Shop中，我们试图做的另一件事情就是开发出非常逼真的素材，对于开发这样的素材需要多少努力有个大体认识，并为它构建一条流水线，同时理解哪些我们在2D里用的小技巧可以或是不可以在3D里运用。

Paul：

所以在早期的时候，我可以肯定你们肯定遇到过这个问题，我们发现平常的地图不能像我们想象的那样使用，因为在你非常接近目标的时候无法获得它的视差（parallaxing）。性能是关键，素材需要是高性能的，因为帧数稍微有一些降低就会立刻使你感到不适。比如说在商店商人这个例子中，我们有非常高分辨率的脸、非常高分辨率的素材，然后我们不断地降低它的分辨率使它能够正好能足够高性能——在所有的时候，无论你是在看什么、无论空间里发生了什么——因为，再说一次，就算是掉了一帧也会改变所有东西。

David：

在那个时候之前，我们的内容都能比较容易的在Perf（Linux系统工具）上运行，因为它比较的简陋和实验性。而这是我们第一次尝试开发我们认为高质量但是却不知道怎么做的东西，所以有很多探索。

Paul：

对，差不多就是……

David：

如何开发美术资源。

Paul：

因为这只是一个探索区域，我们做了各种各样的东西。我们加入了风铃来看看能发生什么，你可以跟它们互动，只要敲它们就可以了。Clough(?不确定，没听出来)……

Jeep：

我们当时在游戏里甚至没有手，你需要用头去敲风铃。

Don：

对，我们当时没有手柄，那个clough把我头都搞大了。

Tejeev：

在Secret Shop之后，我们就准备在GDC 2015上首次发布头显了。我们意识到我们做的Secret Shop demo更多的是一个探索空间，如果要作为GDC上短时间演示来说并不是很好，所以我们就觉得做另一个demo，最后就做出了我们在GDC上展示的Aperture Robot Repair。我们同样也制作了高质量的3A级资源，而在这整个产出过程中，我们甚至还没有最终的硬件。我们还在DK2（Oculus Rift Development Kit 2）上做原型，也没有手柄。

David：

是的，与此同时，我们用了点小伎俩来不用手柄。

Tejeev：

是的，我们是跟硬件团队同步工作的，我们在同时开发产品。硬件还没有完成，软件也没有。两者差不多是一起上线的。

Paul：

我们一直假设这两个会正好一起出现。

David：

（说了啥听不清）

Tejeev：

是啊……我们假设，我们已经知道我们会有手柄，360跟踪这些东西。但是当时我们还没有……

Jeep：

是的，我们的想法是要构建一个叙事体验，做一个能装在5分钟的demo里、同时也可以让人们有一种环境变化的体验的东西，在变化中看到不同的东西。这就是我前面所说的，我们在（GDC）一年前的SDD上展示的内容就是最好的尝试，找出所有的最精彩部分，将它们放在一个场景里，就比如……

Tejeev：

就比如窗台。我们有窗台和抽屉等等，这一些我们在SDD上有的内容，我们都提炼并加入到了Aperture demo里面。

David：

手柄是在非常后期做的，

Tejeev：

可能只有几个月。

David：

Aperture都已经有了。

Jeep：

开始的时候你要用你的脸来开抽屉。你需要把脸贴近它，让后拉出来，再关上。（众人笑）

Tejeev：

对，因为我们只有一个头显这样的跟踪物，所以我们只能把头显放到触发器上——头显要做这。（歪了几下头）这行得通，不过很有趣。

David：

这行不通。

（众人笑）

Tejeev：

（说什么没听清，跟Paul重了）

Paul：

我们在尝试所有能做的，关键就在于我们不知道它行不行。

Matt：

我们假设这个技术是合适的，然后我们就会尽力……

Don：

我们用我们的脸干了很多事情。（众人笑）当我们拿到手柄的时候，我们就像是『哇哦』。

Paul：

在有限制之前，我们会地走进墙和东西里。

Jeep：

是的。

Tejeev：

对对，（这句没听清）。在这之后，我们从GDC回来后都非常兴奋。我们向全世界展示了Valve的头显，人们也很兴奋，Aperture demo在展示紧凑的五分钟内容上也很成功。我们回来了之后就想这之后我们该做什么。我们每个人对于什么好使、什么不好使都有自己的不同的想法，而我们想要都尝试一遍。

Don：

同时我们也有了手柄。

Tejeev：

这是我们第一次有手柄。

Don：

在我们开发Aperture demo的时候，我们大部分人都没有手柄。

David：

在GDC之后，我们觉得应该再次作为一个团队来工作了。我们当时觉得我们在设计工具箱中没有足够的工具，来打造一个产品完整的体验。

Jeep：

还有太多的没有覆盖到的区域。

David：

是的，所以我们在Aperture之前做了一些实验，然后我们继续探索，我们组成了更小的小组、开发更小型的体验。我记得当时我们可能都不清楚会不会重置，然后开发……取其中的一个体验然后深入开发它，或是……之后我们很快就决定的方式是——我们寻找的节奏很快，所以感觉我们不能……探索……

Jeep：

预测。

David：

预测，然后终止寻找说『这就是我们要将这个固定的设计变为产品』。

Tejeev：

我们从GDC回来之后，我们就知道了头显会在大约一年的时间里发售，我们想一起发售一些我们的内容，而我们不确定今后会是什么样的。

Paul：

我们知道规模会是很大的，但是我们内部有声明说要做VR版的Wii Sports。

Tejeev：

当时我们这么决定是因为我们不知道一年时间里能产出什么。就像David说的，我们不知道如何预测什么能在VR上运行，而什么不能。所以我们就决定做一堆小型一些的体验，就跟刚刚Paul说的VR版本的Wii Sports差不多。

Matt：

我们还没有在VR里做过一个游戏，当时都是小型的体验。将所有鸡蛋放到一个篮子里的想法当时并不是很吸引人，所以我们有了一堆差不多是随机的想法

Paul：

有一点不同的是，我们有期限。我们知道我们要展示点什么。

Jeep：

VR版的Wii Sports就是为了展示你能在VR上做的房间规模和有趣的东西的广泛度，展示能包容的不同内容，人们可以找到他们最喜欢的，然后深入挖掘。这就是我们的目的。气球和箭哪个先来？

David：

我记得是气球……其实在VR里我玩的气球是来自在于Steve Cody……

Tejeev：

对，我们的环境人员之一。

David：

他做了一个demo，你会在……我觉得应该我们模拟化了demo房间，就是那个放了很多MP10马克笔的地方。

Jeep：

一个在Valve的现实中存在的房间。

David：

是的。他也尝试做了AR。当你在那个房间的时候，天花板会打开，气球会倾泻而下，而你的脸上有一根针——我不知道为啥要这样。

Tejeev：

这个还挺有趣的，因为大家要全程这样做（用脸戳）。

Don：

我们在当时有了头显的原型机，电路板还暴露在外，人们也要这样这样（用头戳来戳去）。（众人笑）我记得当时有人被人用头顶了。

Kris：

一旦我们有了手柄之后，很多东西，包括握持方式都改变了。

David：

当时在做Secret Shop的时候，手柄的线第一次出现在了我们的桌子上。然后手柄，不好意思，气球、以及弓箭是我们第一批……气球是第一批我们开发的东西，我当时花了一些时间来学习如何使用这些东西，试图找出范围和可能性。当时有很多是使用了已有的资源，然后进行游戏实验，感觉就像是我有的是一个游戏设置，我们有很多有趣的素材，而我尝试用这些东西干什么。而气球工具是一个稚嫩的有意思的东西，就像是『喔，我做了个气球模型，我喜欢气球』，但是……（笑）

Paul：

你又不想事后打扫。

David：

是啊，我不会吹爆100个气球然后打扫它们的。做一个气球、托起它（balloon bop就是不听把气球向上拍让它保持在空中）、感受它的重量，这非常的简单和美妙。这就是如何做触觉技术的方法，让你相信触觉技术的灵敏度。

Tejeev:

气球的感觉在VR里表现的非常好，当你去打气球的时候，你的手就会自然地朝着气球所在位置……

Jeep：

会给你一点反馈。

Tejeev

轻轻地托一下气球，然后气球就会上去到那里，这个在VR里表现的非常好。

David：

然后就是长弓了。当我还小的时候，我很喜欢箭术，我住的地方可以在马路上做这个（射箭）。当我搬家到西雅图，并在西雅图长大的时候，我意识到自己还可以再做这个，我可以去买弓和箭。我记得我买了我的弓和半打的箭之后，我**到了山上，然后我在树上设置了目标，射完了所有的6支箭，每一支都射到了灌木丛中，再也找不到了，然后我就**回了家。（众人笑）当时我就觉得，需要有更好的方式（射箭）。

Paul：

开一趟车要多久？

David：

弓箭就成为了第一批带有手柄的体验功能，来尝试想象我们能用双手做的事情、尝试探索触摸技术——尝试探索这些领域、探索VR在这方面能做的多好。

Jeep：

你在VR里不会丢失你的箭。

David：

你不需要在现实世界中制作就可以做出这个动作（拉弓）。

Jeep：

而且你也可以做一些移动的靶子。

David：

对，我可以射气球。

Don：

我记得我第一次去你的桌子上尝试这个的时候，我都不想把头显还给他了，太棒了。

Tejeev：

最后我们的信条就是拟真现实世界物品，（将它）变成更好的或是更理想的版本。

David：

我们有些东西不好用，就是因为模拟现实物品得不够好。

Tejeev：

现实世界物品更好。

Don：

我们感觉就像在堆积木一样。

Tejeev：

现实世界中堆积木还挺好的，但是在VR就显得有点jenky（糟糕）了，不怎么好用、感觉上不大对劲。

Jeep：

你造了一个城堡，然而所有东西都有点……

Tejeev：

所有东西都显得摇摇欲坠的。

Don：

你的手指没有完全的触觉，你有的只是这种棒（状手柄），然后你就……

Tejeev：

我们就发现，只有在它比现实中的版本更理想的时候，我们才需要在VR中模拟它。

Jeep：

比如做一个巨大的弹弓。在现实生活中你不可能做一个巨大的弹弓。

Don：

搭起来可是很费劲的。

Kris：

刚刚你们提到的弹弓就是一个很好的可以用来搞清楚如何和比你现实所在更大的场景互动的实验。

Don：

弹弓就是在早期我们觉得自己会被约束在一个特定大小房间里的时候想出来的——我们会有一个房间大小的空间、我们做的所有事情都在这里发生。

Tejeev：

所以到了Aperture demo的时候，Aperture demo中的实际房间大小跟我们GDC上摊位大小是一模一样的，我们就是这么设计那个房间的。

Don：

就是为了展示跟踪信号能有多大。

Jeep：

最大的信号。

Don：

能达到的最大跟踪信号。我们知道并不是每个人都有放下Aperture的足够空间，所以我们得改造成……

Tejeev：

其实早在弹弓的时候，我们就有个实验。

Don：

是的，同样是由Steve Cody做的。他用PlayMaker（Unity3D VR脚本）在几天里就搞定了。他就……很酷的就是，它鼓励行走，你会到处走、使用到很多空间，同样也会影响到房间外的更大的空间，你会开始考虑，可能在房间外可以有一些东西。

Jeep：

看到类似远处的方块搭起来的塔倒下非常的酷，你感觉自己在这个很庞大的世界。当你摘下头显时，你会发现『啊，原来我在办公室里，刚刚是VR』。

Don：

是啊，我回到了四楼。我们有很多不同的变种。有一次我们做了个多人游戏模式，在里面可以相互射击对方的方块城堡。看着别人朝你发射炮弹、你身边的自己城堡倒下其实是很有趣的。

Paul：

『狗』实在弹弓那里开始的。

Don：

『狗』是弹弓里的一种特殊子弹类型。（笑）

Paul：

那个跟狗没有关系，它是……

Tejeev：

你需要澄清，你不能仅仅说是『狗』，你不是把『狗』射出去。

Don：

它会到你身后的传送带上。

Tejeev：

如果你把它拿起来，它会变成一个弹丸。

Don：

好吧，它变成了一个弹丸，然后你把它射出去。

Tejeev：

因为我们在弹弓里面有这么一个传送带，我们觉得没有好好利用它。

Don：

我们获得了一些反馈，说弹弓有么点……

Tejeev：

差不多180度……

Don：

就像是『嘿，这个不错，但是只有一个方向上的，只面向一个地方』——你知道的，VR非常酷，因为你可以看你身后，捡起身后的物品——，所以我们就把它（传送带）放到了那里。我们其实并不是特意做的，在那里我们有放了很多没什么卵用的东西，这可能就是我们做的一件事而已。

Paul：

那个狗狗子弹这个其实没有解决什么问题，所以我们暂停了这个。之后我们中有些人就开始对在一个点上玩接球（catch）游戏感兴趣——简单的东西是乐趣的一部分。我们有这个小狗一样的东西，然后我们就做了最简单的一件事情：当我捡起一个球，然后将它扔到空中，我们会看到狗在这条直线上跑，捡起球并把它带回来。

Jeep：

在这之前其实还有一样东西。我们有了菜单系统所必须的空间，这样你就可以把球放到脸上，然后丢到不同的区域。问题就在，第一个测试者拿到他的球并扔出去之后，他说，『我怎么拿到它？』

Paul：

当我们第一次拿到手柄的时候，你们手上有东西的时候最初就想做的是什么？

多个人：

拿起它，扔了它。/把它扔来扔去。

Tejeev：

当时的这个狗，我们就用这个原型来用狗接东西来做实验，非常地酷。我们就觉得我们可以用狗去解决其他的问题，比如人们把东西扔到了可玩区域之外而不能再取回。如果你扔了东西，狗会跑过去取回它。

Paul：

贯穿了整个Valve的一个关键流程就是，我们会测试游玩所有的东西。内部的每个人都会进行测试，我们也还会找一些别人。甚至在我们用狗取回东西的时候，我把我年纪还小的孩子带来，他看得津津有味。他并不知道VR是什么，当时他都不是很懂电脑游戏是什么，你给他手柄之后，他基本立刻就会用了。他看到了一些小东西在那里，看到了一个红球，他就会捡起来扔它。看着他们搞懂，这也是很有趣的。当然，因为他还小，他还是想要一只狗，非常地想要，他会说，『这是一只狗，我想要做这个这个这个』。每次有人来测试，他们的总是加入更多他们想做的，就像你（Jeep）之前说的。

Jeep：

他们想要拍它，想要抱起它，想要……

Paul：

就像是『这是VR，我知道一只真的狗能该做什么，而我想在这里也是这样的。』

David：

还有一点就是，我个人没有预料到能这么深入。

Paul：

我觉得没人能预料到。

David：

我觉得测试开启了……狗某种程度上增强了——我没有预料到这个——它增强了你对自己所处位置的相信程度，你看到了现实世界中的生物，而互动对于你来说就非常有意义了，将它看作是一个真实的生物。

Paul：

它变成了同伴。

David：

对。而且它会对你做出你预期中的反应，这让你觉得你是在这个世界当中的。这是非常棒的用于理解如何制作角色的垫脚石，他们作为一个能真实互动的角色最少要做到些什么。

Paul：

关键就在于我们给所有的东西都加入了很多微妙的随机性。全程总是会有好几个动画，而我们在动画库中也有一个巨大的网络，所有东西都有入口、循环和出口，也有一个规则集表示，『如果你在这里，你可以随机地走向所有这些其他的地方，通常会同时经过一些相同的循环，但最终会给这个东西生命。人们开始喜欢它，然后给我的反馈就是『我想要更多的行为』，然后他们就开始将它带入到其他的体验中了。

Tejeev：

就像在摄影测量（Photogrammetry，实际谈话中有人简称Photo，统一成Photogrammetry）场景里一样，在我们有这些场景之前，它们都是看起来很棒的场景，就像是真实世界一样，但是里面却没有东西。你只是进入了那面，看看场景，而人们就会问『为什么狗没有跟我在一起？为什么没有在别的场景里的那只狗？』现在我们已经将狗放得到处都是了。

Paul：

作为一个特性，狗其实只要在平面上走就行了，它不需要做任何事情。它什么都不用做。Photogrammetry场景到处都很崎岖混乱，我们……

Tejeev：

它还是有用的

Paul：

我们想出了好用的方法。

Tejeev：

这个跟增强体验差不多。它在Photogrammetry场景里面，感觉自己带着这只狗在这个世界中到处走。

Jeep：

它让不同的体验跟有相关性，因为之间有相似的元素。

Tejeev：

对，没错。

Jeep：

在Photogrammetry场景里，我们做的这些还是你被限制在房间的大小的情况下，你可以看到远处的东西，那些你想攀爬的岩石。然后我们就觉得我们需要让你能在这个空间中能走得更远。

Tejeev：

我们想要设计出在长弓和弹弓场景里一样的体验，在一个房间的空间里设计出周围的空间。但是在摄像场景里就是个问题，人们想要走出物理上的限制区域。我们之前做过传送的实验。

David：

是的，传送是我们最早做的实验之一，大概是在我们能用光学系统跟踪Xbox手柄的时候。它运作得挺好的，而且最重要的是，它不会让人感到反胃。我们把它放到了抽屉里，在很多其它实验中也用到了它。这个你（Jeep）应该运行了很多个。

Jeep：

是的，这里面也有些微妙的东西。当你从一个点传送到另一个点时，你不是直接以黑屏形式直接跳过去——这个感觉有点像blink（闪烁）。

Tejeev：

在Aperture demo里你尝试过不同东西，对吧？你试过go go gadget的手对吧？

Go Go Gadget. 非幻灯片图。自行找的。

Jeep：

哦对对。有一次我们想要发布为GDC制作的一个有巨大空间的Robot Repair，我们怎么让别的顾客也能用？我就尝试了一个实验，我们称之为『go go gadget arms』，就是你按下手柄上的按钮时，它会延长你的手臂，就像是一个放大器一样：如果手离身体的近，那么它们还是近的，当你越是伸出手，它们就会延长的越多。这样你就可以站在中心，接触到很远的地方，能碰到和操作所有东西。但是这里面还有个问题，你仍然可以打开装满了小人的抽屉，但当它在房间另一头时，你不能低下头近距离地看抽屉里面的东西。所以这个并不是一个足够好的方法。我们在Secret Shop中也用了，但是在Photogrammetry场景中开始使用传送之后，我们就觉得我们应该将这个运用到其他场景中。

David：

就像我们一直都在解决的，如何构建更大的空间、如何让——我们是应该构建小房间实际规模的空间还是……我们知道我们想要有构建更大空间的能力，我们也需要这么做，我们需要行动起来。所以我们就像当时所有人一样开始寻求解决方法。

Tejeev：

实际的机制。

David：

我们花了挺长时间来缩小范围并认同我们要在The Lab中做成一样的。

Tejeev：

传送运作的实际机制也经历也很多次的迭代。最早的版本中，我们是以注释为基础的，你按下一个按钮然后看着你要传送的地方。这背后我想到的是，如果你一直朝着你要前进方向看，你感到不适的可能性会更小，因为你总是对你要去的地方有参照系。但是人们却被它困惑了，在没有跟踪技术的Xbox手柄上这个运作的很好，但是一旦有了跟踪手柄之后，人们会指（用手柄指向目的地）。

David：

一旦它（手柄）是被跟踪的之后，就算你告诉他们是以注视为基础，他们也会做……（用手柄指）

Tejeev：

比如人们会『我要指着这里』。

David：

我们最后妥协了，接受了反馈。

Tejeev：

对，我们开始做你的手指着，而你可以看着——大部分人会看着指着的方向，即便他们没有朝那边看，我们也发现这样传送其实也不会给他们带来什么不适。我们也看了Budget Cuts的视频，他们在游戏里有一个传送的弧线，我们都觉得有这样的弧线更好，因为这样就利用弧线的方式限制了你能传送多远。

David：

没有这个的话，我们就有个问题，很微小的手部活动会很大程度上改变你的……

Tejeev：

是的，因为我们的传送线是无限延伸的，你做出了细小的改变也会完全改变你要去的位置。而弧线就可以让你去比你高的地方，这样你就可以用传送爬上悬崖了，这个运作得更好。最后我们也用了这个解决方法来使用到所有的体验中，也是为了统一成一个系统、并在所有体验中能运用。

Kris：

我们还有一个问题，就是人们会把自己卡在角落。

Tejeev：

是的。这是我们也意识到的。在虚拟世界中人们会传送到一个点，然后在这个空间里移动，然后再传送回之前的位置，但是我们意识到这跟上次我们在这个位置是不同的地方，因为他们在物理上在这个空间里进行了移动，而他们现在可能已经在房间的角落里了。

Jeep：

这个比较难形容，你可以试试看。

David：

我们需要解决这个新发现。玩家的概念不再是这个化身（avatar）、空间里的这个点，它还需要带入玩家的物理环境以及它的大小和里面的障碍物。我们想了很久的解决方式，如何应付或是在设计上摆脱这个麻烦。

Tejeev：

比如有多少需要玩家来搞清楚的。

David：

我们最终发现，我们实际上需要接受玩家需要形成并理解一个新技能。他们需要……在最舒适的VR体验中，他们需要理解他们自身跟自己的房间、自己的区域的关系。我们最后通过设备向玩家传递更多信息，体现平衡……

Tejeev：

我们现在会给他们提示，当你传送的时候，我们会显示房间的边界，也会用一个圈表示结束传送的时候你会在实际房间中的位置。这样就帮助人们能知道『我要传送的话，应该向右走一步，这样我就在房间的正中央了』，然后再传送。

Don：

我认为重点就是，VR非常棒，它可以让你把自己带入到虚拟世界中，但是有一点很糟糕的就是，它也把你的真实世界带到了虚拟世界中，而它会一直跟着你。

Tejeev：

这就是我们需要解释的。

Don：

对，我们需要解释这个。

Tejeev：

我觉得最后的效果还不错，传送在我们的内容中运行的相当好。

David：

在我们的内容中。我们也避开了一些我们已知的会更难的体验。

Tejeev：

我们特意设计了不需要很多运动的东西。我们大部分的游戏中，你是在一个点上的，不过你可以在你的房间里到处走。在Photogrammetry这样没有现实和时间压力的情景中，你可以到处传送，和那只狗玩耍，而我们为此做的系统也是好用的。我们做的一部分互动内容也是——回到我们的理念——，就是尽量模拟现实世界里的、但是能做出更好或更理想化版本的东西，然后把它们放到我们所有的体验中。

David：

我们有很多的……我的意思是，纵观所有的体验，它们其实是完全不同的，但老实说，在最终都非常的接近（殊途同归）。在每个当中，我们都在独立地做UI和交互的探索，所以相当长的一段时间里，就是手柄能用了、手部能用了，基础UI有些不同、我们在找我们偏爱的那个。

Teejev：

最终我们发现，对我们的内容来说最好用的是当手部手柄能代表你的手的时候，而不是其它的抽象化。

David：

我们不觉得自己能做出令人信服的手部模型，所以我们决定……

Teejev:

只展示你的手柄。

David：

是的。这是非常取决于游戏的，但我觉得你需要的是一个绝对的……我觉得不是手部呈现，而是姿态的程序，你可以看着一个东西，然后就知道它是跟你手里拿的是一样的，最大化跟踪的精度。

Teejev:

回到我们最初的GDC demo上，那是人们第一次『啊哈』的时刻。当你给他们戴上头显，给他们递过手柄，他们就会『啊我可以拿到这个现实世界的物体，而且它也可以运行』。

David：

给人递过跟踪手柄永远不会倦。

Teejev:

是的。

Kris：

我们刚刚谈了如何做设计、UI设计，找到如何将它与现实中的UI分割开来也是我们面临的一个挑战。

Matt：

在当时，我们有了刚刚我们谈到的一些demo，这些都跟我们参考的枢纽计划差不多对吧？每个体验都有一个传送门，整体就是一个大杂烩，只不过它们都展示……

David：

我们观察到的一个现象就是，在我们进行游戏测试过程中，在VR出现之前人们会谈到的是『我要去玩游戏』，『我去了、然后做了这件事』，而在我们早期的实验中，他们会谈到自己是去不同的体验中参观不同场景。而对于『脸球』（face sphere），我们就没找到过合适的名字。（笑）

Teejev：

『脸洞』（face hole），这个不错。

David：

『脸洞』（face hole）。

Don：

Aperture脸部安装传送球（face mounted portal sphere）。

David：

这个是来自于一个想法的探索，VR体验总是会在一个地方，像是一个你能访问的现实地点。因为我们在VR中我们也可以呈现这样神奇的形式，这是……我们处于试图搞清楚的状态、我们知道我们试图将体验合在一起，我们都知道我们要把所有不同的体验都放到一个包里，而我们不想……我们觉得将它们放到菜单里是错误的，这样感觉起来……

Jeep：

是的，而且对于大部分的开发来说，我可以说是90%到95%，它们之前并不是叫The Lab，也不叫别的。

Matt：

它们之前叫做迷你游戏。

Paul：

它就是一堆大大小小的东西的组合。

David：

由Valve呈现给你的。

Paul：

所以我们有个地方叫做枢纽（hub），这里有所有的小球，你就可以……

Teejev：

枢纽只是有一张桌子的白房间。

David：

它只是个纯实用性的东西，对吧？

Teejev：

是的，它是个……

David

你能开始其它东西的地方。

Teejev：

它就只是个白房间，里面有张桌子。我们有个办公室桌子的模型，有人做了上面的抽屉什么的，我们就把它放到了枢纽里，然后在桌面上放上不同的虫洞或是说『脸洞』，就是这样而已。我们看到过人们想要跟枢纽互动，他们想在枢纽里做点什么，甚至有些很简单的互动比如他们想要把球拿起来放到抽屉中，再关上抽屉，然后他们回来之后会觉得它会在之前他们放的位置。就像是『哦，我在桌面上整理了它们』。

Paul：

是的，有些人会为此而困惑，而有些人会害怕，他们会觉得『是谁动了我的球，我没有把它们放在那里啊』。（众人笑）

Teejev：

但是枢纽在当时很大程度上就是一个功能性的东西。它不是……它就是让你把『脸洞』放到脸上的地方，仅此而已。

Matt：

它在将体验整合起来上也没有做出什么贡献。有这些小的『窗户』连接到不同的世界中，但是感觉就是『为什么要这样？』

Kris：

这就是我们之后做出了很大更改的东西之一。在Valve，我们有一个流程叫做『overwatch』（并不是守望先锋），就是当我们作为一个团队决定我们要带几个有丰富的发售经验的人过来，让他们在家进行体验，在没有我们在一边拿着笔记板（clipboard）旁观的情况下进行游玩。在没有被观察和没有被过滤的情况下，我们将他们带回来给我们提供他们的反馈，这就是很好的一个机会来听到很多比如，他们在我们的产品中看到了哪些我们错过的机会，或者……有些已有的反馈是要再三强调的，甚至是找到新的反馈、新的提升游戏的方法。

David：

是的。这是你在快要发售的时候要做的。你想要某种程度上验证你所在的道路、谨慎地检查它，确保……

Paul：

马后炮一句，我们应该早一点做的。

Tejeev：

是的，我们在1月末才做完，

Don：

当时是多久来着？好像是10周，在我们……

Paul

发售之前。

Don：

……可能时间不够长。

David：

不过它对于我们团队来说真的是非常有用和关键，因为我们已经开始想要把体验合到一起了，但是它们并没有，你不能……

Tejeev：

它们还是分开的体验。

David：

它们还是太分开了，你可以感受到它们过于分开、过于没有联系。然后我们就有，这时候我们……我们其实之前提出过这个想法，它不是无缘无故的出现的，但是这时候才是我们正视将它们带入到Aperture世界、某种程度上明确接受这些都是实验的想法，它们，像是……

Tejeev：

它们是实验，但是它们也是Aperture实验。

David：

也是Aperture的，我们就是Aperture，我们也是……

Tejeev：

是的，就像是『谁是Aperture』，『谁是我们』，非常让人困惑。（笑）

Kris、Paul：

So……

（Paul做了个手势让Kris先说）

Kris：

我刚要说……（做了个手势让Paul先说）

Paul：

你可能要说的跟我一样。（还是让Kris说）

Teejev：

我来猜猜看。

Kris：

它引起了我们的重新关注——我们还没有在枢纽上做过很多的开发，因为当时我们都在深入开发其他的体验中。在我们经历过『overwatch』之后，它某种意义上强调了我们需要关注的紧急事态，不仅仅是我们需要找到一个将它们打包的方法，而且还有我们剩下了多少发售前的时间。所以我们……决定，我们要搞清楚如何在Aperture中是怎么设置的，然后我们开始对它进行修饰，搞清楚我们在The Lab体验中需要什么样的功能。很多的功能慢慢地开始上线。

Teejev：

我记得我们在『overwatch』会议之后开了一个很长时间的会，我们都做了很多的头脑风暴来想清楚The Lab。我们之前说了，这是一个Aperture世界，我们会在放在一个像口袋宇宙的办公室环境中，因为我们已经将隔间（cubicle）、办公室什么的打造成了一个非常丰富的办公室环境，有很多你可以互动的东西。

Kris：

我们从那个会议出来时——这是一个大概90分钟的会议——，我们出来时就有一块写满了想法的白板。

Paul：

我们非常激动。

Kris：

我们非常激动，『喔，我们要做这个了，这个太棒了』。我们坐下后，有人展示给我们看Job Simulator的trailer，然后就……（垂下了头）

Teejev：

我们就像是『哦，他们也做了这个格子办公室』，『我们需要重新想一想那些东西了』。

David：

是啊，『我们需要再做一次了』。

Paul：

所以我们采用了这个类似的屋子。既然我们不做办公室了，那我们就在实验室里做。里面有科学家，他们在实验找到的文物（artifacts），每个文物都能拉取出它们在虚拟世界里的场景，他们则试图自己进行体验。

Matt：

是的，那些小人不能理解从人类世界中发现的文物，它们试图拉取出来并进行体验。让他们自己能体验，所以你进入的是他们的世界。

Paul：

你会有一些明信片，而这些都是现实世界中的地点。你会有一个大拱门，那就是箭术的地方。你会有一个街机叫做Xortex，是一个复古的街机射击游戏——它的美学就是这样的。

Kris：

你刚刚提到了Xortex，Xortex是经历『overwatch』流程之后改变最多的。在早期的迭代中，它是一个RC chopper（remote control helicopter，遥控直升机）游戏，是遥控的。

Matt：

回到你们之前所说的，模拟现实世界中的东西，选择做你能让它比现实生活更好的那些。我们有一小群人觉得在现实生活中看别人玩RC chopper是很好玩的，但是一旦你自己尝试了之后，你就会再也找不到它。（众人笑）所以我们很确定所有在Vive手柄里的技术可以将这个体验做得更好、更直观，我们就开始做这个类似Bullet Hell的RC游戏。我们还进行了大量的测试，在其本体和The Lab之外也测试了，直到我们认为非常成功为止。在单独地来看，它运行得非常好，人们也能理解。举个例子，如果你在实验室里玩过玩具飞机，你知道控制系统通常是什么——你拿起手柄，里面的陀螺仪会给你相对方向的提示，告诉你飞机会去哪里。它很有趣，也能运行，但是覆盖在它的控制系统上的一层不能良好地运行，尤其是你有一些能立刻获取的东西，比如狗的时候，你知道事情会……

Paul：

所有东西都是真实的交互，所有其他体验都是真实交互，你在做一件事情。

Matt：

没错，狗这样的东西也是一个完美的不需要介绍的元素。你看到一条狗，你看到了一个红球，你完全知道你需要做什么。而这个却需要很多的教学。

Paul：

你们甚至做了一个训练。

Matt：

我们花了好几周想要把学习曲线做得更好，但是当……

Jeep：

单独地来看，它能运行。

Matt：

是的，当然。

Jeep：

测试Xortex，人们会感到乐趣。他们已经学会了它，并有了乐趣。但是在The Lab这个背景下，有所有的其他的有非常直接的一对一控制的游戏，当他们尝试到这个RC的东西时，他们会把直升机撞到墙上，然后说『好吧我要回到那条狗那里』。

Matt：

『我要退出，我要去跟狗玩』。

David：

我们解决的一个反馈就是，发现每个体验都要在它们要强调VR的那部分上更纯粹和提取。事实上Xortex有的抽象化的控制是违背这个的。就像是你站在房间的一个地方，而手柄在使用运动控制、但是却是抽象化的。在『overwatch』之后，我记得你们试了很多不同的控制布局图。

Jeep：

Zach一天尝试了大概10种不同的方式，而它们都感觉有点奇怪，只有一个是『哇靠，这个太棒了』。

David：

当他无意中发现那个直接控制的时候，它突然就点醒了我们。

Matt：

产品开始……产品的剩余部分汇集到了一起，而且很清晰地知道哪个会感觉上是完美产品的一部分。

Paul：

我们没有提到的一点是，Xortex曾经差点就被完全删掉了。几乎是在最后时刻，我们才准备发布它。

Matt：

是的，如果我们没有发现一个能用的、不需要教学的控制系统，它是不会成为发售的一部分的。

Paul：

它其实被润色得很好，当时它已经是被润色的最多的了。它真的很好，也已经完成了，刚刚好就是那样的，而且我们也希望……

Matt：

但是它不适合产品。

David：

它不适合这个产品。这个产品需要展示所有的感应和运动控制，以及所有的可能性。事实上它本身是一个很有趣的游戏，但是控制会让人们有时候对手柄感到沮丧，感觉完全不对。这就是为什么它需要……

Matt：

我知道控制布局的真相，它有着一定的深度，需要一定的学习空间来获得提升、熟练。但是这对于The Lab来说是不符和，它在这里是不重要的。我们需要的直观性和用户友好度。

Jeep：

它也创造了新的机会，因为你在你的面前有这么一小架飞机，然后你可以将它飞来飞去地『biubiubiu』射击所有东西，这鼓励人们能在房间里到处走动来进行躲避。

Matt：

这个完全是个意外。我们都不知道会变成这样。我们缩小了房间，你就拿着那个东西……我们固定的规模足够给任何人在任何区域可以在几米的范围内移动并躲避子弹。

Don：

所有的美术也在这个比例下好多了。

Jeep:

最初的RC，是在一个更大的空间下，你是飞进去的。但是一旦我们将所有东西缩小到你可以到处移动的大小之后，你可以看到所有的小型飞机，非常酷。它们都有非常多的high poly细节，在这个比例下看起来非常非常棒。

David：

我觉得我们的结构有一个优势就是，我们可以在很晚的时候做出修正的过程，就像这个一样。因为我们做的都是都是模块化的，所以其中一个有问题也没关系，因为我们知道……

众人：

是的。

David：

我们知道我们有……

Jeep：

如果Xortex是跟所有别的东西有关联的，那么我们就不能只是突然地砍掉它或是大幅度地改变它。它是非常独立的，这样我们就可以做出一些大的更改。

David：

是的，如果它有……如果它们中的任何一个要消失，我们的结构可以让这样的事情从容地发生。

Kris：

关于我们设计Xortex的方式，我想要加另外一点东西、另外一点好处。它论证了一种游戏的类型，它不是关于玩家自身、不是关于作为游戏角色到处移动，而是有一种在游戏里控制的东西。它论证了这么一个不同的方式，成为了一个更有趣更直观的体验。

Matt：

我们的最初目标就是为了控制不是你自身的东西，把你在VR中的形象抽象化。我们最终就用这种完全不同的方式完成了这个目标。

Jeep：

我记得所有这些大的改变都是在GDC前的两周——也可能是GDC前一周。

Kris：

是的，改得很快。

Paul：

有那么近吗？

Jeep：

非常的接近。

Teejev：

非常的惊险。

Jeep：

我们一直在尝试将我们想要在GDC上展示的东西放到一起，所以我们展示了一大堆不同的游戏和空间，在最后给了人们10秒钟的时间来看『实验室』，因为它当时完全在建设中。

Paul：

它当时还么有什么用。

Teejev：

嗯。大概在发售前三周（才做了实验室）。

Matt：

在最后两个月，整个都发生了戏剧性的变化。我们是发售前两个月我们做的『overwath』吗？还是两个半月？

Paul：

三个月。

Matt：

好的。在GDC上稍微有涉及这个，所以也是我们第一步用来看我们对反馈所做出的反应最后有没有用的地方。

Paul：

是的，我们在GDC前的最后时间做了一点点测试，这样我们就可以做一些反馈的东西了。我觉得很有趣的是，即便The Lab来得很晚，所有的不同奖杯——或是你想它叫什么，你从体验中获得的东西拿到中心花了很长很长的时间，即便是在枢纽中。

Teejev：

是的，我们有这个想法，你访问了这些空间，当你回到枢纽的时候，你已经从这个空间随身带了一些东西回来。比如你去了长弓场景，然后回来了，在枢纽中就会有一张弓和一支箭。

Paul：

你们经常做的第一件事情就是『喔，我们拿到了一把弓。喔，这里有条狗。』（众人笑）

Matt：

是的，第一次狗和弓组合的时候。

Teejev：

当时在办公室里是一大讨论话题，『当你用弓射狗的时候会发生什么？』

Don：

我错过了最初的长弓场景的奖励，你会在里面获得一个箱子，箱子会……

Teejev：

因为在箭术场景的后面有个传送带，会有些机器人在做些伸入箱子（拿箭？）之类的事情，所以当你回到枢纽的时候，会有一个巨大的箱子等着你。当你走近的时候，狗就会从里面跳出来。

Paul：

像是『外星人』（Alien电影）里的情节一样，跳到你的脸上。

Teejev：

这像是一个诡异的无意中的jump scare。

David：

我们对应该发生什么争论过很多，而他（Teejev）对此有很多乐趣。

Teejev：

最初我觉得应该发生的是——因为这关系到代码如何运行——，当你射狗的时候，一支箭会刺在里面。因为在代码层面上，箭就是『如果我射到了什么，那么我就会刺在什么上』。而狗就会变成『豪猪狗』一样有很多箭在上面。（众人笑）然后我们就觉得『喔，这太棒了，如果狗还能把箭抖落』之类的，这样就变得更复杂了。

David：

我们发现实际上，它怎么做几乎是不重要的，重要的是你需要有一个可信的反应。你不会想要伤害……显然不想伤害它，但是……

Teejev：

如果箭只是从狗身上弹开而不产生任何影响的话，这完全不会让人满意的。

David：

我们将这些毫不相关的元素放到一起，然后我们突然发现，『哦，这个需要以一个你能相信这个世界的方式做出反应』，你不能让它摊开，你不能看到狗无视了它，狗需要知道发生了这个。

Teejev：

当我们把东西放到实验室区域——那个有些小的Aperture里的人在到处跑的地方——的时候，我们发现你应该可以射他们，因为你在长弓场景里面可以射他们。你需要保持这种一致性，让这些单独的游戏看起来是一个整体。

David：

当我们在构造枢纽的时候，有很多的……我们一直都约束我们自己，因为我们发现每个我们放进去的元素需要跟其它的元素进行互动，我们就不停地剔除那些看起来应该可以互动但实际上不能的模型。我们在不停地删除啊删除。

Paul：

我们做了一个大的表格：如果我们将这个放进去，它需要跟所有其它的东西做X、Y、Z这样的事情。

Matt：

Jubson当时做了非常棒的工作（众人点头称是），给我们展示了这是多么重要。如果你看到有个东西长得像它，那么它的行为也应该跟它相似的东西一样。

David：

如果你回过头看其他的The Lab体验的话，你会了解我们是如何探索的历史。就像（Secret） Shop和Aperture比我们最终开发出来的互动性更少一样。

Teejev：

在Aperture demo的桌子上，我们有很多完全不能互动的小道具，因为当时我们没有手柄、没有时间，也不在我们的计划当中。而在制作The Lab的时候，我们需要进步，将它作为最优先的东西——每个东西看起来能互动的都应该能互动。

Don：

基本上每个人在Aperture demo中都会看示波器和那个小的雅典雕塑，他们就像是『耶，我要拿起它』。

Teejev：

每个人都去打了电话。每个人都拿起了电话去拨号，但是当时什么也做不了。

Jeep：

是的。我们想要在这些场景中做更多，但是既然它们是从更早的GDC和TI（The International）中来的，我们就把它们保留在了最初的阶段。你仍然可以到处传送——虽然有些不同了。在Secret Shop中，我们加入了控制器，所以你可以拿起台灯到处走来照亮别的东西。我们基本上不动它们很久了，我们只是更新了它们，让它们可以和运动控制一起运行、并能到处传送。我们就让它们留在了以前的状态。

Teejev：

没错。

Jeep：

嗯。

Kris：

这下你们明白了，这就是为什么我们制作了The Lab。（众人笑）

David：

我们是要结束了吗？

Kris：

如果你们有什么问题，我们会在外面闲逛——我们这次谈话没留时间给问题，不过如果你有问题，我们在今天剩下的时间会在外面闲逛，过来找我们，问我们问题，我们希望能帮助你们把你们在做的东西做得更好。谢谢大家。

Teejev：

希望（这段谈话）是有帮助的。

Kris：

希望什么？

Teejev：

希望是有帮助的。

Kris：

（笑）非常谢谢大家。

（观众掌声）

17. 游戏心理学

By Mike Ambinder (Valve)

图17.1

感谢大家的到来。非常感谢你们花时间来跟我一起了解这个。我的名字是Mike Ambinder，我在Valve是一个实验心理学家。

图17.2

这个是我大部分时间在做的。（笑声）这就是我怎么度过我大部分时间的。我其实并不是一个临床心理学家，Gabe需要一些工作，但其实不是我的专业领域。我是个实验心理学家，我从事的是将心理学上的知识和方法论应用到游戏设计上，考虑知识和人类行为会如何影响到我们做出的选择。

图17.3

对不熟悉心理学的人简单的总结一下，它就是对人类行为和其影响的研究。心理学家通常做的就是，我们会找到行为的规律或是模式。人类对特定的情况的反应在某种程度上是可预测的形式，而心理学家就试图找出这些形式和为什么发生的原因。

图17.4

在游戏设计方面，我知道所有人都有他们自己对游戏设计的定义。在这里的每个人都有他们自己的……为了方便这次演讲起见，我们要首先有个共享的背景，我会定义游戏设计是『一系列呈现给玩家的约束、选择和系统』，通常这些约束、选择和系统『会引起一个行为或是反应』。

图17.5

我们的愿望是可以利用我们在心理学上已知的东西、关于人们可能会反应的可预测行为，将它们运用到游戏设计中，引起各种各样的反应和特定的反应。

图17.6

这是这次演讲的大纲，我会讲这么7个不同的话题，希望会能包含一些关于玩家如何反应的新颖或是令人惊喜的信息。我会谈到『注意力』、『偏好的形成』、『认知偏差』（cognitive biases）。我还会谈到『内部参照』的不可靠性、我们用于合理化解释为什这么做的能力。一个例子来说明为什么我们使用一个叫『认知失调』（cognitive dissonance）的现象，来减少玩家在Dota中的『毒性』（toxicity）。我会用几张幻灯片讲一点『玩家力量』（player agency）。最后会以讨论『动机』结束，『如何保持玩家玩我们的游戏？』、『如何然玩家参与到我们的产品中来？』

图17.7

『注意力及其不足』。这可能是一个有暗示性的标题，不过中心思想是，在有注意力……需要牢记的一点是，我们对这个世界的关注远比我们想象的要少得多。

图17.8

我来告诉你们，你的注意力在哪一块区域。如果你伸出你的手臂，然后竖起大拇指，在手臂这个长度的拇指宽度，这就是你真正在积极关注的环境。我们很擅长于迅速转换移动注意力，而在游戏中，人们也必须大量地这么做，但是注意力的范围差不多就是你环境中的这样的一块了。我们仍然能意识到这块区域外的东西以及能吸引到你注意力的东西。

我想要指出的一点是，如果这是注意力区域（伸出手），玩家们在我们的游戏中可能没有他们想象中看到的那么多。实际上，对这个世界的关注远比我们想象的要少得多。我们的大脑其实非常擅长于创造一个对世界的稳定表现或是幻象稳定表现，而且我们也相信它，但是我们并没有我们想象中那么关注这个世界，而集中注意力也是需要努力的。我们会要求玩家在游戏中集中注意力，参与到战斗中、寻找物品、进行驾驶等等，而集中注意力也是需要努力的。我不会给你们一个特定的例子来讲这个。

图17.9

我想要谈论注意力是因为，对于游戏设计来说这是有意义的。所以我们来看看，可能这些我们都知道了，不过只是为了给你们一个注意力是如何起作用的背景知识。

有很多种方式可以引起注意。突然出现的东西会引起注意，我们在游戏里经常这么做；颜色的变化会引起注意；若隐若现的运动会引起注意，这其中有一个进化的因素，如果一个物体突然提高了在你视野里出现的量，那么它可能就是值得引起注意的东西，比如威胁什么的，所以我们天生就对若隐若现的运动和大小的变化敏感。同样地，我们在游戏里都会用到这些，没有什么好惊讶的，我只是强调了一下背景知识。

另外一点我想说明的是，并不仅仅是物理上的刺激可以引起注意，比如颜色、大小、运动等等，同时跟注意目标也有关。举个例子——心理学家叫它为『注意定势』（attentional set），而我用的是『注意目标』（attentional goals）这样的词，因为没觉得这样更明确一点——，如果你在一个房间里寻找你的朋友，而你的朋友是高个子金发，你可能更会注意那些个子高而且金发的人，可能更少会注意到个子矮和深色头发的人。这就是注意目标的一个例子，它会给你在那样的环境下注意的东西加上一个范围，而人们也在游戏中利用它：如果你在寻找金币，你会跑向游戏内金色的物体，对吧？

所以在游戏中，玩家们经常会忽略、也能忽略非常明显的、让人惊讶的东西，我们给你们看看在游戏中是怎么样的。这有一段视频，是我们其中一款游戏Counter Strike的，里面有两个队，互相要杀死对方，这里双方都只剩下了一名玩家。实际上这个视频仅在两周前发生，所以是非常偶然的一个时间。我来给你们看看发生了什么。

图17.10

（视频略，总之就是一个电子竞技不需要视力的视频）

（播放过程中）应该是有声音的。你们能听到？好的。

（主视角CT，已死亡玩家声音：『他在那里，在那里。我告诉你了，**！看你左边，左边，就那里！左边！左边！！Yuha！右边，花坛，花坛！在你后面，Yuha！Yuha，他就在那里。往下看，往下看，往下看！在你身后，Yuha！就在那里！哦我的天啊！他就在那里啊，**，Yuha！他在那里，看！（主视角打死了最后的T）你个傻（哔）！我的天啊，Yuha！（拆弹失败，T获胜）我的天啊，Yuha，你真是个傻（哔）啊，Yuha』）

（观众笑声）

我们不得不消了些音，因为这是一个公开的presentation。这个人玩Counter Strike非常不错，如果你刚刚在看的话，他很清理角落，他的准星也是放在他觉得人可能会在的头部高度的位置，但是他最终没发现的是有个人在他屏幕的中心，只是蹲下了，就在他的视野中心下面的地方。他没有发现他是因为，他没有预料到那个人会在那里。他玩的是Counter Strike，人们会躲在一些特定位置，他们通常不会躲在开阔的视野中，所以他的注意目标就是『我要看看所有常见的人们会躲的角落』，而不会看到他们实际所在的位置。所以这个跟大猩猩视频（就是那个让你数人传球多少次，偷偷走进去一个扮演大猩猩的人）的发现是差不多的，对吧？当注意力集中、或是注意力被指引的时候，他会使用他作为一个高水平的Counter Strike玩家已知的可预测的线索。你会忽略非常明显的东西，包括你在找的东西。

图17.11

这一段的含义就是，非常明显的目标可以隐藏在非常显眼的地方。如果你了解你的玩家的注意目标，你可以在他们注意力集中在别的地方的时候给他们一些惊讶，反过来，你也不要在他们忽略了很明显的东西的时候感到惊讶。理解注意目标是什么，可能你给玩家的线索就在指引他们错过什么。比如，如果他们专注于攻击敌人，他们就不会关注寻找出口的线索。考虑你给玩家的注意目标，当他们错过明显的东西的时候，尝试去理解为什么，并且利用它。比如你可以在注意力集中的时候做出很引入入胜的、新颖的、惊人的体验。

可能这个主题还不是我现在说的，不过引入逐渐改变的概念是非常重要的。我谈到了突然的出现，它们只是出现而已；如果你用的是慢慢地消失在视野中，那么由于这中间没有非常强的改变信号，人们更有可能错过它。所以逐渐改变环境的想法，会让人们很难注意到——这个你们可以记一下笔记，我也很乐意在之后谈到更多。

图17.12

前面我们谈到了注意力会失效的地方，接下来我们要讲的就是可能不会失效的偏好，它的构成方式。

图17.13

我指的『偏好』就是，你喜欢的东西是什么？我认为我们中有很多人会相信，我们倾向于喜欢那些……至少内部是客观评价……我们自身反应是愉快的东西，我们想要标准化这一点。而我想要给你们的一点就是，比起人为来说，偏好可能是更随性的，这对游戏设计者来说就带来了一系列结果『为什么玩家喜欢一个特定的游戏，而不是别的？或是一个游戏内特定的策略，一个角色、武器、等级、游戏模式。』这只是因为，所有人都在做他们关于哪个最好的内部计算吗？还是说有其它的东西在起作用？

你们可以通过我这次演讲里的所有leading questions（引导性问题）来猜测：其它东西在起作用。

图17.14

这是Dota中的角色列表，Dota是我们的一款游戏。你有112个角色，两个5人团队，每个人都要选择一个角色，有这么一大堆的角色。

图17.15

如果我要求对你最喜欢的英雄排序会怎么样？告诉我，你在Dota中更喜欢那些英雄？你会第一个说敌法师，因为他显然是最好的Dota英雄。军团指挥官第二，然后是帕吉、圣堂刺客、娜迦海妖、天怒法师（明明是陈）、风行者，这么依次排序下去。你会给我一个Dota英雄的排名，这个还不错。

图17.16

但是心理学家发现的是，如果你做点别的事情，比如我告诉你『这些英雄是别的所有人喜欢的』。这个是在大量玩家基础下的集体平均偏好，他们是不一样的——这个是你说的（返回了上一张，又回到了这一张）；这个是他们说的，血魔、巨牙海民（明明是熊猫酒仙）、灰烬之灵等等。这之后发生的是，我会说『你有了玩家群体的排名，现在你的排名是什么？』

图17.17

你的排名会改变。这会在多种情景下发生，心理学家已经对此进行了大量研究，而结果，从某种程度上来说，我觉得是让人吃惊的。我们的偏好会被其他人的想法所影响，这还算好，但是我要说的重点是，『我喜欢的东西发生了变化，仅仅是因为你告诉我别人喜欢什么』。这一点非常重要，因为我们经常在外面的游戏中做这个。我们给玩家提供别人喜欢什么的线索，我们作为游戏设计者喜欢这游戏的什么，那么玩家就会对此作出反应，偏好也会随之做出适应和改变。

图17.18

这就是一些我们作为游戏开发者在游戏里做这个的例子，暗示玩家们去改变偏好。、在最上方是Dota的教学模式的截图，我们在里面放了三个英雄，龙骑士、矮人狙击手和暗影萨满。因我们觉得『嘿，新玩家们，你们需要玩这些英雄』，这就给他们暗示说，『开发者某种程度上偏爱这些英雄，这会影响我对游戏质量的评估』。

左下角的这个图片是职业玩家在一场游戏里玩的英雄，我们在Dota客户端中将此展示给玩家。如果你看到职业玩家使用了不同的英雄，这也是一个社会认同（social proof），也暗示你应该玩什么样的英雄、你的偏好应该是什么

右下角是Counter Strike的地图选择界面，左上角的是Dust 2，然后是Train、Mirage、Nuke等等。我们就是在表示『嘿，玩Dust 2』，就像我们在隐形指导你一样。那会是你最开始就注意到的地图。我们作为游戏设计者暗示你去喜欢Dust 2，而这最终也会影响到人们会比在随机地图选择界面下更喜欢Dust 2。

图17.19

这就表明了社会认同会决定偏好、别人的想法会决定偏好，我们作为游戏设计者在游戏中传递给玩家的东西会并可以决定偏好。那么如何将信息呈现给玩家，并深刻地影响到玩家喜欢你的游戏中的什么东西呢？我们希望出现的是对质量的客观评价，但是人们却受指导决策的暗示影响。我们一直都想让自己轻松点，我们的大脑会自动这么做，所以如果游戏设计者给了我应该喜欢什么的暗示，我会更有可能去喜欢它们。

我想说的另一点就是，玩家会选择『默认』选项。在心理学中，这是一个著名的偏好。比如，如果你可以在四个选项中进行选择，无论哪个是被列为『默认』的，通常人们——不仅仅是游戏中的玩家，而是整体的人——都会更倾向于默认选项，因为这是指导决策的暗示。在游戏外是这样的，在游戏内也是这样的。

让我们回到前面的地图选择页面，如果你真的想要了解一张地图的真实受欢迎程度或是质量，在你的游戏中随机化它们的位置，人们可能因为它在地图列表的顶部就喜欢这张地图并且玩得最多。经常做出改变是不现实的，不过只要明白：如果你的游戏有一个特定的结构，它就会局限化偏好、它就会影响偏好。如果你真的想要完全遵从客观评估，想清楚如何去除你提供的这些社会暗示的方法。

图17.20

以上就是偏好可能不会失效，但是至少会受到严重影响的方式。接下来我们要谈论的是一些认知偏差，就是人们在做出决定时，大脑容易出现的系统偏差。

图17.21

我们没有想象中那么地聪明和理性，这并不是一种贬低性的说法，而是现实就是这样。为了效率，我们的大脑会使用启发式思维模式，来帮助我们探索世界、度过一生，但是问题就在并不是影响我们对情况的判定所有东西、所有因素，我们都有清醒的认识。我们在很多东西上都很清醒，而有一系列的流程是在清醒认识的层面之下进行的。你的大脑要做很多的工作，心理学家们也研究了一阵子了，我们的大脑会以某种可以预测的方式发生偏差，而我们希望能把这些偏差利用到制作更好的游戏中。我要将关于……我在最后有一个列表，不过现在我要详细地讲其中的两个偏差。

图17.22

首先就是『锚定』（anchoring）。我们是相对地做出选择和评估，我们一直在寻找比较所要的基准线和门槛。结果就是，我们倾向于『锚定』在初始呈现的一块信息上，对于心理学家来说，重要的一点、以及让人惊讶的一点就是，我们定下的这个锚定点、这一块信息与我们实际的决定不需要有关系。

图17.23

我来举个例子，这是我的亲身经历。我应该是在上周去了Valve总部，问了我的同事他们SSN（Social Security Number，社会安全号码）的最后2位，他们就会给我从00到99的数字。有的人可能会担忧（泄漏），不过我不需要其它的7位，只要最后2位。然后我把这些回答分成了两组，如果你的数字小，0-49，那么你在第一组；如果你在后50，数字大，50-99，那么你就在第二组。然后问他们，『Dota里有多少个英雄？』我没有问Dota小组的人，我问了所有其他人。你在第一组或是第二组，Dota英雄有多少个？给出的估计数字应该没有区别，对吧？平均来说，人们很有可能收敛到一个数字上。但事实上，第一组、数字小的哪组，估计了100个英雄，而第二组估计了115。第一组锚定在了一个更小的数字——他们更小的SSN——，然后给出了更低的估计；第二组锚定在了一个更大的数字——他们更大的SSN——，然后给我一个更高的估计值。实际上答案是112——你们可能有人对这个数字好奇。重点就在于，不相关的信息实际上可以影响你的决策和对情况的评估。

这个例子可能有点不大恰当，用来说明不相关的信息在我们做的事中扮演了一个很重要的角色，不过当相关的信息被提供会是怎么样的呢？

图17.24

这张依然是Counter Strike的地图选择界面，左上角是Dust 2，它上面有一个预计等待时间1分12妙，旁边的是Train，预计等待时间是4分48秒。Dust 2，1分12秒，Train，4分48秒，Mirage，2分47秒。这里发生了什么？锚定有出现吗？

比如说我要玩Train，预计等待时间是4分48秒，如果我要等6分钟怎么办？我锚定在4分48秒，而实际上6分钟的等待时间，那么我就比我预期中多等了1分12秒，这是一个负面的体验。那么如果那个预计等待时间说的是8分钟，然后其实花了6分钟呢？你比你预期的要快两分钟。在这两个情况下，你都是等待了6分钟，第一种情况它说的是4分48秒，第二种情况是8分钟。8分钟这个情况会有更好的体验，显示一个更高的数字会让玩家在长时间等待下更开心——这有些反直觉。我们不会想要系统上高估我们的等待时间，因为这看起来并不好，但是实际上对于玩家来说却可能是一个积极的结果。这些都是准确的等待时间，我们没有在上面动手脚、没有任何操作，但是正因为我们是诚实的，相比建立一个缓冲区、增加等待时间，实际上我们更有可能给玩家创造了更负面的体验。

上面就是锚定的一个例子。接下来是另一个。比如说我想要玩Train，但是我看到了Dust 2，而Dust 2只要1分12秒，看起来真的非常不错。突然之间——最初我在Counter Strike是为了玩Train，如果（等待）时间合理的话，我就会去玩。4分48秒我就需要决定值不值得等待了，而现在Dust 2是1分12秒，突然之间我的参照系改变了，我实际在使用的比较物变了，我锚定到了这个更短的等待时间——1分12秒。我现在就需要决定，我是想在4分48秒后玩Train还是在1分12秒后玩Dust 2。所以我们展示给玩家的信息影响了他们的决策，也改变了他们如何评价以及情景。『他们想玩Train』和『他们在锚定了Dust 2的1分12秒等待时间下想玩Train』是不一样的。非常突出地，突然之间，玩或是不玩Train的等待时间跟另一个地图的等待时间的比较轴出现了漂移。

图17.25

锚定是其中一个认知偏差，而这是另一个。这里我们提到的『框架』（framing，Framing Effect框架效应），简单地说，就是影响反应选择的表达方式。我可以用两种不同的形式问你们一个相同的问题、相同的概念，而你的反应也是不同的，或者说你可能会有不同的反应。其中一个看待它的方式，或是说从中提取的一个发现是，你可以将同一个问题的框架变为避免损失或是获得收益，人们会倾向于厌恶损失而趋于收益。我给你们看一个例子。

图17.26

当WoW（World of Warcaft）刚出来的时候，Blizzard的人有些担心人们会玩得太久。他们做就是，他们说『你可以在basic playtime（基本游戏时间）中玩几个小时，然后获取100%的经验XP』，那么平均来说，你可能可以获得1,000XP每小时，但是在此之后——我要编造一个数值了——，比如说3小时之后，就变成了『reduced playtime』（缩减游戏时间），『我们会给你——你仍然可以玩——但是我们缩减你的XP』，他们不想要大家沉迷在游戏中，想要鼓励大家停下来，所以大概就是『玩三个小时可以获得100%的XP，但之后你只能获得一半XP』，平均是500XP每小时。玩家们不喜欢这个，那么Blizzard做了什么？

他们重新调整了比例。他们说，『好吧，我给你们额外的XP，开头的三小时200%的XP』，你仍然是平均获得1,000XP每小时，『三小时之后，我们给你基础的100%XP』，平均就是500XP每小时。人们更喜欢这个。实际上XP的获取是完全一样的，对吧？系统没有发生改变，唯一改变的只有表达方式。它告诉你，你在获益过程中、而获益也在消失，你获得了额外奖励，额外奖励也在离去；而不是你得到了惩罚，我们正在实施这个惩罚。对吧？

所以实际的XP获取是一样的，它只是如何将XP获取展现给玩家，对吧？他们获取的是额外奖励，而不是接受惩罚。

图17.27

这些我会快速地过一遍。这个列表是——我不想跟你们永远读着东西进行演讲——，不过我想说重点是，这里面有很多类似的偏差在参与作用，影响我们的决策、评估和思维。意识到这一些可以帮助我们做出更明智的决定。非常快地（过一遍）。

『近期偏差』（recency bias），在评估一个情况的时候，我们会倾向于考虑最近发生的事情。

『确认偏差』（confirmation bias），经常在政治中发生，我们倾向去寻找能确认我们信仰的信息，而避免否认我们信仰的信息。

虚假同感效应（false consensus effect）指的就是我们认为所有其它人比实际上更有可能认同我们——你可能注意到我刚刚的发音（鼻塞了的感觉）。

『马后炮偏差』（hindsight bias，好吧其实是『事后聪明偏差』），我们倾向于相较于真实情况更马后炮地看待已经发生的事情。在某件事情发生后，我们会『是啊，它当然会发生的』，我们会围绕它合理化我们的决策，但实际上并不是这样的。

『禀赋效应』（endowment effect）比较有趣，我们倾向于在拥有这些东西的时候更高估它们。比如说，『你愿意为了这个游戏内物品花多少钱？』，你可能会说5美元。一旦你有了这个5美元物品，你马上就会将它的估值提高，你会说『我只会以7美元卖掉它』。这是大范围中的一个常见发现，而这也是你可以用来运用到你的游戏内物品和人们在游戏中的拥有物的策略。

最后三个也很有趣。『纯粹接触效应』（mere exposure effect）简单地说就是这样：你看到一样东西的次数越多，你对倾向于看它的好感度就越高。这也是赞成市场营销的一个论据。如果你更经常地看到一个东西，相比于你没有见过的东西，你会更高看你经常看到的东西。这就是『纯粹接触效应』，它可以给一个东西带来更多的喜爱。

『偏见盲点』（bias blind spot）就是，你相信别人比起你来更有可能收到这些偏见的困扰。这就是关于认知偏差的认知偏差。

最后一个很有趣，『峰终理论』（peak-end rule）。当我们评价一次体验的时候，比如『我有多喜欢这个游戏』、『我有多喜欢这个电影』、『我有多喜欢听这张专辑』等等，我们不会说『我在整个体验中的平均体验是什么』。我们不会这么做，我们会走一条捷径。我们做的是，我们会说『在最高点、在顶峰的时候，我的感觉是如何的』以及『我在最后的感觉是如何』。『我在顶峰感觉如何、我在最终感觉如何』，然后你将它一平均，这就是你对体验的评估。对我们这样的游戏设计者的言外之意就是，虽然可能很难知道游戏的顶峰在哪里，但是你真的最好……你知道的，扼住结尾（nail the ending and stick the landing）是非常重要的，因为这对人们对你游戏的评价有着深厚的影响。如果人们说他们的感受是纵观整个体验的，其实并不是这样的。有的人可以做到，但是总体上，在你想起对整体体验的感受时，你是在考虑高峰点以及结尾的感受，这就是你评价东西的方法。

图17.28

这些认知偏差可对游戏设计的启示就是：可预测的方式能影响和成形决策。对于前面我谈到的两个偏差：理解玩家们的锚定点是什么、理解比较的基础，你会发现取决于你展示给玩家的锚定点，选择和最优化策略会发生改变。而在框架这方面要注意参考系，如何将东西展现给玩家是很重要的，如果你将一个东西的框架变为获益或是损失，这会对他们的反应产生很大的影响。你要倾向于积极的框架，给他们奖励而不是惩罚，等等。只要理解同样的情况能以多种方式展示给玩家，我们能选择如何展示，从而影响玩家的反应。

以及这可能是我这次演讲里最实际的建议，这个在日常的锚定行为里面都在使用：总是在谈判中说出第一个数字。如果你想要75k的工资，而你的老板想给你50k，如果你先说75k，那么你们会锚定到一个更高的数字，如果他先说50k，那么你们会锚定到一个更低的数字。不管是谁，先说第一个数字的人在谈判中设置了锚定点。这是你可以在日常生活中牢记的，想想锚定点是什么，以及你想要怎么样的锚定点，然后据此尝试利用它。

图17.29

『选择性失明』和『内部参照』。『选择性失明』我会在下一张幻灯片中进行定义，这一节我主要要讲的『内部参照』：我们是如何决定为何要做这些事的？

图17.30

之前也说到了，我们如何可靠地知道为什么我们要做我们做的事情？作为结果，特别地，我们从玩家那里获取的反馈有多可靠？当玩家告诉我们为什么要那么做，他们对我们的想法的评价有多可靠？

图17.31

心理学中关于这个的现象叫做『选择性失明』，我给你们看一个例子。

我会要求你选择两者中的一个。我告诉你『这里有两个人，告诉我哪个人更有吸引力，A人还是B人』，『这里有两瓶果酱，告诉我哪个更好吃，果酱A还是果酱B』、『这两个赌博中你更倾向于选择哪个』、『这两个道德判断中，哪个让你更舒服？』。只需要在两个选项中做出选择就可以。然后我会分散你的注意力，比如我会让你做一个填字游戏、看一段视频、安静地坐着、玩你的手机等等可以让你注意力分散几分钟的事情。然后我会让你来为你没有做选择的东西做出辩护。如果你选择A人，我会给你B人，然后告诉我，为什么你选择了B人。如果你选择了果酱B，我会给你果酱A，然后告诉我为什么你觉得果酱A更好。超过一半的人都会给我一个理由来说明，你为什么会做出其实你并没有做出的选择。

作为一个人工实验，它已经被重复过无数次了，而它确实也表明了很重要的一点，我们并不擅长于解释为什么我们要那么做。我们有些人可以，当我们坐下来深思熟虑的时候，我们可以做得挺好，但是我们经常受到外物的暗示。我们经常会选择对事物进行方便自己的解释，如果有人说『这是你刚刚做的』，你最后就会为你没有做出的选择编造出一个理论，所以我们很擅长编造理论。

图17.32

给我们的启示就是这些：对自我报告保持谨慎。这非常有用。无论是你得到的email还是论坛上的反馈或是从你问玩家们为什么那么做的游戏测试中获得的信息，你都要明白我们作为人类是不擅长的。有些人删除，你也可以获得很多的有用的数据，但是重点就是，对自我报告要持谨慎态度，将它们视为寻找行为的线索。你可能注意到我们用到了若隐若现的运动（实际幻灯片文字效果）来吸引你的注意力，希望起效果了。

这一点非常重要，让自我报告提供给你实际发生了什么的洞察力，去发现行为是否实际上正在发生。如果人们说一个武器不平衡，去看看数据它实际上是不是平衡的；如果人们不喜欢一张地图，去看看他们是不是在玩这张地图。有些问题很容易回答，而深入挖掘可测量的行为也是非常直观的。有时候它会更复杂和迷惑人，不过我想说的重点就是，明白什么正在发生其实……我们大脑中觉得正在发生的事情其实并不总是正在发生的是事情的准确判断。尽量使用自我报告来指导你，然后寻找一个能衡量的行为。

图17.33

下一个话题。我知道我们现在有点跳跃，但是在心理学中的东西非常多，这些最后对你们都很有用。『认知失调』和『玩家毒性』。

我会在下一张幻灯片定义『认知失调』。『玩家毒性』就是，如果有人进行在线游戏——我觉得你们大部分人都有玩过——，你们可能注意到有时候玩家并不是那么友好。有时候会有一些『毒性行为』的情况，如果我们能找到方法减少这些行为的方法，那么将会很棒。

图17.34

让我先定义什么是『认知失调』，然后再谈谈如何使用『认知失调』来减少在线游戏的毒性。『认知失调』就是，当思想和行为是不一致甚至相反的时候，就会出现不适。你可以这么想……我觉得自己是一个慈善慷慨的人，如果我在街上走看到了一个乞丐，但是我不会给他钱，所以在这个情况下我是不慈善慷慨的，之后我就会产生认知失调，对吧？我将自己定义成一个慈善慷慨的人，但是我的行为、或是说不作为，显示了我并不慈善慷慨，这就导致了矛盾。

这种情形会在很多种情景下发生，当我们都感受过这样的不适时，我们会通过改变对立的思想和行为中的一个来减少这样不适。如果我们能减少玩家的认知失调，可能我们就可以用它来改变游戏中的行为。我来给你们看一些我们的例子。

图17.35

这是Dota中的聊天记录，可能你们都没见过，因为这并不是大部分对话的内容。如果所有的对话都能这样那真是太棒了，但是现实不可能是这样的，他们不会倾向于这么做——如果会这么做那真的挺好。实际发生的是……我们来谈谈，后面有一张幻灯片讲了人们会在在线游戏中倾向于更负面化。这个话题本身就可以单独做一次演讲，之后我们可以讨论它。

图17.36

首先当然是匿名性。然后Dota需要非常多的时间投入来玩这个游戏，所以门槛是高的。在对手出现失误或是队友出现失误时，你需要做出很多的决策来抓住机会并相应地做出反应。还有人们知道的『邓宁-克鲁格效应』（Dunning–Kruger effect），简单地说就是，彩笔（imcompetent）不知道他们是彩笔。更普遍的说法就是，我们并没有在我们自我评价自、，并与别人相比时那么棒，我会觉得我比我的队友玩Dota玩得更好，从而我会因为实际上是我做的错误而去责怪他们。

还有很多的因素，我们的重点不是这里，我们只要明白处理好其中的任何一件事情都可以减少毒性。

图17.37

在Dota中，如果有人挺混蛋的话，你可以举报他们。你可以在记分板上点击他们的名字，然后这个对话框就会出现了。可能你们看起来比较困难，它上面写的是『举报玩家』。然后你可以选择一个类别，『辱骂玩家』、『故意滥用技能』和『故意送人头』，然后就可以举报他们了。这就是我前面说过的可测量行为，我们可以用举报的数量来表示他有多少『毒性』。

图17.38

我们之前在Dota中做的是，在游戏结束之后，我们会调查玩家，『请给你在这次比赛中的享受程度打分』，1- 5星。如果你不想回答你也可以不用回答。1-5星，『请给你在这次比赛中的享受程度打分』。这样我们就能将它与玩家的氛围和游戏中的特定行为联系起来，来理解为什么人们会有一个良好或是糟糕的体验。非常有用——不过不是我要说的重点。

在我们进行了这个之后，我们又加入了两个问题：

图17.39

首先是这个，『队友合作』。『请给上一局中的队友配合你的合作程度打分』，1-5星。这样你就可以说你有好的队友或是不好的队友了。我们可以多方面使用这个数据，比如将它运用到游戏匹配中。老实说，我根本不关心这个问题的答案，我们问这个问题的唯一原因就是，这样我们就可以问下一个问题。

图17.40

『请给上一局你配合你的队友的合作程度打分』。这里发生了什么？我们有自我认知偏差，我们很想给自己打高分，所以我会很愿意说我有很好的队友、给自己5星。但是如果我在游戏里是个混蛋，我知道我不能这么做，所以我在就有了矛盾的两个观念和想法：我不是一个很好的队友，但是我想给自己评分为好的队友。这就会引起『认知失调』。我们做这个就是希望，如果他们想要给高分但是又知道自己不值得那个高分，那么他们可以经历认知失调，然后他们就会相应地做出改变，很有可能他们就会克制他们的行为，在下一次看到这个调查问卷的时候，他们就可以诚实地回答了。

图17.41

我们做了这个，这也是当时我们在行为层面上做的唯一改变。而结果就是这个：大概每天的举报减少了大概137,000或者说12.5%，仅仅就是因为加入了这个调查。这贯穿了是百万的玩家和数百万场游戏，对吧？仅仅是加入一个调查问卷——实际上就是两个问题——来引起认知失调。

图17.42

简单地说就是，引入认知失调可以引起非常有意义的行为变化。你并不需要持续地操作，也就是说你可以巧妙地做它。而你要带给玩家的态度也非常重要，如果你让他们有不同的行为——正如我们的调查问卷——，那么有时候他们会有能让每个人都更开心的行为——每天137,000次更开心。

图17.43

还有几页幻灯片是关于『玩家力量』（player agency）。我认为这是一个重要的话题，但是我不想在这个上面细讲太多。

图17.44

需要讲的一些重点——可能我们很多人都能意识到，但是如果我们忽略它，那么它会对我们的玩家产生影响。我们喜欢感受到自己能对我们的环境施加控制。在任何情况下，我都想要感觉自己有类似心理学家称之为『自主权』（self-determination）的东西。我们会希望我们的行为会有影响。而当你设计的时候，你能给玩家多少力量？这一点需要牢记，这个问题在你做决策是非常有用。

图17.45

又是这张举报对话框，如果有人在Dota里表现得很不友好的话，你可以举报他们。

图17.46

如果你在Dota中举报了某个人，而他也被多次举报的时候，我们会禁止他进行游戏匹配，或是将他放到低优先级匹配中，或是禁止他们在游戏内的交流。我们会给他们惩罚，而这个时候，我们会让你知道我们这么做了。『感谢您。我们最近已经对你曾经举报有恶劣行为的一名或多名玩家采取措施。（你又获得了一次提交举报的机会。感谢你帮助我们将Dota 2社区建设得更加友善。）（这句没说，不过我给加上了）』所以你有所行动、举报了一个人之后，我们会对你的行动做出行动，然后告知你。我们在提供玩家力量。

图17.47

一个行为之后有一个结果。你举报一个玩家是一个行为，而结果就是那个玩家遭到了封禁，而且结果的证明就在这。你举报了某人，我们采取了措施，我们封禁。这一点非常重要，我们不能仅仅是有举报对话框，然后用它来封禁人，形成闭环是非常重要的。这会给玩家一种力量感，让他们觉得自己能够影响这个环境。我不喜欢跟负面的玩家相处，我想要做出改变，而这就是你可以做出改变的证明——我们给了你证明，你可以改变环境中你不喜欢的东西。这就是给玩家提供力量。

另一点我想说的是，少量的力量也跟大量的力量一样有价值。一直给玩家们大量的力量是不现实的。力量其实更是一个二元的东西，相比于一个连续区间而言更是一分为二的。只要玩家们能一直感受到自豪有一股少量的力量，这就是他们所需要的。

举一个不大恰当的例子，想一想Madden（Madden NFL，一款橄榄球电子游戏），它的天气跟你所处地此时此刻的天气是一样的。也就是说，我的环境会影响到我的游戏的环境。这可能感觉起来不太像玩家力量，但其实这也提供了玩家力量，他们可以影响环境来改变一些东西。像这样的小东西会在玩家如何理解的过程扮演重要的角色。

图17.48

最后一个话题就是『动机』。为什么人们在玩我们的游戏？

图17.49

广泛地说，动机是一种驱动行为的机制。而一个更广的问题是——可能我们都很感兴趣的是——，我们如何保持玩家参与到我们的游戏进来？

图17.50

总地来说，有两类或是说两种类型的动机。第一种就是，体验在本身是让人满意的。这是内部驱动的，我这么做就是因为我喜欢它。我用Team Fortress里的欢乐团队作为本身享受的象征。

图17.51

另一种发发就是使用外部的奖励，对吧？在游戏里获得物品、提升等级经验槽、解锁成就、开箱获得奖励，作为完成一次行为的结果而给你们的任何奖励、任何东西，都是外部的奖励。外部发生给你的东西，而你会积极地去获取这个外部的东西。

图17.52

这些点是值得思考的。内在的vs外在的，内部动机vs外部奖励。内在行为会倾向于持续更长久，我做某件事是因为我真的享受它，我会更经常地做，停止的可能性更小、更难于消失。而且我也会给更高的评分，也会带来更大的享受。比如我有一个艺术家朋友，然后我说给我做一个追梦人（Dream Catcher），她会制作一个给我，她也享受制作的过程。比起我说我用100美元买那个追梦人，她会给这次体验更高的评分。在突然我给她这次行为的外部的奖励之后，她可能不会那么享受了。所以内在行为有这些优秀的品质。

外在行为、奖励，对于塑造行为非常有用，让玩家在我们的游戏中做不同的事情。不过有一点要注意的是，他们会有改变游玩动机的风险。原来是自发地做某件事，但突然之间，我做同样的事情被提供了一个奖励，我做这件事的动机可能就会变为获取这个外在的奖励。这样就可能不会持续太久，而我更有可能停止这么做，我也不会那么享受它。所以请牢记，动机是能并且也会改变的。

图17.53

既然内在行为有这些优秀的品质，那么我们如何培养内在动机呢？如何让玩家们发自内心地享受？关于如何培养内在动机有很多的理论，我在这里要讲的几点都是被普遍认可的、能发挥有效作用的方法。

我在上一节讲了力量，而这是让人发自内心地享有某个东西的基础。他们感觉到自治权和力量——自治权就是控制自己命运的能力，而力量就是实施的能力、来完成决定自己命运的行为，可能这段话比较多余。不过我想要说的就是，我能做出能影响我的环境、我的情形的选择，能让我做我想做的事情。

如果你给玩家自治权和力量，你也应该给他们促进表现的能力。当我们做出一个行动或是活动的时候，我们想要做得更好，我们想要知道我们在做得更好，无论我们花了多久。确保任何技能发展对玩家来说是明显的，给他们这个技能发展、这个表现的反馈：『这是你做的不行的，这是你怎么做得更好的』。理解我是如何更擅长于某样东西以及我在上面有什么做得很好，这是非常重要的。你需要拥有技能发展，以及对技能发展的反馈，让人们知道『你是在这条路上的这个阶段，想要到那里，就要做这个』。

最后一点就是——我不是很喜欢泛化，不过这里需要（泛化）——，我们做为人类，很大一部分人都是被想要形成积极的社会比较所驱动的，我们想要自己对别人而言看起来是好的。所以给你的玩家提供机会，让他们在别人看起来是好的。排行榜就是典型的例子：我能给别人展示我有多么厉害。

所有这些因素都会引起自发动机。

图17.54

对于游戏设计的启发是什么？如给你可以，致力于满足玩家的自发需求，使用外部奖励来在需要的地方诱导行为，但是要明白你可能会改变玩家的动机，以下就是这个的结果。

图17.55

这是我演讲的最后一页幻灯片，你可能可以猜到它要表达什么，不过我还是要问你这个问题。

图里面有两组圆盘，每组4个圆盘，分为这些左边的圆盘和这些右边的圆盘。我要问的问题就是，『那一组圆盘看起来更亮？』想回答的人可以回答，或者我们……

没错，绝大多数人，我认为是90%的人会说右边的圆盘（更亮），而实际答案是它们是完全一样的。每张图里的这四个圆盘是完全一样的，它们是一样的圆盘，你可以一个像素一个像素地看、进行对比——我会很乐意把这两张图发给你们，这样你们想花多久时间（对比）都可以。

这里的重点就是，背景非常重要。背景会改变你的感知，这一点就是我整场演讲中想要传达的。你们如何给玩家展现东西的方式，还有展现给玩家的东西的背景，都会对你如何看待事物的方式产生巨大影响。不管你喜不喜欢、不论你如何决策、不论你的内部参照是什么，背景是非常重要的。这次演讲的希望就是传递这样的观点：如果我们更注意对行为的影响，我们很有可能最终能做出更好的游戏。

图17.56

谢谢大家与我度过这段时间。非常感谢。

（观众掌声）

18. VULKAN 图形

By Alen Ladavac (Croteam)、Dan Ginsburg (Valve)、Jeff Bolz (NVIDIA)、Rolando Caloca Olivares (Epic)、Mikko Strandborg (Unity Technologies)

主持人：John McDonald (Valve)

John：

大家好，我是来自Valve的John McDonlad，这是Vulkan专题讨论会。这次是对Leonard Nimoy（Star Trek的Spock扮演者）生平和时代的回顾展，希望你们在正确的房间里——当然，我刚刚只是开了个玩笑。这是关于图形API的。

首先我想从简单的介绍开始。然我们会谈到我们希望你们从今天的讨论会里得到的什么。我们会谈到为什么我们要讨论Vulkan。我会稍微详细地介绍一下每个人，让就从那里开始。我希望在这一节中，或者说我们希望在这一节中，你们能清晰地了解使用Vulkan的成本和好处，利用它的优势，对Vulkan的现状和未来有大致的认识。

我们要谈论这个是因为，在上一次的SDD，我们谈论了很多关于OpenGL的内容，我们也向你们当中的很多人谈论了OpenGL，获取了很多的反馈说OpenGL有很多好处但也有很多缺点，而事实也是如此。所以我们就和Khronos小组（Khronos Group，制定开放标准的行业协会，包括制定免费API）的成员一起推动了这个基本上从头做起的API，也确实解决了很多缺点，同时也保留了那些好处。我们今天就要在SDD上谈论它，因为我们发现这个我们尽量让它尽可能多部分开放的开放API，基本上能帮助我们所有人将所有事情都变得更好——我们在为我们的顾客制作游戏、满足我们的需求。

那么我们开始谈我们要谈的内容。我有写下一些笔记，因为要记的东西太多了。

在那头的是Jeff Bolz，他是NVIDIA的杰出工程师（Distinguished Engineer），他今天也代表了Vulkan工作小组的硬件成员。Vulkan是每个人的协同努力结果，包括硬件和软件供应商。而Jeff在1.0期间的作用是独一无二的，他解决的问题比其他任何人都要多，他用这样的方式表现了自己。毫不夸张地说，Jeff可能比地球上其他的任何人都要了解Vulkan，所以我们也很高兴他今天能跟我们一起在这里。

然后Jeff的旁边就是来自Valve的Dan。Dan和我应该是最初两个来自Valve的——虽然还有其他人——参与成型Vulkan1.0工作小组的人。Dan是第一个将Vulkan实际运用到程序中的开发者，这个程序是Dota 2，当时驱动距离能勉强运行还要很久很久的时间。这是一个仍在制定中的新规范，所以我也很高兴他今天能加入我们。

下一个是来自Croteam的Alen。你不想……我应该这么说，Alen，你怎么不招个手？你能向人群招个手吗？（Alen招手）谢谢。Alen是早期采用Vulkan的人之一，同样也在Croteam（是早期使用人之一）。The Talos Principle在Vulkan API仍在开发中的时候就运用了Vulkan。在Steam上的The Talos Principle的公开版本也在发售日的第一天就支持了Vulkan，对此我们非常地高兴。非常高兴看到有一个没有那么深入参与的人能采用和表示，我们都认为有效的东西是有效的。这非常棒。

然后是来自Unity的Mikko。Mikko现在领导……你可以向人群招个手吗？（Mikko招了个手）谢谢。Mikko领导着Unity的Vulkan团队，他也做了OpenGL和OpenGL ES的后端，所以他是非常有经验的。

最后是Rolando。Rolando来自于Epic，在他11岁的时候就开始写代码——比我还要早。他在Epic已经4年了，非常棒。他基本负责了虚幻4（Unreal 4）引擎里的所有Vulkan代码，所以如果代码好用的话，那就是他的锅，不好用也是他的锅。他也是Khronos工作小组的成员之一，他也帮助发布了第一个Android平台上使用Vulkan的demo ProtoStar，使用的是Unreal 4引擎，发布在三星S7上——我知道这里面有个笑话，不过随它去吧（可能是S7爆炸？）。

以上就是参与讨论会的所有人。我会尽量放慢我的说话速度，我知道我说得太快。先从一个问题开始，就随便定一下Jeff开始说吧——只是因为这样比较好记——，『你们希望用Vulkan能达到的目标是什么？你们希望得到的是什么？』

Jeff：

甩开OpenGL的遗留负担、拥有非常整洁的代码是非常棒的，虽然世界上有很多其它的API，但是能有一个让所有的IHV（independent hardware vendor，独立硬件提供商）和ISV（independent software vendor，独立软件提供商）能协同工作的API真的挺好的，能在所有的平台上运行、不受操作系统版本之类的限制。站在我们的角度，我们希望Vulkan能无处不在，我们在我们的所有平台上都支持了它，对于它的未来也很乐观。

John：

很棒。Dan，你呢？

Dan：

John刚刚也提到了，我们在最初的时候已经参与到Vulkan里了。我们在起源2（Source 2）引擎里应用Vulkan的一个目标就是想要一个能在多平台运行的高性能渲染后端；同时我们也希望确保API对于别的开发者来说是有用高效的，所以我们在Source 2引擎上进行实验，随着Vulkan的开发过程的同时尝试不同的API设计，找出什么能运行、什么不能。所以基本上我们把Source 2当作是测试如何让Vulkan最高效的平台。

John：

Croteam的Alen，你们想要从Vulkan中获得什么呢？

Alen：

多年以来，我们就一直注意到了『硬件能做什么』和『我们能通过已有API使用到什么』之间的差异，而Vulkan是一个很好的在更底层访问硬件、获取更多的性能和功能的机会。除此以外，它还有提供给了更多硬件提供商、移动和桌面平台和不同的操作系统。所以这对未来而言是非常好的提议，而我们也希望它能让我们更方便地将更多平台作为目标，同时也能带来更多的性能和功能。

John：

很棒。Mikko，如果所有好的答案还没被说完的话，在Unity的你们是希望从Vulkan中获得什么呢？

Mikko：

对我们而言，到现在为止大部分的好处应该是能有一个更底层图形API的崭新开始，尤其是在移动平台，在GL ES上的不同版本的驱动都……呃……非常……有趣——我们就这么说它吧（众人笑），这就让我们能……

John：

你还挺谨慎​​​​的。

Mikko：

是的。这就让我们能更好地控制硬件实际在发生什么，这样我们就能做更多我们想做的事情了，驱动也不再是障碍。

John：

很棒。Rolando。

Rolando：

我们之前在主机平台上工作了10年，然后转到了PC平台，我们发现我们并没有获得期望中性能。之后我做了些Metal（另一个图形API）的工作，它非常棒，因为它提供了更底层、更接近硬件的层面以及更多的控制。然后就是Vulkan横空出世，有PC、Android、Linux等等平台——毫无疑问这就是我们想用的。

John：

很棒，谢谢。在讨论了这个之后，我们来就另一个尖锐的问题进行讨论。『你们的实施情况到了什么程度了？』比如，是已经发布给消费者了，还是在内部开发中。这次从你开始，Rolando。

Rolando：

目前在Unreal 4引擎，我们下个月要发布的4.14版本中，我们会有完全的——我们已经有移动端支持了，在Protostar demo的时候发布的，而需要继续开发让它能在桌面端也能非常良好的运行。所以我们现在有了部分可以运行的延迟渲染。我们目前还没有能运行计算渲染的完整Shader Model 5.0，不过我们的目标就是这样，让Paragon等等所有的游戏都能在这个上面运行。

John：

很酷。Mikko。

Mikko：

我们在9月底的时候发布了一个支持Vulkan的实验性Unity版本，你们可以去我们的网站获取，或者从我们的blog那里找到链接。我们会在Unity 5.6版本中正式推出Vulkan支持，我们现在已经完全完成了这个功能，完成度已经达到了和其他的功能如DX11和其他更高层的渲染器一样的水平。

John：

很好。Alen，我知道答案，不过我们再说一次。你的Vulkan实施状态怎么样了？

Alen：

我们已经在和其他API相当的功能水平上发布了Vulkan（版本），同时登录Windows、Linux和Android平台。在这三个平台上我们都得到了很好的结果，这部分之后我会讲到的——我不是要从那个问题里偷点什么出来，不过我们现在还没有作为默认配置的原因只是因为还有些发生崩溃或是驱动问题的极端情况，但其余99%的情况下如果你想要微调游戏，这个会是全平台的首选API。

John：

棒。Dan，我们的状态怎么样了，我其实不是很了解。

Dan：

Dota 2是我们第一个使用了Source 2引擎的游戏，在5月的时候，我们在Windows和Linux上发布了免费DLC形式的Vulkan支持，所以至今已经发布给玩家5个月了。Valve其它的努力还有，我们有在Windows和Linux上可以运行的Steam界面（overlay），现在我们正在致力于Windows和Linux的Vulkan上的SteamVR。

John：

最后是Jeff。我觉得我们都知道，不过（你还是说一下）……

Jeff：

我觉得大部分人都知道NVIDIA在第一时间就发布了Windows、Linux和安卓上的Vulkan驱动。不过我想说的是驱动的质量在过去6个月里得到了提升，也有了几个游戏和游戏引擎，报告的bug也非常的有用——特别是通过Doom解决了很多稳定性问题。我现在对驱动目前的状态非常满意。

John：

很好。接下来我要问Mikko和Rolando一个问题，『与你曾经参与工作过的其它API相比，你们发现有多少的时间是用于解决Vulkan上的bug，而不是更高层的渲染bug、或者是……呃……驱动bug之类的问题？总计你们在这个上面花了多久？』这次先从Rolando开始吧。

Rolando：

很有趣的问题。Jeff也提到了，所有IHV的所有驱动在过去的几个月里还不错。其中一个主要问题是在移动端上，驱动安装、更新、涉及到的插入等等的问题。不过我觉得目前是非常好的时间点，现在加入进来的人相比6个月之前开始的人有巨大的优势。

John：

非常感谢你成为一个早期采用者，我们非常感谢。Mikko，你呢？

Mikko：

相比较于……举个例子，当我们开始OpenGL ES V3的时候，当它发布的时候，当时最大的问题是早期驱动的质量。当然你们（Rolando）在早期的Vulkan驱动质量上也焦头烂额，不过对我来说却是惊人地简单、bug较少，不仅仅是因为我们有类似RenderDoc这样的在很早期就支持Vulkan的debug工具（Rolando竖起大拇指），给了我们很大的帮助；而且验证层也给了我们很多好处，同时我们也跟所有的硬件生产商以及致力于这些验证层的人们有密切的合作，这非常地有帮助。

John：

很棒。接下来这个可能是一个非常相关的问题——虽然我不是故意这么做的——，Alen和Dan，你们使用Vulkan驱动的体验是怎么样的？我觉得我应该最近问一问，因为我知道Dan和我都是处理写给硬件的开源驱动的，追查内核模式bug，非常有趣的经验。自从发布以来，跟其他你们用过的API相比，你们的体验是怎么样的？

Dan：

不得不说，总体上是非常出色的。我们已经在NVIDIA、AMD和Intel的专用驱动上，以及Linux上的开源驱动上发布了（Vulkan）。最近AMD发布了一款叫做RADV的开源驱动，它也在这上面运行。我觉得相比较OpenGL，它的bug更少了，比如我们不同驱动的GLSL（OpenGL Shading Language）解析器之间会有差异，而由于Vulkan转为了二进制表示的SPIR-V（Standard Portable Intermediate Representation V，并行计算和图形的公开标准中间语言SPIR重编写版本，Vulkan和Open CL 2.1核心），这样就减少了很多的bug。我们处在一个比较特殊的位置，我们在开发Vulkan的时候和所有的IHV一起合作，在Vulkan发布前我们也碰到了很多不同的bug，但是发布后驱动的质量都不错。

John：

Alen，你提到了你们大概在1%左右的情况下会有些驱动问题，你可以就这个再展开讲讲吗？

Alen：

驱动里总是有bug的，不管你什么时候想实现新的功能，总会在某些设备上出现极端情况。不过总体来说，我认为Vulkan驱动平均来看比OpenGL驱动、甚至是DirectX驱动更稳定。它感觉起来——听起来可能不是很科学——不过它感觉起来更容易让IHV去看看它的情况并修复它，因为Vulkan里所有东西感觉起来都更轻量级。随着第一步已经迈出、所有的驱动都在被提升，我们在桌面端看到的大多数现存问题更多在其它的领域。比如说在Linux里，我们遇到的最大的问题就是在游戏使用OpenGL打开的一些情况下，如果我们想要从OpenGL换到Vulkan，窗口管理或是什么别的就会因为这个API的更改而崩溃，不过这不是Vulkan自身的问题。所以总体来说，我觉得它在驱动上的问题更少，尤其是你要考虑到现在还在很早期的阶段，如果是OpenGL的新版本，我觉得会有更多的问题。

John：

Jeff，Alen刚刚说了很有趣的一点，我们在Vulkan上的一个承诺就是我们会有更轻量级的驱动，这个是我们已经做到了的吗？驱动是比OpenGL的驱动更简单吗？我刚刚没提到，不过你在这方面做了很多工作。

Jeff：

是的，针对Vulkan部分的驱动实际上比OpenGL的要小很多。在我们的运用中，Vulkan驱动是在OpenGL驱动的同一个dll文件里的。我们将它放进去的原因是因为，我们想要共享编译程序、分配内存以及我们设置如何与硬件对话部分的代码，这部分内容无关API是什么。在这样的情况下，仅仅用于连接API和硬件命令的代码的实际数量是很少的，与相应的OpenGL代码相比更简单。所以答案是，是的，已经完成了这个承诺。

John：

这只是我突发奇想……我们昨晚讨论过一些这点，但是你不在（看着Rolando），所以我先抛弃你了（转回Jeff）……Vulkan驱动中最复杂的部分是什么？

Jeff：

我认为这取决于你问的是哪个硬件提供商。

John：

当然。

Jeff：

对我们来说，内存分配是我们的痛处。Vulkan允许将在任意内存格式下将任意的缓冲区和图像结合，但是这并不是我们的硬件所预期的使用方法，所以并不是很适合。我们要解决这个问题，这就是我们的挑战，我敢说其它的IHV也有不同的挑战，不过这就是妥协的本质，不是吗？

John：

是的。

Jeff：

所以这个就是主要问题，我认为我们差不多已经解决了，今后不再会是负担了，而未来的硬件也会改善到更好的匹配。这一点同时也会影响到DirectX 12，并不仅仅是Vulkan独有的。硬件会追赶上来，长期来看将不再是个问题。

John：

有一个相关的问题，这次就从Alen开始吧，当你将Vulkan应用到The Talos Principle时，你觉得使用Vulkan最需要技术含量、最困难的是什么？比如在什么地方你发现需要『这个东西我要花很久的时间来考虑部署或重写，来让它达到我们满意的状态』？

Alen：

首先这里面有很多的问题，因为在它发售前，我们是朝着一个移动的目标工作的。不过如果你去掉这些（细节）进行抽象化的话，就像Jeff说的，内存分配是一个问题，因为它在很多方面都非常复杂，比如说操作系统的指令和对齐问题等等不同方面。只要你解决了最基础的需求——虽然要抓住所有（需求）有些难——最后也不是什么大问题。同步是另一个，它现在全靠开发者了——虽然对我们来说还不错，因为我们已经完全掌握了——不过你也需要非常小心。好在验证层已经提升了很多，提供了很大的帮助。我们第一次开始着手这个的时候，验证层有很多没有覆盖到的情况，所以我们想要渲染什么但是出错的时候，只能绞尽脑汁想哪个资源没有同步。这些应该是最重要的两点。

John：

好的。我想过会儿之后再回来谈验证层和测试套件，现在我们先继续。Mikko，你们呢？你觉得使用Vulkan技术中需要解决的最有挑战性的问题是什么？

Mikko：

我觉得，还是内存管理。我们进行了多种尝试，最后我们重复利用了所有的对象（objects）、缓冲区（buffer）和所有的……好吧，没有图形（image），因为它们通常不会被重复使用，大部分（重复使用的）是缓冲区。我们就这样尽量少地分配内存。

John：

你们两个人说到的内存分配，是由于多线程吗？还是说在内存管理方面，在Vulkan中你需要做得比其它的API更多？还是这两者的结合，处理资源释放方面？你们两个人当中有人可以解释一下吗？稍微解释一下你们刚刚说的是什么意思。

Mikko：

我觉得大部分情况下，都是因为我们在最初的设想：一旦你有自己的内存区块并自己来管理它，那么在某个地方创建一个缓冲区——就拿缓冲区举例吧——可能会是一个非常高效的自由操作；但是事实不是这样的。当我们意识到自己在框架中并不需要做这些东西的时候，我们就去掉了它，然后一切都变得更快了。

John：

很棒。

Alen：

我们的主要问题是，因为这些基本要求不仅仅只有对齐，还有区块大小分配。比如某些情况下你可以特定对齐一些对象，而你不能分配每个内存区块到区块……有点难解释，有些区块大小会大于对齐大小，你必须确保在一个区块里没有两种不同的类型。你的脑子时刻都要记得小心内存分配器，这就很复杂了。

John：

Jeff，我猜这是因为有些现存的硬件有这样的要求，比如两种类型的对象不能在一个区块里，对吧？这是我们为Vulkan做出的妥协之一。

Jeff：

对，对，非常准确。

Alen：

它比它听起来更吓人。因为之前的API没有要求这个的，所以这些东西在实施的时候你都不会一个字一个字地把说明规范读一遍的，你会部署一些你觉得很合理的东西，然后就想『为什么这个不好用呢？』，对吧？然后当你明白所有细节的时候，你就需要去记录分配器了。

John：

Rolando，我们回到上一个问题，你们发现了什么？也是内存管理吗？

Rolando：

我觉得内存管理对我们来说还好。在最初的时候，当我们发布Android demo的时候，我们基本上就是用了最单纯的方法，每个目标分配一个，然后就做好了。这是我们为了让它正常运行所做的长时间改写的一部分。我觉得对我们来说，问题都出在转站（turn station）、内存屏障（memory barrier）和图形屏障（image barrier）上，你需要对高层进行更改，我猜之后的问题里面我们可以讨论。

John：

好的。Dan，我个人有一些自己的理解，不过我们发现最有技术挑战性的问题是什么？

Dan：

要不是他们说过的话，内存管理和图像布局转换会是我的前两个答案。不过还有一个让你感到很复杂的东西，那是描述符集（descriptor set）。描述符就是你如何将采样器（sampler）、texture和uniform（texture和uniform buffer是用于加速着色器检索渲染的）绑定到PSO（pipeline state object）中，你需要管理自己的描述符池，搞清楚你想要怎么分配它们到多线程中。如何进行优化、如何让它高效率运行是非常有挑战性的。

John：

很好。Alen，你之前提到了验证层在开发中非常有用，不过昨天晚饭的时候你说了一个很重要的观点。当时我们在讨论Mikko提出的一个问题——这个我不想讲的太详细——，他们做了一件对某个硬件提供商来说很吃惊的事情，我很确定这是被允许的，而Alen说『你应该将它加到验证层里』。

Alen：

其实是不对的，它应该被加入到测试里，对吧？

John：

是的。不过我想的是，这个主意很棒，因为它们两个都是开源的，我们很容易就能出力，你们的经验也能让它越来越好。

Alen：

我们的经验就是，当你在应用某个新东西上碰到问题的时候，它要么就是你的问题，要么就是驱动的问题——除了那些确实出现了错误报告的情况。在理想情况下，作为开发者，我们希望所有不允许的东西都会出现错误报告，错误可以在API这边……哦不对，驱动这边，也可以在程序这边。如果是程序这边的问题，那么验证层会指出来；如果在驱动这边，那么测试套件中就应该有一个驱动在发布前就要通过的测试。在使用Vulkan开发的过程中，如果你碰到了这些问题，有一个很好的方法就是请求一个验证层或是测试套件的补丁。

Rolando：

我能加一点吗？

John：

请。

Rolando：

一定要使用验证层，没有任何理由在用Vulkan开发的过程中不用它们。尤其是现在它们已经比刚开始的时候要成熟了很多，它们更轻量级，而且提供更多的详细信息。一定要用它们。

John：

很好。

Mikko

我们自己也遇到了一个bug，只在验证层没有被使用的情况下能被重现。这非常有趣。最终查清楚的原因是，由于验证层总是要分配所有的缓冲区ID和图像ID，就像单调增长一样，它们从来不会重复使用，而驱动却会（重复使用），所以在你删除一个缓冲区或是图像的时候，如果你的缓存没有合理地清理的话，那么一切就一团糟了。

John：

这个bug真是让人印象深刻。Jeff，你们意识到……我们从你开始吧……你们意识到的Vulkan发展的最重要方向是哪个？

Jeff：

在短期内，Vulkan小组正在致力于Vulkan Next。它会包含一系列VR特性，跟OpenGL ES里的OVR Multiview差不多；它也包含了一些为了提供更简单高效的排序符（compositor）托盘的东西。我觉得我们现在做的这些都非常重要，我也认为我们是在正确的时间解决正确的问题。在长期的未来，我也不知道，不过我很期待将会出现的VR新事物。

John：

好的。我们现在来讨论一个不是那么技术性但还是非常重要的问题。我先从程序提供商开始吧，不过你们（硬件提供商）也可以想一想。『你们是怎么处理你们现有的着色器内容的？』我想的是，你们不想重写所有东西，不然这太可怕了。先从Dan开始吧。

Dan：

好的。在上次SDD的时候，我做了一个关于我们如何将着色器从HLSL（High Level Shader Language，高级着色器语言）变为GLSL（OpenGL Shading Language，OpenGL着色器语言）的演讲，简单地说就是，我们有我们自己的轻量级翻译器和宏命令系统，来实现从HLSL转换为GLSL。由于我们在Source 2中已经有了能用的OpenGL渲染器，所以我们并不需要做太多的额外工作来引入到Vulkan中。我们已经在使用glslang——它是可引用的开源状态，也是用Khronos官方用来生成SPIR-V的工具——，所以我们只需要围绕描述符集和剪切空间做出一些轻微的修改，基本上着色器就完全一样地进入到了Vulkan中。之后我们在Google和LunarG和John Kessenich进行了很多生成SPIR-V的HLSL前端的工作，在glslang开源项目的主分支中就是一个HLSL前端。

我们展示的SteamVR中，Pierre-Loup已经把我们所有的SteamVR着色器通过这个HLSL前端分析、生成为SPIR-V，它现在也可以正确地渲染。上周，我把这个跟Source 2进行了连接，现在还要解决一些问题，不过我们计划最终要抛弃我们自己的HLSL到GLSL的翻译器，直接使用glslang的HLSL前端来为Vulkan生成SPIR-V。

John：

所以你们会直接pass掉你们现有的——我们现有的着色器。我不在Source 2方面工作，所以（用了你们这个词）……

Dan：

目标是有未经修改的着色器。我知道SteamVR就是这样的情况，我们在Vulkan中使用的着色器跟在DX11中用的完全一样。

John：

很棒。Alen，作为一个早期采用者，你的故事是再神奇不过了。

Alen：

要让你失望了，我对Dan说的没有什么要补充的。因为我们有OpenGL支持，所以改变并没有那么多，大部分问题就是用GLSL来加速编译器……编译到我们的代码库和界面，因为……因为它结构的形式……嗯……因为我们支持了一些不支持最新C++标准的平台。

John：

你是说，问题出在glslang是由编译器作者写的？

Alen：

差不多就是这样。

John：

好的，没错。John K是一个聪明的人，但是他也是个编译器作者。

Alen：

是的，那些就是些很有意思的问题，很容易解决。

John：

好的。Rolando，你有话要说吗？

Rolando：

简单的说，我们基本上在HLSL下写了所有的着色器。在材质编辑器里你可以写下自己的注释，然后它就会生成HLSL。我记得应该是在2012年，我们加入了Mesa着色器编译器来进行HLSL进程、生成（Mesa）IR，然后我们有一个给GLSL的后端，一个给Metal的后端，现在还有一个给Vulkan的后端。我们现在还在生成GLSL——比普通的OpenGL后端稍微好一点的GLSL——，然后将它通过GLSL slang来获得SPIR-V。我们可以生成SPIR-V，不过我们都是直接用HLSL前端。我们会用Mesa IR从我们的交叉编译器中获得元数据。我现在也不知道我们是不是以后也要这么做，不过这对我们来说不是很难，因为这个是我们已有的一个系统。

John：

Mikko？

Mikko：

我们确实有一条着色器编译流水线。我们所有的着色器最初都是用的HLSL，然后它们就会经过我们内部的着色器编译器根据关键词来生成所需的所有不同的类型。基本上都能通过Microsoft的d3dcompiler这个dll，甚至是mac，我们都能让它运行。然后得到的字节码（bytecode）就会用HLSLcc转换为GLSL ES。

John：

这个是Arauz写的工具，对吗？

Mikko：

不，那个最初是James Jone写的，现在我已经差不多全部重新写了一遍了。我们也用这个生成Metal语言……着色器语言。在这个例子中，它生成GLSL，然后到glslang。利用glsang，我们可以集成入我们的hook来获取着色器所需的反射数据。然后就进入小Small V压缩器中，这样着色器在SPIR-V下就不会那么大了。之后再进入到实际的游戏可执行包中。

John：

我记得我挺Arauz说到过这个。SPIR-V的一个问题是，由于它不断增长的数量，压缩起来很难，不过听起来你们已经在这方面有了些工作。

Mikko：

是的，它还是挺有帮助的，不过跟别的东西相比，它们还是非常非常大。

John：

我记得我们之前谈过，这也是一种妥协。我们觉得之后总归可以让它更小，而之后让它表达更丰富是更难的。不过看起来可能我们需要再审视一下这点。

Mikko：

是的，当我们最初尝试让我们的图形测试套件能在Android上运行的时候——内容大概就是几百个只有轻量级着色器的测试场景——，在Android手机上我们一直会把内存用尽，就是因为SPIR-V着色器自身的大小，我们把它们解压成一很大的一团，它在内存中就变得很大。Small V在这方面有些帮助。我们也用了其它的技巧，我们只会解压我们需要的字节。

John：

明白了。那么我们来谈谈……显而易见，你们都有了你们已经支持的其它API的渲染器前端，而Vulkan有一些独特的结构。我就在想，『你们有没有人在API层面制作或是改变你们的渲染器前端，里面有没有什么让你惊讶的东西』；或者说，你还没有做出什么来，但是目前还在制作中。Rolando，我们从你开始吧。

Rolando：

我们在几个月前的最初实施还比较幼稚，在利用优势方面做得并不是很好，比如渲染通道、资源转换和内存方面。我们就慢慢地将这些概念运用到渲染中来，尤其是内存中的资源转换和渲染通道。一旦我们有了这个之后，我认为在这就是我们从CPU得到的最大收获，同时更了解GPU渲染器是如何工作的，因为对我们来说，渲染器需要像Unity一样能跟所有其它的API合作，所以在高层渲染器上让我们特别为Vulkan做决定是艰难的，因为支持成本高或者会破坏其它API。我们不得不仔细考虑，我们在高层使用什么样的技术，来利用到每一个平台。

John：

我觉得我之前应该也问问这个：『你们现有的前端大概是什么样子的？』是像GL一样吗?还是3D一样?

Rolando：

差不多是D3D11这样。我们已经有了可用的资源转换API，下一步比较大的就是PSO——高层的实际pipeline state objects，我会同时用到D3D12和Vulkan，然后就是渲染通道。

John：

很棒。Mikko，同样的问题，不过先从你的渲染抽象化是什么样的开始吧，然后再谈论这个问题的其它部分。

Mikko：

好的。由于我们还需要支持桌面端的DX 9和移动端的OpenGL ES 2，我们的渲染抽象化API非常像DX 9那个年代的抽象层。在这下面，我们已经有了……你们谈到的大部分内容都已经应用到了GL ES中，所以我们也可以利用比如抛弃帧缓冲区这类的功能。对我们来说还是挺简单的，它仍然需要很多的代码，但我们很清楚我们要做的是什么。对我们来说还挺简单的。

John：

Alen，你们最后改了你们的渲染器了吗？

Alen：

我们仍在展望。我们目前已经做了一点了。同样地，我们会说我们目前的Vulkan运用是一外面包装着Vulkan的DirectX 11。因为高层的引擎所需要给OpenGL、OpenGL ES、DirectX 11、DirectX 9等等我们非常熟悉的API提供基于状态的接口；在中间层，我们的接口也是基于状态的。由于最初是在变化的目标，所以最开始的实施中我们只是让它运行。我们把它整个包起来，缓存所有的动态PSO、所有动态的东西。有趣的是，即便是这样，我们……比如在Android上，仍然有非常大的性能提升，这显示了驱动的臃肿和overhead中的一些问题；在Linux中，OpenGL上也有很大的性能提升；而在某些Windows设备上，DirectX 11也变得比Vulkan慢了一点。我们没有做什么优化，我们确实有一些自己渲染通道支持、抛弃之类的东西，不过我们面前还有很多的工作，我认为这是一个很好的优化的机会。我们现在致力于Vulkan的原生多线程渲染器，可以在多线程上记录注释，我们有的是要做的东西。

John：

也就是说，即便是现在，你们单纯地在单线程模式下使用Vulkan的情况下，也看到了性能提升，是吗？

Alen：

我们有一些多线程渲染器，跟DX 11上用的是一样的，我们在其它线程里用我们自己的格式记录注释，然后再到主线程上再次运行。所有的性能提升都是比较小的，不过它们都是能在驱动层面看得到的。接下来是做原生多线程渲染器，然后就是缓存PSO。

John：

很棒。

Mikko：

我们也观察到了同样的情况，即便是在单渲染线程下运行，跟你一样。尤其是在有大量绘图和驱动overhead的情况下，我们比DX 11更快。而在Android上更是远远地将GL ES 3甩在了后面，即使是单线程。我们也用到了多个作业上，比例会跟你预期的完全一样，它的帮助更大。

John：

很棒。Dan，之前我们有谈论过，不过我现在要问你，我们已经计划的有什么？而不是我们已经做了什么。

Dan：

我们也是差不多的情况。DX 11是我们引擎的抽象，我们计划的就是提升它。首先就是通过我们的抽象化让渲染通道暴露出来。我们有所有用于在我们的引擎中构建渲染通道的信息，只不过目前还没有传递到渲染层。它会给你很大的帮助，尤其是如果你的目标是TBR（tile-based renderer，基于tile的渲染器），甚至是立即模式下的渲染器，都会有GPU的提升，譬如子通道和渲染通道。另一个就是，我们想让描述符和描述符集在抽象中成为第一级类型，这样在引擎知道对象的绑定是定量的情况下就可以进行预处理。因为目前我们所面临的其中最大的一个问题就是更新描述符。然后，剩下一个是什么？我不知道，我一下子记不起来了。

我还要说的是，如果你是一个从头开始的开发者，我建议你们的抽象看起来要像Vulkan，因为这明显就是API的发展方向。如果你去看DX 12和Metal，你会发现很多相似点，如果你真的想要从中受益，你的引擎需要看起来是这样的，然后你就可以通过模拟API的方式来支持更老的API功能。

John：

或者在某些情况下，你也可以无视它们，对吧？

Dan：

是的。不过取决于你要支持的平台种类，或者是我们还有没有因为XP这样的原因需要支持DX 9的情况，在这种情况下，你还是需要它（DX 9）的。

John：

我觉得……如果我说错了，Jeff可以纠正我……我会认为硬件提供商会很乐于看到我们思考我改变渲染目标的频率是多少，所以即便是在DX 9和DX 11中将渲染通道作为第一类也可以将它带到最前沿。

Jeff：

是的。我认为，如果一个引擎是这样构建的，那么它在DX 9上也不会有劣势。我只是觉得要以那样的方式重写是需要付出努力的。我想回复一下他们刚刚在说的CPU限制性能。我非常高兴你们看到了这些CPU局限性的提升，现在我们不需要做之前在OpenGL下程序和驱动之间的反复调试了。每当一个新的OpenGL游戏出现的时候，基本上每次我们都要看一看API流、搞清楚时间都花在哪里，在驱动上做些优化或是从开发者那里获取反馈告诉他们『不要这么做』。但现在我们在Vulkan下完全不需要做这个，你们也表示速度变快了，很棒。

John：

与此相关的是，你们有发现你们可以用计时器识别Vulkan调用所需的时间都花在哪里吗？以前在D3D和GL中是一个历史遗留问题，当你打包API调用命令时，你只能搞清楚列举数据所花的时间。在Vulkan中，你们发现你们可以测量性能了吗？比如『哦，我进行了这个调用，这个调用代价有些高』。

Rolando：

是的。现在你可以知道时间都花在哪了。在以前，你调用GL绘图，它可能会花上几毫秒，也可能是几微秒，谁知道呢？但是现在你可以准确的执拗时间都花在哪里了。

Mikko：

而且现在你可以hook到任何一个你平常在用的分析器（profiler）里，性能也很稳定。不如使用它的话，在某些情况下你会看到峰值，这因为OpenGL中的有些缓冲区会变满，所以需要在中途去掉一些东西——仅仅就因为这个，这就是它的工作原理。现在，当我们在构建命令缓冲区时，我们能看到这整个构建当中占用了多少CPU。

John：

好的。

Jeff：

也有人告诉我GPUView现在更有用了，因为你现在可以……

Mikko：

哦，是的。

Jeff：

当你调用vkq提交命令的时候，你知道它会提交一大堆工作，然后你就可以在GPUView里看了。而在OpenGL中，你只有随机次数使用到的随机缓冲区。

John：

是的。你知道『我提交了这个，所以我能通过检测我的应用来说出里面有什么。』而不是『呃……我不知道。』好了，Jeff，他们都已经回答了他们要做的东西。那么你们作为一个硬件提供商，你们认为对于构建应用的人来说，最重要的是什么？比如，如果你说……如果我要找你，我会说『嘿，我今天做渲染，有什么高层概念需要我确保加入到我的渲染器前端，来最大化利用……不仅仅是Vulkan，还有DX 12，因为它们还挺像的』。

Jeff：

我们已经有这方面的尝试了。我认为找到一种处理PSO的方法是很重要的，因为这个在以前的API中是不需要你担心的。还有在写你的代码的时候牢记保持多线程，即便你最初也不会记录命令、描述等等这些多线程上的东西，你也要考虑到它，确保今后利用多线程的时候不会变得困难，这也是非常重要的。

John：

我们之前稍微谈到了一点PSO，我们也都意识到了他们是非常重要的东西。可能你们需要跟大家解释一下PSO是什么，以及为什么在Vulkan中它是第一类的。

Jeff：

就是着色器集合，以及所有可能会影响到着色器编译到所有不同的支持Vulkan的硬件的API描述。这是一种理解方式，也是为什么我们需要一次性了解所有东西。它的好处就是，程序可以知道工作是什么时候完成的；如果它需要，它可以在另一个线程里进行这个工作；对于整个流程来说也是一次性的成本。而在OpenGL中，我们得到的是状态差值（state delta）和一个绘图时间，我们需要查看状态，然后找出……通过hash或是某种缓存之类的……找到要用的着色器。这个成本在Vulkan里就不复存在了，它在OpenGL里确实是CPU瓶颈的一大源头之一。

John：

我也觉得有一种情况，就像Rolando谈到的问题一样，我做出了一个绘图调用后，『Surprise！这个花了好几毫秒』而不是进行大概推测。这是GL驱动第一次有机会能够『哦，我可以看到你用在它上面的所有东西，而现在我要解决一个问题，所以我要编译一个着色器。』

Jeff：

是的，是的，非常准确。

John：

好的。在开头的时候，我们谈到了我们希望用Vulkan实现的一些好处，那么我们现在再来说说这些承诺哪些实现了，哪些我们觉得如果做了某些改变就能实现但还没有实现。Jeff最后说，这次我先从Dan开始。

Dan：

从性能角度来看，我会重复一下其他人的说法。举个例子，在Linux上、在某些OpenGL驱动中，我们看到了Vulkan有更好的性能。它帮助降低了延迟，从一帧开始到与之关联的命令缓冲区提交到GPU的时间在Vulkan中更短了。在长期来看，它可以让多平台支持简单很多，因为我们在Linux和Windows上使用的是一样的代码。

John：

你们有没有在……我知道你跟这方面没关系，不过在VR方面，你们有发现这个也是有用的吗？

Dan：

嗯，我们正在将VR带上Vulkan和Source 2，有一样映射得非常好的是能记录命令缓冲区，然后重新提交的能力。我们做的跟DX 11的方式非常相似，只不过是硬件层的重新提交。我们记录了所有提供给左眼的命令，而在提交左眼和右眼的过程中，我们更新这些命令缓冲区指向的缓冲区数据，将数据转换给右眼，然后我们就可以再提交第二个命令缓冲区了。这样就不需要消耗CPU来记录另一只眼的命令，CPU压力会小很多。

John：

过去几年中Alex Alachos谈到了很多『running start』，你知道他的『running start』在Vulkan里更容易吗？按照他要在D3D11里为了实现这个耍的小把戏来看，我猜测是更容易的，其实我并不（肯定）

Dan：

实际上，应用了这个的人是Pierre-Loup，现在他坐在观众席里。我不认为我……

John：

你不想谈论这个。

Dan：

是的。

John：

没关系。哦，他（Pierre-Loup）说了『是的』。谢谢。Alen，你呢？你们看到了什么好处？还有哪些承诺没有兑现的？没有兑现的承诺是哪些？

Alen：

我之前谈到了性能的提升，这对我们来说是没有预料到的难题，因为我们知道我们仍然有很多的工作要做，不过现在已经很棒了。关于帧数的稳定性，之前Rolando和Mikko也提到的峰值。在以前，会有些很难解释的峰值，即便我们知道它们的存在是因为你们刚刚说的原因，我们也没有什么能做的。你会加一些预热，但是它的效果远没有你想象中的好。现在我们还有一些峰值，因为我们还没有设置BSO缓存，不过我们知道这是我们自己的问题，我们可以自己解决。之前，我们找这些问题找了像是好几十年，而我们能做的也只有哭。现在我们能看到很多的潜力，而我们也有能力解决所有的问题。至于还没有兑现的承诺，在性能之类的方面我还没有看到。如果我们去看原始规格的API，它看起来更……活泼和有趣。API里定义了一些极端情况，但是在我们开始实施前不是很明显，所有有些东西会比我们预期中要稍微复杂一点，不过没有什么是不能解决或是最后引起一些内容无效的。

John：

我之前应该问你的，刚刚你提醒了我。你之前提到——实际上你们都提到了内存管理有些困难，感觉要是某个人写一层东西的话，我们都可以受益。我知道听起来可能不大Vulkan，你们认为它是公允的吗？

Alen：

个人而言，从我们的经验来看，它更多的是要知道要做什么。所以它并不是一个很大的问题，更大的问题是命令缓冲区是如何构成的，不管是一级还是二级还是渲染通道。如果你不深入所有细节的话，这个可能比较难解释。了解硬件的需求是什么，以及为什么需求是这个，就像是『我猜这可能是唯一完成方法，但是我们觉得还有更容易的方法』，所以有些工作比我们预期中花的时间还要多，不过如果你想比硬件更快，那么也只能这么做。

John：

明白了。Mikko，你们呢？关于承诺。

Mikko：

性能对我们来说是个惊喜。

John：

是不好的方面吗？

Mikko：

不，是好的。最初我们计划说『我们要做这个针对Vulkan的实验性发布版本』，所以我们首先针对的是正确性。我们知道它会变得很慢，但是我们就想让它首先是正确的，然后我们再让它变快。我花了好几周的时间进行分析、查看性能并进行优化，突然之间，我们就比DX 11要快了。这一切都发生在Windows的桌面端，我用了Windows工具做的分析等等，基本上所有这些提升在Android上也能直接实现。

John：

很棒。

Mikko：

通常来说，在Android上进行分析是很困难的，而所有这些东西都可以直接应用到Android上。当然，还有一些我们没有做的事情，我们还没做合适的子通道——我觉得现在还没人做了这个——，不过我认为这会在性能上有很大的提升，尤其是使用tile-based GPU的移动端。比如你可以做一个合适的转移渲染（divert rendering）这样的东西，让一个G-buffer（Geometry Buffer，几何缓冲）保留在块内存（tile memory）里。

John：

听起来是挺庞大的一个东西。

Mikko：

应该是一个挺大的东西，不过也要求在引擎的更高层进行一些更改，因为我们要让它明确知道『我要启动一个子通道了，是要像这个样子的』。这就是我们现在在做的东西，只不过还需要花一段时间。

John：

好的，很棒。Rolando？

Rolando：

跟他们说的差不多。我们团队里很多人想留在Window 10哦不，Windows 7里，他们不想换到Windows 10，而很多功能是在Windows 8.1可用的，我差不多学了个入门和D3D12。而Vulkan允许我们在Window 7上使用这些功能。同时我们的代码中分别有给Android和PC的两个hash定义，剩下的代码是完全一样的。就像他们说过的，你可以测量它，它们在两个平台的性能是一样的，你可以知道你的瓶颈在哪里。

John：

很棒。我猜……

Jeff：

John，让我插一句。

John：

抱歉。

Jeff：

很高兴大家没有说Vulkan太难用了。还记得吗，我们之前曾经非常非常担心这个。

John：

之前是我们担心的大问题，是的。

Jeff：

大家在这里说，有一些挑战而你们也解决了，他们也说你可以去掉所有性能调整的成本，这么多的东西变得更简单了。这不是我们让他们这么说的，而是Vulkan在生产力上完全是提升。

John：

你们觉得这是公允的吗？

Mikko：

是的。老实说，在最初你要写的让一切运转起来的样板代码（boiler plate code）是非常让人气馁的，但是一旦你完成之后，其实用Vulkan来编程还是挺有趣的，因为我们再也不需要和驱动作斗争了。因为一般来说，我们要找到一种方法来让驱动不那么聪明，因为它总是想要聪明，但是最后都惨遭失败——我说的不是NVIDIA，我在说的是别的一些提供商。（观众笑声）

John：

停一下，停一下。

Mikko：

我们现在做的东西已经在GL ES上做过了，只不过我们现在更明确地知道了要做什么，比如重复使用、循环利用缓冲区。我们已经在GL ES 3上做缓冲区的fence和循环利用，因为这样在很多平台上会更快，bug也更少。而现在Vulkan终于给我们提供了工具来明确地做这个。

Rolando：

我觉得它变得更难了。我的意思是，对于没有做过任何图形工作的人来说，它更冗长、更难使用。他们要从头开始做一个程序，这有点让人沮丧。要放进去很多的代码，不过你只需要做一次，然后你就能习惯了。

John：

我觉得这个说法很公允，我不推荐比如大学生来使用Vulkan，他们并不是目标群体，我们才是目标群体，对吧？它是给专业人员用的。接下来，我想稍微快一点，因为我们快没时间了。我要问的是，你们还有Vulkan上或是使用Vulkan的VR上没有提到的未来计划吗？我知道我们有个答案。

Dan：

哦，对，我忘了我有没有提到过了。我们在今天下午和今天晚上会在社交区进行demo展示，它是运行在Linux的Vulkan上的SteamVR，使用的是Vulkan上的Source 2，欢迎大家来看。我们目前非常专注于让Vulkan适合VR，最终也会给我们的引擎加入VR和Vulkan的多GPU支持。差不多这就是我们的焦点。

John：

很棒。还有吗？

Rolando：

对我们来说，VR……只要平台和API支持，我们就会参与进来，因为我们差不多已经完成（听不清）。

John：

很棒。我们可能没有提问时间了。不过如果你有问题，我们会在外面待一会儿，今天剩下的时间我们也会在附近，你们尽管随时来找我们中的任何一个人。我们过会儿可能都会去喝点止咳药（某个梗），所以我们会给你非常诚实的回答，可能比你想要的还要多。谢谢大家（观众）今天到这里，也谢谢你们（研讨会成员）的参与。希望对大家有用。

（观众掌声）

19. 抢先体验

By Arthur Bruno (Crate Entertainment)、Russ Clarke (Payload Studios)、Will Turnbull (Klei Entertainment)、Tynan Sylvester (Ludeon Studios)、Tyler Sigman (Redhook Games)

主持人：Alden Kroll (Valve)

（观众掌声）

Alden：

大家好，欢迎来到『抢先体验』（以下简称EA）的专题讨论会。EA出现已经有几个年头了，上一次2014年的SDD上我们也有类似的专题讨论会。我们认为再为此做一次专题讨论会是值得的，因为有很多的产品都经过了EA、尝试了很多东西，有很多创新、也吸取了很多教训。我希望跟这五位大佬一起进行这次专题讨论会，谈谈他们的不同观点。他们有不同的目标、不同规模的产品，所以很值得你们花点时间来了解他们在这个过程中学到了什么经验，以及在你准备EA的时候你能如何将这些经验应用到你的产品上。

我们先从自我介绍开始吧。我叫Aledn Kroll，我在Valve工作。

Will：

我叫Will Turnbull，我在Klei Entertainment工作。

Tyler：

我叫Tyler Sigman，（来自）Red hook Studios。我制作了Darkest Dungeon。

Arthur：

我叫Arthur Bruno，我在Crate Entertainment工作。我制作了Grim Dawn。

Russ：

我叫Russ Clarke，我在伦敦的Payload Studios工作。我们制作了TerraTech。

Tynan：

我叫Tynan Sylvester。我在Ludeon Studios工作，制作了RimWorld。

Alden：

我们的讨论先从这个问题开始，你们能谈谈你们的EA经验吗？以及现在你们希望自己在EA当时知道什么？

Will：

我先开个头吧。Klei第一个进入EA的游戏是2012年的Don’t Starve，所以在当时我们已经有相当多的EA现有技术了。当开始做Don’t Starve Together和Invisible. Inc.这两个去年发布的游戏的时候，我们做的就是看看我们在Don’t Starve的2-4周的更新里做了什么，然后把它们应用到这两个游戏上。我想知道的一件事情是——尤其在Invisible. Inc.中——，『我们能把别的游戏的模型比如说Don’t Starve里的应用到新的游戏中吗？』现在我们已经成功了一半了。

Tyler：

我们在2015年2月参与的EA。就像我们的Kickstarter一样，我们有幸看到了很多完成了EA的游戏，从中学习了很多。我们为很多东西都做好了准备，但是有一件我们没准备好的事情是，我认为EA应该是用于迭代、尝试各种设计想法、改变游戏达到你满意程度的试验田。我认为它可以也应该是这样的，但是我们并没有准备好……我们以为所有参与到EA的人都可以预料到他们是早期接纳者，能理解东西会发生改变。在EA中途的时候我们才明白，由于我们做出了显著的游戏性改变，我们要面临非常严峻的社区管理挑战。要是我们当时知道改变已有东西而不是直接加入内容的限制有多少就好了。

Arthur：

我们进行EA的时间也比较早，是在2012年末。我觉得我们相对而言是准备好了的，或者说，我预料到了很多人不会将它看作尚在开发中的游戏，他们会预期更高水准的润色。我们在进入EA之前进行了很多的测试，确保核心游戏玩法是紧凑有趣的。在发布的时候，我们获得了良好的反响，但是我没有预料到的一件事是，一旦你在EA阶段发布，你就相当于进入踏上了一台跑步机上，玩家会期待不断地更新内容。作为一个小型团队，在我们制作的内容是基于故事和任务元素的线性游戏情况下，我们要花很多时间来发布内容，尤其是在早期的时候。有时候发布前需要的时间会要3个月甚至6个月，人们通常会在我们发布的前10个小时或是1天时间里火急火燎地重复玩上十几次，然后就迫不及待地想要下一次更新。我觉得我们……回想起来，我不能肯定我们能有不同的做法，因为我们这么做部分是由于资金的原因，我们想要在EA结束的时候**我们的团队、增大游戏范围、增加生产效率。不过如果我可以的话，如果我在我们决定未来走向的当时有超过一种选择的话，我觉得我会选择预载开发，我们会发布一个初始版本，然后以一个更加稳定的数量发布更多的内容。

Alden：

所以，Will，这个跟你们的EA经验差不多，对吧？你们在开始EA之前就有了非常长期的产品开发计划。

Will：

是的，尤其是在Don’t Starve Together和Invisible. Inc.中，我们在发售前尽量做出一个完整的游戏垂直部分，大概完成了75%。我们做的就是，我们在EA之前特地做了一个付费Beta，这样我们获得了一些保留数据和付费玩家的反馈，从完成了一半变成了完成75%，然后发布了一个我们有自信表明最终产品的版本。

Russ：

TerraTech几乎相反。我们在一年半前进入了EA，早期的游戏跟现在的有很大的不同，差不多就是因为我们需要钱。正如Tyler说的，在开发过程中，一些我们认为需要的显著的平衡性修改会导致很多负面的反馈，这时常发生。还有一件我们没有准备好的是——我能提前知道就好了——，玩家社区中对于某些特定问题的根深蒂固的想法。比如说，我们发布了一个游戏内的DLC，这个对于独立EA游戏来说并不常见，它不是一个内容型的DLC，而是一个更深入的提供实验室环境的EA mod，你可测试一些非常实验性的东西。我们设置了一个相对较高的价格，目的就是为了设立门槛，因为我们不想让所有人都拥有它，但最后30%的人拥有了这个DCL，这么说起来我们做得并不成功，不过也算是另一种成功。结果是很多的玩家都不喜欢DLC，尤其是当他们在一个EA游戏里看到的时候，他们就不会把这个游戏当作独立游戏，也就没有兴趣听你的解释为什么DLC跟他们想的不一样，他们就会想为什么开发者要第一时间做这个DLC。如果我们之前做好准备知道这一点的话，我们可能会以稍微不同的方式传递我们的东西，让它稍微缓和一点。

Tynan：

这听起来像是阴暗面……一个不断改变的游戏要应付成千上万接触的人的挑战。我学到的是，玩家基础中能有多少的价值，尤其是那些非常喜爱你的游戏的狂热粉。我就碰到一些人想要将游戏翻译到他们的语言、测试游戏、给我反馈bug，以这样的方式来帮助你。他们可以测试更……除非你有3A级的测试预算，他们可以做到比你内部的测试更彻底。我曾经尝试想象过如果只有我们两个一起做他们在RimWorld里做得事情，看起来是完全不可能的。因为有数千个忠实的玩家在感情上完全投入了这个游戏，尤其是他们创建了一个社区、彼此交流、交换意见并创造mod的时候，他们会发现你永远也不会看到的问题，他们创造出的东西和提供的建议是你永远也不会想到的。当然，如果这些玩家投入了某种东西但觉得被抢走的时候，也会有出错的危险，不过它也可以催生出意外的发现、驱使他们创造出你无法事先预料到的能帮助你、帮助所有人的价值。

Alden：

听起来你们从社区获得的反馈中获得了很多有用的东西。你们是如何筛选这些反馈并发现其中的可行部分是哪些呢？你们有什么好的流程吗？

Tynan：

当然有。它混合了系统性和非系统性的东西。系统性的是，我会尽量……每当一个新的有价值的建议或是概念出现的时候，我会尽量每次都记录下来，然后我就会得到一张有我的、开发者的、朋友的、玩家的想法和建议的巨大的列表。这么做的目的是，有时候一些想法在当时看起来不怎么样，但是之后再考虑之后，它们就会冒到最上面来。我基本上就拿了那张列表，不断地排列这些东西，将最上面的内容作为要完成的任务。如何吸收反馈……这是系统性的一面，或者说这就是这么一步一步做的方法。

更主观的一面是，我喜欢看YouTube视频、Twitch的直播和大家形容他们的游戏体验，我尽量看了很多这样的内容，差不多每个月会看好几十个小时——理想情况，甚至可能更多。这里面有大家没有报告的内容，如果你看得足够多，如果你看了足够多不同类型的玩家——你看了熟练玩家、新手玩家、创造性玩家、希望有消费性内容的玩家，你的神经系统就会自然地出现一个统计模型，告诉你什么是有问题的、什么是对的。你的大脑会——我的意思是，人们天生就很擅长这个——，你的大脑会通过大范围的采样自动学习，有什么是不停出现的，有什么是只出现了一次你不必太担心。这样就免去了你关注比如非常亲近你的或是碰巧声音很大的人。消化大量的东西，就会……大量地消化它、思考它，那些不断出现的东西就会自然而然地出现在你的面前。

Arthur：

我来佐证Tynan所说的。我发现EA阶段测试者的一个特定核心……硬核群体，尤其是那些从Titan Quest论坛过来的人，会比我们在THQ和Titan Quest时用到的『专业』测试人员提供更好的测试和bug反馈。也正如你说的，你可能花好几个月听取玩家的反馈、阅读论坛，而一旦你第一次看了某个人的直播之后，你马上就会看到很多呼之欲出的东西，你就会觉得『哦天哪，我们怎么漏掉了这个？』

Tynan：

直到现在，我已经看了——我也不是很清楚——，可能数百个小时的RimWorld。而我现在还能每隔20分钟看到不完善的、很糟糕的东西需要我修复，所以我不停地会记笔记。

Arthur：

或者是玩家会做一些你完全没预料到的事情。

Tyan：

是的，玩家不会想到要给我们反馈，它不是一个bug、看起来也不像一个bug。大量观看视频测试……或者说内容，真的非常有价值。

Russ：

我觉得很好的一点就是，你可以从不同的渠道中获取不同类型的反馈。从观看YouTube视频或是在一些演示游戏的直播你可以获得一种反馈。而在直接的书面形式的反馈渠道——我们在我们的网址上有一个论坛，一个私人的论坛，参与人员都非常热衷于这个游戏。他们会在论坛发帖，就像写好几页的论文一样，会讨论游戏的走向应该是怎么样的、为什么现在都不太对劲、他们有多喜爱这个游戏等等。这种方式也非常有用，但是当然你也要持保留态度（with a pinch of salt）来听取他们说的东西，或者说你要注意你采纳的东西。比如说，当你从Steam评测中得到了一些反馈时，其中有些评测也会挺长的，你需要按权重来评判它们。比如说，这么多的差评是关于bug的、这么多的是关于性能的、这么多的关于难度曲线的，可能这就是下次里程碑的时候需要在这些方面花上这么些时间用于优化，来减少（这部分的不足）。

Arthur：

我觉得在你阅读反馈的时候，你也需要考虑这些受众是哪一部分的、他们能多大程度代表所有受众。我的意思是，我们从我们的论坛里倾听并获取了很多的反馈——我记得论坛里我们有大概15k的订阅者——，但是我们也要考虑到这是受众很小的一部分，我不认为这是一个非常好的所有玩家的分布、代表。因为我觉得这是表明了有人花了时间注册了一个游戏的论坛，某种程度上他们已经是一个硬核玩家了，而你作为设计者，还需要尽量考虑到那些通常沉默的大多数受众。你从一部分的玩家那获得了很多的反馈，但是你也要自己进行评估它会如何影响到其他部分数量可能更多的受众。

在这个的基础上，我认为尤其是在你阅读负面的评测的时候，其中的一些你要看一看然后说『这个是完全正确的』。如果我们有些特定的目标本来能够满足这些玩家的期望，但是我们没有做到，那么我们就需要回过头强调它。而在另外一些情况下，人们不满意你的游戏是因为你要做的并不是他们所预期的。你永远不可能取悦所有人。我知道很容易就因为这个压力而停滞不前，因为当你翻阅你的Steam评测或是其它别的在线评测的时候，作为一个开发者很容易就会『好评、好评……翻过这些，我不需要关注这些』，你不会去阅读它们，你只会把注意力集中到所有的负面评价上，这样它们看起来的数量就会比实际还要多得多了。

Tyler：

说到反馈，我认为在Darkest Dngeon的EA时期，我们最大的挑战就是搞清楚玩家基础有多大、以及他们对游戏的期待是什么。我们在广告中将它定为一个非常困难的游戏，容错率很低。我觉得很多人也会认同它非常困难，但是也有相当一部分数量的人觉得只要你弄明白之后它太简单了。你可能会在同一天收到非常矛盾的反馈，它们都是来自于我们都非常感激的玩家群体——他们购买了游戏，我们也想让他们一直有良好的体验——，但是在同一天对于同一样东西，他们有的说太简单了，有的又说太难了，你就无法取悦所有人。

进入EA时很有帮助的一点是，你要确定你知道你要做的是什么样的游戏。这听起来很显然，不过我觉得如果你说『好吧，我只想把它放在那里看看玩家有什么样的反应』，这也太含糊了。我认为你需要想好『这是我们要做的，我们来看看人们是否喜欢，或者说是否有足够多的人喜欢我们在做的』。比如说，浏览负面的评测或是反馈的时候，我们做了和你们类似的事情，我们会去搜索各种来源，将它们编辑成一个文档，试图追踪它们。

这其中比较有趣的是，我们能看这些负面的评测，了解他们对于游戏在抱怨什么，然后回复他们『就是这么设计的』。我的意思是，尤其当它发生在Darkest Dungeon上的时候，由于它因为R&G（随机要素）之类的东西而臭名昭著——但老实说，DND也是这样的——，你需要投掷D20，（概率）是均匀分布的，但是在电子游戏里人们就变得愤怒了。所以说，如果他们抱怨的是Darkest Dungeon体验中必不可少的特性什么的，我们就会说『是啊，我们从来没说过这个游戏是给所有人玩的，这正好证明了我们在做的很成功啊。』虽然于此同时会很多负面评测指出很多我们想要修复的东西，但是如果你在脑海中没有一个目标的话，你会晕头转向的。

Tynan：

我觉得决定什么是你要做的和什么你不要做的非常重要。对于抱怨一些你可能永远不会做或是支持的东西的人们，你能了解到的是，可能这意味着你需要更好地交流你在做的是什么了。所以在一开始、或者玩家购买游戏之前就设立好游戏预期中的样子是非常重要的。他们最终不会预期一些你甚至都不会去做的东西——而这通常也是他们生气和差评的原因。

比如在RimWorld中，我们就在一些人身上遇到了问题，他们抱怨的原因是『不管我多么擅长这个游戏、不管我怎么尝试，最后我都会失去一些人。这让我很沮丧。』我就不得不在所有我能用到的途径来表示『这个是一个故事生成游戏，而不是一个能让你获得完美评价的技术向游戏。它本来就是戏剧性的，会有牺牲的发生，不可能在不破坏游戏核心的情况下去除这部分。』这就是你对你在做什么和你不做什么所要进行的交流，不要接受那些试图让你远离目标的反馈。

Alden：

你们有人发现过一些最终确实影响到你们的反馈，让游戏转变到一个跟你们预期完全不一样的方向？

Will：

有的，Invisible. Inc.对我们来说就是一个很有意思的案例研究。当我们将Invisible. Inc.发布到Steam的时候，我们看到了第一天——我们会追踪我们所有游戏的留存率，除了社区反馈之外，它可能是最好的来看我们游戏的表现如何的来源：在首日的粘度高不高、人们是不是愿意回来、直到下一次更新出来之前你是否将玩家留存了足够长的时间。如果他们停留的时间不够久，你就需要做出更大、更有声音的更新来把他们带回来，将他们推回到游戏中。

Invisible. Inc.表现得有些糟糕，存留率、尤其是首日存留率比我们预期中的要低，我们发现在游玩的人也会疑惑『为什么要这么做？』我们第一个想法是，我们需要加入教程。因为玩家没有了解到游戏的核心机制，又因为本就设计的非常难的难度曲线而变得非常沮丧，所以他们都离开了这个游戏。因此我们就加入了教程，这稍微挽回了一些存留率。随着发布的过程中，我们就注意到了游戏中『可能这里不太妥，可能这里太难了』，然后我们就降低了难度，加入了失败后的倒回和重新开始功能，让它不那么残酷。不过后来变得有些分心（red herring）了，我们在早期版本中做了过多的妥协来回应我们获得的大量反馈。

Alden：

Tyler，你之前提到了EA中的大幅度、彻底的修改是你们处于EA时期的一个元素。你们有没有找到一种方法来告知顾客你需要做出一个巨大、彻底的修改？

Tyler：

我觉得这个很难。每当你做出会改变游戏基础的修改的时候，不管你如何将它传达给玩家，它仍然是一个挑战，不过你仍然可以稍微按照你的喜好侧重你的游戏。我们没有做……说实话，我们还没找到。我们以前推出过一个叫做Corpse and Hound的更新。在Darkest Dungeon的开发中途，我们对格斗做了一些改变，因为我们觉得可以比当初的预期更多地利用这个系统，一些深层次的东西比如站位和一些战斗机制并没有发挥出足够的作用。同时，压力系统也没有我们预想中的那样有限制性作用。在Darkest Dungeon中，如果你的角色达到了100的压力值，他们就会压力过度，进入我们称之为『痛苦的』（Afflicted）状态，也就是说他们会变得失去理性、自暴自弃、绝望、疑神疑鬼等等，这部分是Darkest Dungeon体验中很重要的一部分。但是有些人就发现只要让他们到100的压力值，痛苦的状态并没有足以限制他们游戏方式的能力。我们想填补上这些漏洞，所以我们就为此在游戏中加入了『心脏病发作』，如果你在一个特定的压力数值之后仍然让它上升，那么他们就会直接死亡；同样在战斗中，如果你击败了敌人，他们就会有尸体，尸体会保留在那里一段时间占据住他们的位置。

我们有很多的理由去做这些，我们也对这个更新很兴奋。我记得我写了最长的一篇补丁说明，用一种戏虐的方式以恶狠狠的语气写了出来，我真的对所有我们要加入到角色上的可怕的东西感到兴奋——因为这就是Darkest Dungeon的形式，而且一直以来也很有效。最重要的是，它完全改变了战斗的机制，而战斗是游戏的核心部分，我们就像是亲手起义了一样。非常吓人的是——我们并不知道当时的社区有多大——，当时那次是至今以来最大的一次抱怨，而且还有不断增长的威胁。

这让我们大吃一惊，所以我觉得未来——我记得在我们推出这个之前，我是这么跟我的搭档、也是这个游戏的美术Chris说的『我们还在EA，如果这不是我们能实验游戏想法的地方，那么它存在的意义是什么呢？没事的。』所以我们就推出了它，我以为人们在发几天的牢骚之后就会安静下来。（但事实是）它并没有平静下来，而是不断地增长。我们最后终于落实了它，但是我觉得我们之前应该做的消息传递是，如果你要根本上改变某个游戏运行机制的东西，我认为你应该提前谈到它，你可以将它推送为自愿（opt-in）的Beta分支版本，从而获取……归根结底，你的社区是你最好的资源。游戏的优胜者是来自于社区的，而不非要是来自于内部的。你给小部分自愿的人进行推送，如果他们买账的话，他们在之后就会变成你的消息传递人；如果他们不买账的话，这也是一个很好的反馈，可能你推送了不怎么样的东西。我觉得我们可以分阶段地实施，提前传递信息。我也知道我们的美术Chris觉得我们没有将它润色到跟别的东西一样的程度，我们这么做就是因为我们是在做实验。我们把这些丢给玩家，『哇惊喜』，可能没有完整地实施好或是平衡好，社区中也没有拥护者，这就是风险所在。我以为内容差不多是还行的，但事实上是——比如五个月前买了游戏的人，他们已经玩过了，在之前的游玩中还挺有乐趣，但这之后却没有了。这就促使我们加入一个选项能禁用掉它，因为我觉得一旦你从某个人那里拿了钱，你就应该更——这是一个非常棘手的道德问题，即便有很多EA的免责申明，但是人们没有获得乐趣就会让我感觉很糟糕，虽然最后我们还是会保留这个功能。

Tynan：

这里面有个我刚刚开始意识到存在的设计师技巧，就是哪些改动会让现有的玩家厌烦，而哪些不会。并不是任何一个更改、或是让游戏变难、或是非要去掉一个东西会引起问题，你做出的一些在新玩家、抽象化等等每个设计者角度来看都更好的改动，仍然会让那些以原来的方式投入了精力的玩家感到生气。很难说这些改变会是怎么样的，我看到的是这样的：任何能让这个游戏在某个方面变难的东西，只要玩家们在心理上觉得是不合理的，他们觉得游戏的难度不应该在这个地方。比如说，在Rimworld里，在敌人攻击的方面，游戏难度可以调到我们想多困难就有多困难，但是当角色变得疯狂、崩溃的时候，他们并不一定会觉得这是合理的，他们会对此感到生气，即便敌人对他们而言是更大的一个问题。有时候确实与沟通有关，需要测试来找出什么会引起这个问题，但是我也认为这里需要研究，找出心理学上人们为何会抵制这种对新玩家等等各种意义上都对游戏更好的改变。这应该也是我们要研究的。

Tyler：

我觉得单纯地堆砌也没有什么用。我们会把更新汇总起来，我们通常有一个6周的更新周期，给重要的更新起名字，做一些恶搞的图片等等。我们会一次性把很多东西丢进去处理，做出一个大的更新。比如在这次的更新中，我们同时做了尸体、给了敌人护甲、在各个方面提升了难度。我们其实可以慢慢地做出来，但就不会像跳进一个冰泳池一样让人震惊。

Tynan：

增加难度绝对是有风险的（spark point）。移除掉能做的事情让难度上升，对我来说是非常危险的做法。

Arthur：

我认为最危险的事情是——我们有很多次这样的经验——，改变一些能够轻易抹去玩家在游戏中所花的时间的东西。我们在开发过程中曾经困扰我们的一件事就是，我们有一些你能收集的『零件』（component）可以组合成为一个『完成的零件』（finished component），可以作为装备的附加物。在完成的时候，你可以获得一个随机的完成奖励，而有些奖励相当地强力。所以一些非常硬核的玩家会慢慢地收集这些东西，逐渐积累出一套完整的完美完成奖励，这要花费很久的时间。但是在我们应用手工系统和库存的时候，我们遇到了问题，我们无法将这些东西堆叠到一起，因为他们的随机完成奖励是不同的。我们就这个问题进行了反复的讨论，如何让他们堆叠起来，而玩家还能够根据完成奖励来找到它们。结果是我们并没有找到一个好的方法，因为这样会导致UI的过于复杂。所以我们就在社区发布了一个投票，告诉他们说我们想要改变这些东西，好处有这些，而坏处是这些。而事实上大家的投票也是勉强赞成它，大概是55%的赞成和45%的不赞成。即便是这样，我也决定了我们不可以马上实施，因为有如此大比例的玩家投了反对票，这些人就像是在威胁说『如果你这么做了，你就是毁了我的角色，我要退出这个游戏』等等。不过我们最终还是这么做了，当然也引起了一些不和谐。不过我认为这中间起到缓和作用的是，在开发过程中，我们通过社区跟我们的受众交流，尽量……我认为其中一部分就是你需要给他们设定期望值，让他们看到你的努力、你要做的是什么。

我们花了很多的时间——尤其是在早期的时候——，尽量让我们论坛上的人理解我们的整个受众是怎么样的，跟他们解释他们在这个受众中是哪一部分。因为我觉得对于玩家、甚至是游戏开发者来说，有个常见的现象就是，如果你看看你自己和你关系最好的5个朋友，如果你们有一个相似的爱好，那么每个人都有这个爱好，因为这是你了解的所有人了。当然我们时常会和跟我们相似的人做朋友和交流，分享一样的观点。尤其是在游戏上，我们更倾向于和那些喜欢类似游戏的人一起玩游戏。所以一部分工作就是尽量跟人们解释论坛上的人虽然是非常重要的一部分受众，但也是非常有限的一部分受众，它并不能代表整体。同样对于EA也一样，EA的早期受众，或者说那些早期参与人，和EA末期、特别是完全发售后的受众并不一定是一样的。我们发现对我们的游戏来说——可能这取决于游戏的种类——，对我们来说，大部分玩家都对玩一个EA游戏并没有什么兴趣，而这部分玩家某种程度上就是另一种类型的玩家。你应该预见到从你最初获得的核心受众那里，你获得的是有限的视角。如果你过于专注于他们的反馈，你最后就像是在一个回音室（echo chamber）里一样，你是在专门最终受众中很有限的一部分人设计游戏。如果你这么做得太多的话，最终你可能会疏远一些之后可能会来的人。

这个『零件』的问题，我们后来也回过头来在我们内部进行了很多推心置腹的交流，最终决定……我们知道这是正确的事情，因为现在已经一团糟了，即便喜欢这些完成奖励的玩家也因为库存的管理而苦不堪言，同时它也造成了非常明显的平衡性问题，因为那些花了数千小时、获取了一套完整的完成奖励的人，拥有的角色比一般玩家的要强大得多，所以它让难度的平衡变得非常困难。我们花了很长的时间解释为什么我们要这么做，而最终我们也做出了这个改变。很多的人接受了……我觉得因为我们不是仅仅做出改变、发布一个更改了所有东西的补丁，而是让玩家们看到了我们是经过了深思熟虑，我们进行了这次投票、依然进行了商讨，然后再解释为什么我们最终要这么做，我觉得很多人当时更能接受它了。在最后，甚至是那些之前坚决反对的人也随着时间接受它是更好的了，因为我们给了他们时间看到了好处。确实有一些人会说『我要删除我的角色，因为你让我非常生气』，然后在两周之后，我们看到了他们在游戏上花了更多的时间，所以……

Tyler：

这里有心理学因素……哦对不起，我插嘴了。

Russ：

我觉得在开发中的游戏的平衡需求和消除时间投入的风险之间的矛盾在EA期间是很常见的。我们也不断地遇到了这个问题，因为TerraTech是一个颗粒化（granular）的游戏，里面都是一些建造块，人们用这些建造块来创造东西，在游戏里长期地使用它们。如果我们觉得这些建造块上面的附着点太多了，我们应该去掉某些附着点，那么这样就会完全破坏掉一些人的创造物，从而也可能完全破坏他们的整个游戏存档，这样的更改对我们来说是很难做的。

回到你（Tynan）刚刚说的，任何一个我们觉得在平衡性角度上需要做出、但是会限制人们已经习惯的功能的改变，都是非常让人痛苦的，但是我们不得不经常这么做。而我们从中学到的是——因为我们经常会为游戏发布一些新的块，我们从中学到的一件事是，当我们考虑到最初的平衡的时候，如果你有任何想不好要进行限制还是先看人们会怎么用的地方，那么你就应该先限制它，因为在之后再让它更容易、给它更多东西，比起从中去除是更加简单的。如果你确实不得不去掉某些东西——有时候这无法避免——，那么你要尽快地这么做，因为如果你等了6个月再去修复你迟早要修复的东西，你就等于进入了一个痛苦的世界。

Alden：

这是很好的一个论点。你们已经谈到了更新周期的不同节奏，你（Will）提到了……Klei的更频繁一点，你提到差不多是6周一个周期。你们认为这个在不同的游戏中是不一样的吗？你们有尝试过使用不同的更新频率吗？

Will：

对于Klei在2012年的Don’t Starve来说，我们基本上每2周会有一个小更新，每4周有一个大更新。我们在游戏里加入了一个倒计时器，每当你进入游戏的时候，你都会知道『我离下次更新还有5天』、『我离下次更新还要有1天』。我们也发现这对于创造更多的内容来说也是一个很好的工具，我们在Don’t Starve的EA阶段里就这样做了很多的内容。

我们所有的游戏都是在这个框架下进行的工作，因此我们也常常疑惑是不是可以转而做一个系统，而不是这样很多个小更新，我们可以攒了3个月的内容，然后做一个更大的更新。而事实上，Don’t Starve Together现在虽然已经不在EA阶段了，但也是一个我们在持续添加内容的游戏，而我们也在尝试刚刚那种方法。我们有一个Beta分支版本，你每隔3周就能获得新内容，而对于大多数玩家——90%的玩家——，他们会每隔3个月获得一个大更新，我们吧更新首先放到（Beta）上。我们也非常好奇，这是不是一个开发中的游戏更好用于获取新内容的一套方法。

Tyler：

对我们来说，我们更想要做大一些的更新，这也是我们市场营销策略的一部分。同时，我在想小型团队的逻辑是不是也有些不同：Chris负责美术，我负责设计，所以有时候由于某个人生活中发生了什么，我们的更新时间就会有变化，它迫使……我想说的是，如果我们像每2周推出什么东西的话，我们就会不得不破坏时间表来做一些更小或是更大的更新。而且每次发布一个更新的时候，你都要进行一定的管理，因为总是会有bug的，即便你花了最大的努力，我们也发现通常在更新的下一周你也要——可能是因为我们做的更新稍微大了点——，接下来的一周总是要花时间维护这个更新的。对我们来说，2周的更新周期和4周或6周的更新周期有很大的不同，如果要有一个特定的周期，我们觉得间隔稍微大一些更好，我也觉得营销也是这样的。

不过对于平衡性更新这样的，我们会随时推出，不会被周期所限制。如果我们觉得什么东西需要被强调，或是可以从一个我们在做的更大目标上单独拎出来，我们就会直接发布。

Arthur：

我比较不喜欢承担不必要的责任，所以我常常对宣布发布日期或是承诺一个特定的更新周期非常的犹豫。在我们的一个设计师提出『我想要每2周给社区一个新更新』的时候，我说，『我不清楚你知不知道你这是在自找麻烦，因为只要你向人们宣布了，你就不得不这么做了』。不过我们确实有（周期），我也认为它运作得挺好，不过在同一时间，如果因为各种原因——比如你要停个车什么的——，你比平时晚了2小时发布了更新，人们就会抓狂『发生了什么，Grim Dawn的开发者还在工作吗？』

我觉得如果……这仅仅是新闻的更新，如果你承诺了一个特定时间框架下的开发更新，尤其是对于小一些的团队，如果你没有足够的资源来保证履行承诺的话，我觉得你可以准备好接受激烈的反应了。我觉得某种程度上，设置低预期再超额完成总是更好的。每个更新都需要一定程度上的管理，对我们来说，每次发布一个大型更新后——就像你（Tyler）说的，你发布了这个大更新后，肯定会发现一些bug之类的，然后你就要花很多时间来修复，很多时候工程师或是内容人员不能去做主线版本的内容，因为我们可能要做另一个修复程序。总是会有残留的一些东西，导致我们开发速度会变慢几天或是一周、甚至更多——如果有个很明显的bug的话。

不过如果你能发布一个主要的更新版本，每隔……这个取决于游戏，如果你的游戏内容更线性，那我觉得比较难，因为这种类型的内容更费时间，而且由于人们很快就会过完这些内容并想要新的，以一个更紧凑的间隔来发布的压力也会更大。但是同时我觉得还有一件很重要的事情是，玩家们似乎不会以大小来衡量一个更新，比如我以为大家会对大更新更兴奋，但是他们并不一定会……兴奋程度跟工作量并没有什么联系，加入了一些武器之类的小更新也可以（让他们兴奋）。所以我就觉得可能更多小更新的计划可以让大家保持兴奋、让他们去不断查看更新，然后再以一个对于你的开发团队来说更能管理的时间间隔发布更大的更新。

Russ：

如果你去看那些正在开发周期中的游戏的话，我觉得这是一个比较常见的形式，而且我们也是这么做的。在早期的时候——我们已经参与EA一年半了，不过甚至是在这之前——，我们就已经有了规模小一些的类似流程。我们以前更临时（ad hoc basis）一些，准备好了就发布。我们发现这样有一个问题，它很容易混乱、或者说你会需要处理一些突发的事情，你就会无法保持一个规律性。不论是什么原因，如果你花了好几个月做一个大更新，那么你就无法做出更小的更新，你可能也不会注意到中间的间隔有多大。突然有一天你看到有人说『这个游戏已经死了，开发者们都不在乎这个游戏』，你还要快速地对此作出回应。所以最近我们就采纳了一个规律性的周期，我们花2周时间做小更新，每第3个小更新我们称之为『里程碑版本』（milestone release），我们会更新一个稳定版本，而在其它两个更新中，我们会做下一个里程碑的东西，并更新不稳定的版本。这样的情况下，那些非常想要了解工作进度的人就可以获得更新的版本，而那些不在意频繁更新而想要更稳定版本的人可以得到更高质量的、6周一次的更新。在我们给人们提供这样两个版本的同时，我们也发现这样的节奏也对我们的开发进度有很大的帮助，它让我们更好地进行计划来确保我们不会迷失。

Tynan：

我觉得可能跟不同的团队大小有关。对我来说，我们只有3个人，我们仅仅是做功能更新，可能要3-4周的时间，也可能要3-4个月的时间，看起来还可以。我想说的、但是你们刚刚没有提到的是，至少在我这样的情况下，最好完全不要承诺一个日期，甚至是你觉得你要发布前的1小时。我的更新都是直接发布的，就是这么惊喜，因为我好几次碰到了这个问题：我以为我们明天就可以发布了，但是最终结果是3-4周后才发布出来。原因就是你会发现一叠bug，解决一些之后又出来一系列bug。

这差不多就像是优劣分析，对吧？提前宣布你的发布时间的好处，在我看来是相对小的，因为不论兴奋是发生在发布时还是发布前，你获得的是同样的兴奋；而坏处就是，你说冒着你（Arthur）之前谈到的生气的风险。看起来非常有诱惑力……你想要对将要发生的事情更确定，你想要有这么一个确认，我认为这里面对开发者有一些心理学影响，他们会想要从公布发布日期中获得自我安慰的效果，就像是『每个人都赞同了，我被认可了，我感到了确定性』。但是如果你不能做到的话，会是很糟糕的，所以我觉得最好抑制住这种冲动，给人们惊喜就可以了。最终玩家们也会习惯的，几年之后他们会发现『很棒哦，有新东西了。在我听说它的时候就能玩到了。』

Alden：

所以你觉得在一个无法预测的时间表情况下，玩家们不会说『这个游戏死了，4周没有更新』，你也不会做些什么让他们知道……

Tynan：

这就是关键。对我们来说这从来不是大问题，你可以做一些事情比如……有段时间我会每天写一两句话还说明我那天做了什么，有时候就是处理税务工作、处理税务工作，平衡了这个功能，加入了一把枪等之类的事情。我会尽量这么做，让人们相信你不是消失了。你可以跟他们确认你在那，你只需要去发布一条『我们在努力工作』这样的话。我觉得你可以宣布一些即将到来的功能，只要他们是可靠的、已经实施的，这样你就知道他们是好用的，因为现在他们已经能用了。我认为宣布日期是更危险的。我有过几次情景，宣布了X/Y/Z功能，因为我们已经让它运行、已经做好了平衡，我知道99.9%的情况下它不会被砍掉什么的，只要几周时间的修复bug就可以了。这就是可以用于缓解这个情况的方法。

Tyler：

你也许会放一些斯金纳箱（Skinner Box，操作性条件反射）性质的更新。（笑，我估计别的人没有get到笑点）

Tynan：

没错，没错。我在更新直接消失过1个月，也消失过7个月。

Russ：

我能理解这种方法在小团队里是如何行得通的，因为你可以非常地灵活。一旦你有了超过10个人，我觉得保持每个人高效就很难了。

Tynan：

完全正确，这些都需要放在一个背景中讨论，比如你团队的大小、制作的游戏类型等等。小型团队的一个巨大优势就是非常地灵活，而我充分利用了这一点。

Arthur：

我也不是很懂，不过我们虽然超过了10个人，也会像你那样每隔一段时间放出发布一个惊喜版本。大家都知道即将到来，但是都不清楚确切的时间，某种程度上确实有斯金纳箱效应，我注意到在某些情况下，人们会变得更兴奋，因为他们会想『是今天发布吗？』、『我觉得可能是那一天。』人们就会开始投票或者说打赌发布的日期。

Tynan：

我发现大家会做一些统计分析，比如从这到这的一段时间里，这个曲线是向上还是向下倾，他们会试图找出x轴上的截距是在哪里。

Arthur：

对于更大的更新来说，我们尽量会宣布它们，因为我觉得有时候给媒体提前提供一个媒体版本还是有价值的。我觉得如果媒体能提前得到游戏，他们写出来的东西会更有价值一些；相反如果等到它慢悠悠地到媒体手中、玩家已经玩了几天的时候，我觉得对他们来说发布个新闻可能就没那么有意思了。对于一些非常大的内容更新，比如推出新的章节，我们会安排一个发布时间，但是直到非常接近发布的时候才会宣布。很多次我们在做的时候，我们都会告诉自己比如说『我们要在12月发布它，在11月底的时候需要完成』。然后我们就会开始做几天……几周来确定能不能在设定的当天全部完成——当然我们从来没有在我们原以为的日期完成过，我们最终会超过2周的时间，不过好在我们给了自己3-4周的缓冲时间，所以这个方法还是奏效了。

不过负面影响就是，它会带来更多的操作成本，也就是说我们现在专注于这次更新，在它发布之前的好几天里大家都不能去做别的事情。所以这里面既有优点也有缺点，我觉得混用的话会比较高效，而且按照什么样的模式也一定程度上取决于你的团队大小、你喜欢的工作方式、以及你开发所处的阶段。通常来说频繁更新会更容易一些，因为它们的都是像平衡性更改这样更小型一些的更新，你会加入更少的更新内容。早期的时候，我们在一些情况下，比如大型的更新或是主要系统的大幅度修改，我们知道到时候会是一团糟，会需要好几周的测试来回复到一个可以发布的状态。如果你当时定了一个太快的节奏的话，那么就很难适应进去，因为一个发布期限到来的时候我们会『快快快，把这些都放进去』，我也不认为我们有时间去打磨那些大幅度的修改，因为到时候我们要发布另一个版本。

Alden：

我在最后想留点时间给你们（观众）来提几个问题——如果你们在做游戏的话。这有几个麦克风，这条过道尾部有一个，那条过道尾部也有一个，我们会接着讨论几分钟。如果你们在麦克风那边排好队的话，我们等会儿就会开始回答问题。

我想进一步提问的是，你们当中有几个还在EA中，有几个已经发布了正式版，你们是如何知道什么时候该从EA转变为正式发布的呢？

Tyler：

我们有非常明确的……举个例子，我们在最终发布前3天加入了最终boss，所以我们知道已经做完了，我们在脑海中有个明确的完成概念。在EA阶段的时候还是相当沙盒模式（sandbox mode）的，我们保持了一个非常坚定的道路，虽然也有时起时落。功能集和发布区间……我觉得这是你需要在商业计划中考虑的，发布的时间是什么。我们确认了想要什么时候发布，最初我们想在去年的万圣节发布，但是没法做到，所以我们就自己想下一次比较好的区间是什么时候。我们选了一个我们觉得还不错的区间，看了看日历，看看有没有其它高质量的游戏发布、媒体的注意力都分散在哪里。我们确定了一个区间，也通过我们想在1.0版本中达到的功能集来确认了它。最后我们不得不撤下一些东西来确保我们的日期，然后在之后再以免费更新方式添加它们。我觉得这又回到定义你的产品上，有些游戏在EA阶段改变得更多，但是我们在EA之前就知道我们想要做什么，所以游戏在EA期间也就没有改变太多，差不就就是完成了所有的『待做事项』之后，最后知道『可以在1月19日之前完成』。

Will：

对于……

Arthur：

我认为……哦，你先说，抱歉。

Will：

对于Klei的游戏，如果你去看整个EA的流程：在我们进入EA之前的Beta阶段——这是啥提供给游戏的粉丝的——，你可以差不多了解游戏是怎么样的、我们的粉丝喜不喜欢；在我们进入EA的时候，游戏已经打磨得相当不错了，我们寻求的是，这种类型游戏的粉丝或是我们以前游戏的粉丝来玩它；当我们离开EA，我们的期待的是，这个游戏可以让Steam上的任何人来玩。当我们觉得内容已经到了那种程度，我们就会说『嘿，我们准备好了。1.0版本，都来玩吧。』对于我们来说，这肯定不是这个游戏工作的终点、也不是更新的终点，而是『这个体验是我们想给大家的，我们认为它对Steam上的每个人都是准备好了的』。

Arthur：

我认为对我们这样做线性内容的人来收，很明显当我们完成最后的内容的时候就差不多是游戏做完的时候。由于我们在早期花了很多时间在迭代和打磨核心游戏体验和游戏的感觉上，最后在这方面没有太多要做的东西。在这个方面我们从EA上得到了很多的好处。因为一旦游戏呈现到玩家面前，我们觉得确保他们在初期玩到的内容也非常有趣是非常重要的，所以我们就提前进行了游戏体验和破坏性的打磨。而由于玩家们非常活跃地游玩和理论上评论这个游戏，我们可以一直进行平衡性调整，所以我们在最后对游戏非常满意，我们要做的差不多就是完成最后的内容。我们想做的还有一件事是确保在发布的时候发布一大块内容，而不是游戏完成了，我们就退出EA，我们想做的是完成游戏，在正式发布的时候有让人兴奋的新内容，带回一些老玩家，也让新玩家看到一些之前没有的东西。

（Q&A部分）

Alden：

好的。我们来回答几个观众的问题吧。从你开始。

提问者1：

你们好。考虑玩家的痛苦和特性的迭代——说个引子，我离开电子游戏工作一年去做了一个企业软件，你的用户跟你签了5亿的合同在你迭代的特性上，当你把东西都搞砸的时候他们会很痛苦。一次又一次拯救了我们这些咸鱼的是『特性版本控制』，如果你要推出一个新特性，我会对一些特定的商户锁定它，或者允许一个特定范围的商户使用它、别的范围不能用。在你们的例子中，对于已经有用户使用的组件挂载点的游戏存档，你们不会发布会破坏它们的新特性，但是对于新游戏存档，你们可以这么做。你们有考虑过做这样的『特性版本控制』吗？

Russ：

是的，在某些方面我们会这么做。我们需要选择性地使用，因为它需要很高的管理成本，它取决于类型是什么。有些内容的特性，比如说一个特定的建造块，我们会做的是，我们会有一个对某个特定版本或者某个特定世界种子版本之后锁定的替代版本。我们可以这么做，不过这还是……这并不意味着我们不需要再担心它了。

Tynan：

它还有个问题就是，它对反馈是有害的。因为如果一直有不同的特性、每个人玩到的特性是不一样的，那么你就无法知道人们都在讲什么，也无法在听取玩家意见的时候知道他所在的背景是怎么样的。设计的流程会非常复杂，这也是为什么——至少在我这里——，我会非常抗拒加入特性的开关之类的东西。我也认为，作为设计者来说，我们应该去做一个满足各种各样的玩家都单独的游戏，我觉得总有一个方法是能做到的，而让玩家通过开关或者是去玩老版本来设计他们自己的游戏从某种程度上来说是个挺蹩脚的借口。在某些特定重要的情况下，我觉得这可以是个解决方案，但是如果平常都这么做，我觉得它的缺点太多了。

Will：

对我们来说差不多就是不要破坏玩家的mod。随着我们不断开发游戏，总有一些mod是两三年前的，所以我们寻求『特性版本控制』基本上就是，很多玩家在打了mod的服务器上玩，而我们要保证他们能继续玩。

Arthur：

我也觉得，至少对于基础的游戏来说你需要有一定程度的『纯正性』，或者说所有人都有一样的体验，因为……尤其是对于一个多人游戏来说，但是就算对于单人游戏来说，玩家们某种程度上也是互相竞争的——即便没有直接跟他们比较的玩家，很多时候人们进入游戏都会把自己跟别人在做的进行比较，通过比平均数完成更多来获得认同感。如果人们玩的不是一致的版本、如果我们不知道平均数是多少，那么就无法衡量你和别人在游戏里的完成度了。尤其是对于我们的游戏来说，有些情况下我们会允许……比如说更改了一些物品，而由于它们不怎么影响平衡性，我们允许它们的旧版本保留在玩家的库存当中，只不过不再掉落而已。还有一个更明显的就是角色阶职，如果一个角色阶职太强而被你削弱之后，你不可能让一小群玩家继续玩那个过于强大的角色阶职，而让别人玩被削弱的版本。

Alden:

谢谢。我们来听听这边的问题。

提问者2：

当一个游戏以服务的形式推出、不断地做出更新或是新增内容时，你们觉得这跟我们在EA阶段做的有什么明显的区别吗？或者换个提问方式，对于已经完成EA的游戏，你们现在的操作方式有什么区别吗？

Arthur：

我想说的是，游戏肯定在某种程度上会变成一种服务。而在15、20年之前，你基本上会做一个版本，然后以一个盒装发布，仅此而已。我认为游戏的营销周期已经发生了改变，在过去，营销都是集中在零售发行商上，盒装游戏会上架一段时间，商店内的广告也会持续一段时间，一旦这段时间过去后，销量就开始下跌了，整个流程也就差不多了。当你参与到网络分销的时候，游戏总是在上面的，游戏的曝光度可能会随着时间降低，但是它总是存在的。我觉得人们不会急着在第一时间挑选游戏，除非它是个非常高质量的游戏。由于现在每年都会出这么多的游戏，即便是仅仅单看ARPG这一块，它在五年前还挺安静的，但是现在有很多游戏在竞争。现在销量是，人们可能会在开头的6/8/12个月选择去玩另一个APRG游戏，而不是你的游戏，但是最终他们找一些别的东西，他们可能会做一个APGD的搜索，然后找到了你的游戏，所以即便是在发布之后，你也需要进行频繁的更新保持你的游戏是『活着的』，因为口碑是一个很重要的因素。尤其是当人们看到一个多人游戏，但是发现社区已经『死了』的时候，他们会丧失很多兴趣去玩它。同时由于媒体和人们听说游戏的方式在现在是非常碎片化的。不像过去1995年你登上PC Gamer的封面，你就完事了，现在每一小块曝光都会小小地提升你的销量，而且你需要很多块，因为现在的媒体都分散到很多网站上——直播的人、YouTuber等等。人们从如此多的来源听到各种各样的游戏，所以我觉得举行一些活动——内容发布活动——来获取覆盖率、甚至是小型的覆盖率也是很重要的，让大家保持讨论你的游戏、让它不断地出现在各种网站曝光周期中。

Tyler：

我觉得区别就是——尤其是就EA而言，你需要培养出实时行动的技能，而我认为这对于传统的PC开发者来说是非常困难的。如果你们有人做过移动端游戏，我觉得你们能从这个移动端f2p世界中学习到很多实时行动需要什么。比如说在我们的例子中，我们以前社区管理是分散到不同的有其它工作要做的人员上，直到到了那个尸体更新的时候，我们才终于决定我们需要一个全职的社区管理员。最后我们也是这么做的，我们已经让John做了一年，这样在发布的时候就可以有一个对外交流的优势，而如果你是个小型的、专注于开发的团队的话这就比较困难了。玩家们只需要知道你们是『活着』的还在工作就行，很多问题可以被解决，而这在EA完成之后也是一样的。

Will：

EA改变了我们做游戏的方式。在EA之前，我们做了像Mark of the Ninja这样的游戏，这是一个14小时流程的单次游玩游戏。而Don’t Starve让我们……这是一个不断的开发过程，只要消费者们对游戏感兴趣，我们就会有人去做这个游戏。相比5月份发布的时候，我们现在有更多的人在做Don’t Starve Together，也比2年前刚刚开始这个项目的时候要多。

Alden：

我们还有一个问题的时间。如果我们没有回答你的问题，你可以在外面找到他们，尽管跟他们提问就行。你来提问吧，那位男士。

提问者3：

这是一个很有意思的问题。EA和正式发布的游戏之间定价的原因是什么？你们怎么处理社区里对于这个问题的反馈？当定价过高或是过低的时候他们会不高兴吗？

Tyler：

我们提了价格，在EA期间是19.99美元，等到正式发布的时候涨价到了24.99美元。我们这么做的最初动机是想让在EA期间购买的人感到……我想说的是，他们帮助了我们，我们想要让他们觉得自己是早期尝试者，获得了一个早期尝试者的价格。我们好像没有听到什么负面的评论，所以我对此也很满意。它只需要找到……我认为只和价值有关，确保你给你的游戏定价是让人——听起来很理所当然——让人觉得是值得的，但是我觉得这是很难回答的一个问题。甚至在我们提升价格的时候我们也有一些紧张，不过我们看了看这个类别中的其它游戏，我们知道要玩完这样的游戏要花上很多很多的时间，游戏体验的时间会很长，所以我们想……看了看其它ARPG大概要40、50、60美元，那我们可以提升到24.99这样，而且这样会让我们对于如何对待EA玩家也感到心里暖暖的。

Russ：

我们也是一样的价位，看看其它独立游戏的价格、看看他们看起来满意的（价位）是什么，我们也不会……我们当然没有降低价格的打算，但是我们也没谈过要提价，虽然我们很可能会。很有趣的是，自从游戏从第一个版本开始发生巨大变化以来，人们比起以前能在20美元基础上得到越来越多的折扣。我觉得我们需要小心的是大幅度的折扣，如果你有一个开发了很久的游戏，一旦你开始给玩家留下了50%、60%、75%这样的预期，未来就很难再设置回来了，所以我们会避免这么做。

Tynan：

对于Tyler说的东西，也有一种相反的观点。他说早期玩家获得的更少，所以只后价格上涨了他们也能获得更多，但是……我可能总结的不怎么好……也有一个准则就是，你在非常早期得到的玩家是非常喜欢你的游戏的人，所以理论上愿意付更多的钱，所以要平衡这些是非常难的。我的策略就是这两个因素差不多是对等的，所以我会保持这个价格是一致的。你要注意到你提供的是什么、获得的玩家是怎么样的，以及随着时间出现的价格歧视。在长尾效应中，促销也是你要考虑的一部分。

Arthur：

我觉得Tynan说的其实差不多就是我想说的，早期你得到的玩家通常是那些对你的游戏最感兴趣的玩家。还有一个变数就是，如果你曾经有过Kickstarter众筹，你会有特定的级别让人们更早地获取游戏权限，这些级别是在更高的价位的。当我们进入EA时，我们觉得我们必须要以一个更高的价位发布来保护Kickstarter参与者的价值。即便他们在我们进行公开商店发布EA版本前几个月就已经玩上了，我们也觉得将价位降低太多还为时过早。但同时，随着开发的进行，你会碰到一些这类玩家：他们对你的游戏感兴趣，但是他们没有早期尝试者那么看重你的游戏。所以我们也感到这是一个矛盾的地方，早期玩家会觉得『我们更早支持了游戏，我们应该……后来的人不应该获得一个折扣』，但另一方面，我们也看到了很多类似『我想要这个游戏但是它太贵了，它不应该这么贵』这样的抱怨。在某种程度上，这取决于你发布的游戏的类型，人们对价位的预期范围很大，而且经常跟你实际在这个游戏里花费的精力并没有什么关联——我觉得非常不幸地，ARPG就是这样的一个类型，尤其是现在有相当不错的f2p游戏——合法的f2p游戏——供选择，就很难去定一个过高的价格。最后我们稍微反过来做了，不过我们在正式发售之前很久就开始降价（打折），在正式发售之后保持了一样的价格。

Will：

我们在定价上的理念不太一样，我们倾向于给我们的EA玩家最优惠的价格，而且我们也不怎么打折。这里面的理念是，我们想让玩家会因为觉得游戏还在开发中、他们还没有准备好参与而选择等待；而不是因为如果他们等上几周或是几个月，他们会得到一个更好的价格，他们等待是因为价格原因，

Arthur：

确实是这样。我还想加上的一点是，大部分先参与进来并付了更高价格的玩家，他们是非常乐意的，因为他们是最乐于支持这个游戏的人。事实上，很多人都会买好几份游戏，仅仅就用来……因为他们从游戏中获得了如此多的乐趣，他们想要一直支持开发者。我觉得应该稍微不同地对待受众，你的忠实玩家是非常重要的，之后再买这个游戏的顾客他们只是想买这个游戏，而不会那么投入到里面。

（一顿混乱，明显是有了不同的看法）

Alden：

我们没时间了，做个结尾吧。谢谢你们，谢谢大家。

（观众掌声）