全局目录

9. STEAMVR 硬件

By Ben Jackson (Valve)

下午好，再次欢迎大家来到SDD。我的名字是Ben Jackson，在Steam的VR部门工作，主要从事与追踪有关的课题。

今天我要讲关于Lighthouse的内容，我的意思是Steam VR追踪技术，你们可能已经听说过去我们常常叫它的名字Lighthouse，它们实际上是一个东西。

图9.1

首先我会给你们一个概览，告诉你们为什么我觉得你们应该用它。然后我会讲一讲技术的近况，以及我们为改进它而正在做些什么。我会讲如何让更多人的能用到。

图9.2

这就是这个系统，核心组件是基站、目标上的传感器、电子器件——追踪目标内部的电子器件——以及主机软件。数据也一样地从整个系统中穿过，从基站起源、与传感器交流、到电子器件，然后到主机上。我们并没有公开地讲过这些内容是怎么组合以及如何工作的，所以我今天会给你们看一些这部分内容：

图9.3

这就是这一系列中的第一个，基站。它产生所有用于追踪的信号，这使得系统质量非常的精确，也是确保任意一个手柄或者头显HMD都能一起工作的兼容性的关键。目前它会嵌入到墙上，而不是PC中，这样所有在基站范围内的人都可以共享它了，在这个空间里的每个物体都可以独立地操作。而它的范围也非常大，120度的范围足以让它即使在被放在角落的情况下也可以接触到左右两面墙和天花板、地板之间的空间。这对于别的类似相机镜头的东西来说是非常有挑战性的，但是对于发射出激光的转子来说是非常简单的，而窄激光也保证了甚至在房间的边缘也有高分辨率。

这些就是关键组件：sync blinker同步闪光灯，是一组LED阵列，会做出全局的闪烁——之后我会说明；以60Hz的速度旋转的转子rotor，当你看着它，你能看到一个点，我称之为激光点laser spot，这是之后我会说的线的一部分。转子旋转速度是60Hz，这就意味着在房间边缘的地方线会移动得非常快。如果边缘距离基站有5米，那么你算算，60Hz，它在房间边缘的速度就是2000m/s，比你的速度快得多了，就是它让我们能够追踪你。

图9.4

我想再强调一次为什么每个参与到Steam VR追踪技术的人作为目标体，是独立的。其自主性在于目标是通过接受共享信息来得知自己的位置的，而不需要跟别人进行协调。这就是为什么SteamVR非常适合背包式主机backpack pc——它不需要跟任何东西相连，包括基站本身。同理它也非常适合移动端VR。而它的可扩展性意味着每个使用这个volume（设备​）的人可以共享追踪。

图9.5

你可以在你自己的基站里看到我刚刚提到过的特性，如果你用能看见红外线的东西来看它——你们很多人可能有手机相机可以这么做，夜视镜也能，如果你有的话——，当你在房间里移动的时候（小人在移动），你可以看到这些点是在跟随你的（白点也在移动），就像画像里的眼睛一样，而这只是因为你看到了转子正好面对你的时候的点。如果你用手机进行这个实验，那么拍一张照片，如果你对照片进行分析，你会知道转子的点在哪里、离边缘都多近。如果你进行了测量，你会发现朝向的是基站，因为它会前后移动，就像图里的人验证过的那样。你在这个实验里有看到整个转子的优势，让你能判断从转子上出来的点在哪里，但是传感器就简单多了，它们只能看到光的闪烁。所以它们就需要使用不同的技术来判断看到闪烁时转子的朝向，方法就是通过timing计时——之后我们讲到——，而结果是一样的。

图9.6

另一种你可以假象的方式是，有一定弧度的激光形成了一条线，这个例子中是映射到了墙上。当然因为120度很宽，也能照到头顶和脚下的面上。假设你这时候看到了点，这条线就穿过了你的眼睛、或者是相机镜头——如果你在使用手机相机的话。所以在图左边，你可以看到光线现在被定格在它穿过你眼睛的时间。而（右边）是实际上追踪时发生的事情，一条线（竖线左右平移）扫过你，然后另一条光线（横线上下平移）扫过你，而当你看着它的时候，因为它的转速太快了所以你看到的是一个持续的点。之前说过，我们使用了计时，所以我们可以利用扫过的过程判断照射中你的时候转子是朝着哪里的。可能有些人刚刚没看到，我再给你们看一次（应该是让两条线又移动了一次）。

图9.7

这一页幻灯片就有些偏技术了，这是为了满足你们想要更多细节的好奇心。在左边我们有计时图，展示了一个转子扫过房间时发生了什么。所以第一件发生的事情是同步闪光灯——那一组LED——会明亮地闪烁，这就意味着房间里所有的东西都能看到，并让他们启动自己的时钟。而在这下面我画的是转子，这是一个俯视图。闪烁发生于在转子，在激光向旁边照到盒子的边上的时候，我们称为0度。然后转子现在在转动，当它到达大概30度的时候，这时候激光能从盒子中出现，它打开了开关，就如上一张幻灯片所示的那样线就能扫过房间，然后就打到每一个可见的传感器上。我在最下面画了一条线，在0度的时候，我们获取了一次闪烁来记录起始点，然后根据计时——因为转子是以固定速度旋转的，时间和角度是等价的——所以转子旋转，扫过了传感器，我们记录下时间，然后据此提供我们需要的角度，比如我在下面写了的一些数字。不过你们能发现这些数字非常接近，这非常合理，因为从基站角度来看，当目标体距离较远的时候，它们都是非常小的。正因为如此，我们在测量角度时需要很多精确性来告知发生了什么，所以我们需要很高的计时精度。

以上就是一个基站的一个轴上，每个基站有两个轴，所以每个基站都会发生两次。如果你使用两个基站，它们会轮流工作，其中一个闪烁、扫描、闪烁、扫描，然后另一个就有机会闪烁、扫描、闪烁、扫描，如此往复。

图9.8

这个系统的优势是什么？

一个就是我们的精度只受到我们能计时到多准的限制。而相机有传感器、传感器有像素，你的极限就在于你能在这些上面解决多少；但是线是以持续的方式扫描的，类似模拟连续的方式扫过房间，而我们要做的只是去精确地测量它。深入这部分其实还有很多内容，不仅仅有电子器件，同样也有传感器能多好地将光线转换成脉冲。

另一个优点就是我们的范围只被我们能将每个东西做到多亮、脉冲的计时有多准所限制。5米是一个合理的亮度和准度之间的平衡，不过你们很多人可能知道，光线是可以继续传播的，有写基站可以用于更广的范围。

以及，重复之前说的，自主性。我们有无限的用户和目标体，因为基站仅仅只是参考物，我们追踪的是类似于人工特征的东西，而基站只是坐在那里发出信号，而所有东西都能接受到它们（信号）。

还有一个就是，可能不是很明显，传感器识别自身。当它们被光线照到的时候，它们会说『嘿，我是传感器七号，我刚刚被光线照到了』。这样我们就准确的知道了是哪个被照到了。反之则是，一个LED亮起来了，你看到了然后你需要想『好吧，这个LED是哪个？』（拜拜手表示不行）所以你的手可以移动得相当快，它可以从遮挡中移进移出，可以旋转，只要有东西进入视野了，我们就可以知道是什么传感器被照到了，因为它们会识别自身。

图9.9

一旦我们有了所有这些数据，我们在低延迟的情况下获得了所有的角度、所有的IMU数据，一直传输到主机——可以用USB或者无线来实现，然后我们的驱动就会处理这些数据，通过同样的OpenVR驱动API——这对所有人都可用——向系统输入姿势信息。

图9.10

在VR中，良好的追踪系统是一项重要的责任。你的眼睛时刻在做彻底的追踪，你通过看周围的东西来知道自己在什么地方。当我们将你的世界替换成虚拟世界的时候，我们将你的追踪系统包裹在我们的追踪系统中。这就是为什么我们花费了如此多的时间在透镜、面板、帮助人们提高帧率和优秀的追踪上——因为在房间规模的VR中有一根链条，这跟链条的强度和它最薄弱的环节一样。

图9.11

现在我想给你们更新些信息。让我们来看看这些组件，谈一谈我们已经做到了什么程度，以及我们计划的方向。以下这些就是我们致力于VR时心中牢记的东西：

图9.12

显然我们想让所有东西都变好，而精确性是其中很重要的一部分。精确性就像我们能使用的货币一样，我们能花费这个货币来获取更大的范围或是更小的目标物。我们致力于使标准组件是可获得的。我们想确认所有需要用来使SteamVR追踪技术运作的专用部分都是能轻松获取的。我们会尽可能快地推进，不过我们也知道我们不会跟所有人都一样快，这也是为什么我们试图让所有人都参与进来。以及最后，我们一直都在考虑如何将VR带给更多的观众。

图9.13

让我们从信号开始的地方——基站——开始吧。我相信Joe已经在keynote中给你们展示过了一张全家福（演讲3.），所以让我们来每个内部都看一眼。

图9.14

这个基本就是我们做的第一个跟现在的基站长得差不多的基站。我们已经把长得像锯开成一半再拼起来的硬盘一样的原型打入冷宫了，但是一旦我们意识到这个可以工作，我们需要点更吸引人的东西。这些是由Valve员工手动加工的，你可能已经发现了这就是一对被锯成一半后又窝在一起的铝管段和手动旋转的黄铜转子，你可以看到点、产生线的line spreader （线扩散器？）。

我们使用一些多余的部件来制作，其中很多来源于eBay——你可能不知道的是，现在的硬盘马达不是以单独的马达出现的，它们被集成入了硬盘中，所以我们不得不到eBay上买那些早已不再使用的硬盘中的硬盘马达的旧库存。

印象中大概我们做了50个左右，因为我们给它们每个都取了名字，有26个男孩和大概26个女孩，而当我开始这个项目的时候，我记得大概有5个人，每个人都知道它们的名字，它们也有各自的性格。（观众笑）我们现在还记得某些的基站，我可以告诉你有一个叫做Jody的，在我开始做追踪系统工作的时候曾经在我的桌子上坐了很久。

你可以辨认出我们在之前的图里看到过的结构，那个翻转的L形是同步闪光灯，这是9个Osram牌Platinum Dragon LED灯（查了一下是07年发布的，在Dragon系列中是亮度最高的单芯片LED，功率可达Golden Dragon的两倍）。它们是被集成入的，所以可能看起来不怎么样，你可能看到的只是粉色的点。不过这些是1个就可以产生超高亮度的灯光闪烁的LED灯，你基本上都承受不了直接看它，而我们使用了9个。（观众笑声）因为我们真的不知道需要多亮，如同我说过的，范围就是亮度，所以我们错误的使用了超高亮度。当时，它们每个都要10美元，所以如你所见这不是一个划算的做基站的方法。

关于这个基站，一件有趣的事情就是它们其实挺不错的，但是又变成了问题，因为在他们没有被好好制作的情况下，我们可能没有获取该获取的信息，它们是由知道什么部分比较重要的人小心地手工制作的。

图9.15

所以我们继续扩大规模，要求Synapse做了大概400个，你可以看到它们明显都是基于同一个示意图，你可以认出一样的部件，一个类型的主板，只不过稍微改善了点。做了这样大概400个，然后手动校准它们，而从这里开始，我们学到了要达到批量生产需要什么。如果你为GDC 2015开发了任何内容，你可能获得了其中一个，以及一个你们之前在用的3D打印的头显。之后在GDC 2015我们展示了Vive的demo展位上也使用了它们。当时有7个demo展位，有14个被认为足够好的基站，以及少量以完美程度排名的备用品，完美程度从『请别用这个，用下一个』开始。（观众笑）下一步，哦对，我应该说一句，我们当时用光了所有在eBay上购买到的马达和激光器，所以我们就无法继续做这样的了。

这个是我们称之为Robin的基站，它随着开发套件被运送出去，我们在2015年的时候给了每个人一个。我知道你们当中很多人都拿到过这些当中的一个，所以你们也知道对于这些我们有一些成长的阵痛growing pains，所以我们只好停止调试它们，将它们分发给你们，这样你们就可以开始做内容了。在这个时候，我们已经用上了有现货供应的部件，但是可能并不是完美地适合，同时我们也在做我们知道今后需要的定制部分。如果我们对VR的发展方向的判断是正确的话，如果它（市场）会是非常庞大的，而你的到了这其中的一个，你应该保管好它，因为它会变成一个收集品。

图9.16

最终，Vive发布了，有基站、有所有的定制部分，一个为应用设计的定制马达，定制激光器、定制光学仪器，而且也做了好几千个。

图9.17

如果你认为那个Robin基站和HTC基站是一个相当大的飞跃的话，这是因为它是基于我们内部的研究平台的，就是我这里展示的这个。它被我们用来尝试新的东西，你可以看到甚至在这个上面我们也做了些更改。这就是我们想要用这个平台来进行一次全循环的地方，把我们在做的定制部件转变成所有人都能下订单的标准部件。我会用这个模型给你们展示一些我们现在在做的东西。

图9.18

你们可能已经注意到了有一整个的转子不见了，而我们制造了这个并且移除一个转子的原因就是，这样我们就可以安装带有两个line spreader的转子，这么做的结果就是你需要的就只是一个转子。相比这个砍掉部件的一半的方法，还有更好的方法恩那个使它变得更轻、更静、更便宜、更高效吗？（观众笑）

不好意思，我要取消一些Windows更新。（观众笑，鼓掌）我刚刚还在奇怪你们怎么没反应，我以为它也会去那里（指更新页面。应该是设置了播放幻灯片时只显示幻灯片内容），但并不是，只有我（去了那个页面）。（观众笑）好了。

图9.19

再一次拿出你们的夜视镜或者手机，现在我要让你们对要发生的事情大吃一惊，当你看着一个单独的转子时（屏幕右边的人上下移动，而点也随之变化）。（观众：oh boy. 很配合嘛）我可以说在我做了我们刚刚形容的这个实验之前，我也没有充分理解它，我们做了一个单独的转子，而我通过夜视镜看它。我会这么跟你们表达，很明显它发生了，但是它不是特别地明显。这就是线实际上做的经过你的样子（两条线分别扫过），就像一个V扫过一样。我再放一次，这样你们可以看到，你可以想象一个V扫过去了。当你站起来的时候，你的其中一个可见位置开始向左移，而另一个向右移。而如果人是左右移动的，那么你会看到两个点同时移动。这是一个给你直观感受的方法之一。

图9.20

让我给你另一个选择，这就是另一个考虑它的方法。在一个双转子的基站中，我们有个一个转子加另一个转子提供轴信息，这样组成了协调系统。而在一个双（口误了，应该是单）转子的基站中，我们根据结合V形线的信息来获取两个轴的信息。你可以想象不管你在哪里，你的水平信息是从一个在两条线中间的点来的，然后你的垂直位置你可以根据看到的两条线之间的距离来进行推断。

图9.21

接下来一站是传感器。这就是我们称之为『分立传感器』discreet sensor的东西，也就是说它们是用分立器件构成的：

图9.22

你看到的这个传感器里面大概有40个分立器件，因为它的形状，我们叫它『口香糖』gum stick（条形的那种）。它负责接收光线、增强、过滤多余信号，然后产生一个我们能用于计时的干净的脉冲。你可能从丝网印刷上知道了——字还是挺大的——它是来自于2014年10月的，电子器械工程师喜欢在PCB上加上日期，这样会方便很多。而下面这个，看的出是一样的设计，是被放入到早期的Vive原型机里的。

如果你在2015年获得了开发套件，那么你获得的两个Mr. Hats和原型HMD中就有这样70个这样的『口香糖』。你可以计算一下，70乘以40是2800，组件还是不少的。

图9.23 图中被部分盖住字的全文为Reduces component count dramatically. Its’s the TS3633 Light to Digital Converter to SteamVR Tracking!

还不止如此，我们还在做传感器ASIC，你们可能对这个词不熟悉，ASIC就是Application Specific Integrated Circuit专用集成电路，也就是定制的硅芯片。它将上一页幻灯片中你看到的大部分结合到了一张芯片上，并且表现得更好。

你可能会问了，『为什么人们不在所有地方使用ASIC呢？』这是因为，有些人知道答案的在笑了，这需要花很长的时间，而且做出第一块ASIC的价格非常贵，而结果就是简化了你的设计，而额外的增量部分非常便宜。如果你还没看到的话，就在这个小方块（黄色的）里，而主板上除此以外只有9个元件。

显然这些芯片很小，没有很多的空间写上信息，起初只给了我们四个字母用于命名，所以我们选择了HATS。我们喜欢你的VR hat里充满了HATS这一主意。不过很不幸地，早期HATS的版本很快就被新东西抛弃了，这就是TS3633，用于SteamVR追踪技术的光-数字转换器。为了给你们它有多小的直观感觉，这是上一张幻灯片里的同一比例下的主板。比例可能不完全一样，因为在蓝色主板的背面你还能看到一些分立器件，这部分分立器件是大很多的。

图9.24

我们的合作伙伴中其中一个致力于这方面的就是Triad Semiconductor，我们在2014年开始就跟他们一起迭代来达到甚至是超越我们之前看到的分立版本的性能。十分感谢Alan Yates花了如此久的时间来打磨初始的模拟设计到最好。而它也将成为能现货供应的元件之一，我之前也提到过，每个人都能买到。

在幻灯片的底部，你可以看到TS3633的两个面，边上的是一个10美分硬币。这就是我们说的3×3 WLCSP，wafer level chip scale package（晶圆片级芯片规模封装），换句话说就是，在硅晶圆片上直接切割出小正方形，边长为1.6毫米，跟10美分硬币上的D字大小一样。你回去的时候可以拿出10美分看看。

这就是我们的网址，triadsemi.com，如果你现在访问，你可以看到这部分的数据表单。上面有样品图，你也可以在这里购买。

图9.25

接下来我们进入下一部分。当我们从传感器处获得信号的时候，我们会将它传送到被追踪物的电子器件上来计时。

图9.26

这就是我们称之为Watchman的电路板，这是V1。每个传感器都有单独的关联，你可以看到它们环绕于电路板的周围。我们用了这个很多次来做HMD和手柄的原型机。如果你有机会用到我们在GDC 2015上展示的有线手柄，在每个hat里面都有一块这个电路板，以及一大堆连到每个传感器上的精心折叠起来的线缆。按照从大到小的顺序，上面的主要芯片有：FPGA（Field－Programmable Gate Array，现场可编程门阵列），它将所有单独的连接器连接起来，获取所有的计时数据；连接在上面的是MCU（Microcontroller Unit，微控制单元），它有一个USB可以返回到主机；然后是IMU（Inertial Measurement Unit，惯性测量单元），用来整合传感器。

正如幻灯片里写的，这对于HMD来说是非常好的设计，因为你可以让前面平整、后面线缆展开，与HMD的样子非常匹配，但是对设计手柄原型来说并不是很理想，因为大部分传感器都在一个地方。

图9.27

所以我们继续开发了V2。我们进行了批量生产，所以如果你在2015年得到过开发套件，那么你应该有3个：在两个追踪hat里各有一个，在面板前有一个。它也在Vive V0和V1 开发套件 HMD里。这是一个不断完善的过程。大部分新芯片跟你刚刚看到的基本上一样的，可能只有小幅度的升级，但是核心是一样的。出于制造的需要，它从一大堆独立连接器变成了3个每个能连接11个传感器的连接器。这对于制造来说好多了，但是也使得它对原型机制作来说变成了一个糟糕的平台。

图9.28

它只能进行追踪。你看右边这个MR. Hat手柄的轮廓，它有三个单独的电路板在里面。最上面横躺着的这个，是上一页幻灯片中提到的Watchman V2，它用一根排线与颈部的一块radio小电路板相连，然后又用一根排线和手柄部位的电路板相连，这块电路板提供所有的手柄功能。这样就导致从不同的Valve项目中产生了很多固件，如果你体验过，那么你就知道这样有些太复杂了。它速度快，某种意义上也模块化了，但是我们真正想要的是将所有这些结合到一个更小的规格中，结合所有追踪、radio、手柄输入部分。我们知道在向人们公布之前，我们需要做到这个。

图9.29

这就是Watchman V3。显然它很小，也对所有部分进行了升级，相当大的升级，就像从Cortex-M0到Cortex-M4（ARM公司产品）一样，加入了radio、所有手柄需要的I/O接口，支持Haptics技术和触摸屏按键以及额外的I/O接口。它的大小足够容纳在手柄握把部位，如果你用它进行原型设计，就不会变得很笨拙了。它支持hardware dev kit（HDK，硬件开发套件）——之后我会你们展示。

图9.30

之前我们讲了硬件，下面就来谈谈我们为开放SteamVR追踪技术给新的想法和应用上正在做些什么。

图9.31

我之前提到过，基站对于追踪质量至关重要，同时它们也是系统兼容性的关键，这也是为什么我们现在不能进行广泛地授权，因为我们还没准备好。我们知道大家都会在他们的系统中需要基站，所以我们会制造一个基站，使我们能OEM给所有想要使用的全规模的合作伙伴。目前，如果你想要单独的基站，可以从HTC处购得，它们都是兼容的。

图9.32

我们的传感器商店也非常简单，你只需要去 triadsemi.com，在右上角输入数量，点击『下单』，你就可以获得传感器了。我们现在就有网，如果有人（想买的话）……（观众笑）

图9.33

而对于（追踪）目标，我想谈一谈我们已经形成的课程。

图9.34

我希望如果你在听这次演讲，你不会对我们提供授权感到惊讶。对于要在他们自己的产品里使用SteamVR追踪技术的人来说，这就是一个点击即可的授权，没有预付费，没有专利费。目前我们已经有超过300家公司注册，这是一个很大的成功。我们没有认证程序，你可以造任何你想造的东西，只需要跟SteamVR兼容就可以。

现在我们确实要求获得许可的人要上一节课。而这也加速了我们将技术推广出去的计划，因为我们在Valve做的所有东西，我们都想不断迭代让它更好。比如现在，开发套件是刚刚为每节课做好的，我们现在正致力于增加规模。我们也在吸取早期课程的反馈，让课程更好。等到这些都做好的、可以量产开发套件的时候，我们就可以对外开放课程了。

图9.35

我不希望你们觉得这个课程在阻碍你们，从现在到今年年底之间还有超过100个空位，如果你们现在都去注册的话，我们可以开放更多的位置。大概有40人已经上过了，反馈也非常好。如果你想要带一大群人，或者你有想讨论的保密产品、做些展示和描述、获取建议，我们也可以安排私人课程的时间。

图9.36

开发这个课程和文档的合作伙伴是Synapse。他们就在Seattle的这条街上，你应该已经听到过我在讲基站和电子器件中间提到他们了。他们为课程做了一个参考对象，用它一路从最初的一次性原型到工具、再到使工具包在一卷内，一直服务于课程。他们做了所有要教你如何做的内容，所以他们也很有资格给你好的建议。

关于SteamVR追踪技术，在Synapse的有一个人你们得知道，那就是Doug Bruey。他在整合课程文档方面做了很突出的工作，他使得很多粗糙边缘和我们提供的工具变得平滑，老实说，他可能在教人如何开发被追踪目标方面比我们做得更好。他是个非常好的人，有圣人般的耐心，如果你看到Doug游荡在大厅里，一定要问个好。

图9.37

让我们来谈谈课程会涵盖什么。1）它首先会从更深层潜入技术开始，我们今天只是略讲了表面内容，而这里面会更深入。2）它会讲到如何设计被追踪目标。外形非常重要，你选择开始的基础外形、基本形状会很大程度影响到质量。我们会讲到如何做出这些选择。3）我们也提供工具来帮助你生成外形、提取元数据metadata——用于从CAD程序中提取元数据的插件——。4）帮助你进行传感器放置的工具——它们会就哪里放置传感器提供建议。如果你想要进行人工改变，也有一个工具可以给位置进行评价。它非常好用，在你尝试将想做的东西造出来以前，它就可以告诉你实际上能不能运作。5）我们会谈到覆盖物。这个话题有些微妙。显然，当你获得开发套件的时候，你会看到很多裸露的传感器，而对于商业产品来说你会想要将它们覆盖起来。我们会讲到一些有趣的挑战。6）如何快速做出原型。7）如何测试你的目标，如何校准它。当你进行机械装配的时候，会产生层叠问题。将传感器粘到洞里的时候，它会产生偏移。要追踪它的话，我们就需要知道它更精确的位置，所以每个目标体都需要单独校准，这样我们才能知道传感器下移了大约100微米。8）我们会教你如何做一个渲染模型，这样可以在比如当你在白房间里砍的时候使你的目标体变得可见。9）如何评估追踪和发现问题。10）当然我们也会跟深入的讲电子系统、11）固件。12）我们也会给你介绍HDK。

图9.38

这就是一次由工程师讲的，也是提供给工程师的课程。这三天的信息量非常丰富，我们也鼓励所有人都派机械工程师和电子工程师来获得最大的好处。如果你能将你的工业设计团队中的某个人也纳入，也是非常棒的；你选择的初始形态，会影响到它如何运行，所以最好在你知道它能否运行前不要爱上它。而我们的工具会很快地帮你进行评估。

所有的文档和工具都在Steam上的一个包里，上课的人都可以获取，而且每天都在更新。

图9.39

当你结束完课程之后，你可能会有些问题。一旦你参加课程，你就会在这个论坛上有发文的权限，而现在所有人都可以看。你可能从其他被授权人那里得到答案，可能从我这里获得答案，以及其他Valve团队的人，你也可能从Synapse团队那里得到答案。

图9.40

这个就是Valve会提供给课程参与者的参考硬件。它体现了传感器放置和覆盖的原则，让你能快速上手。我这里有一个，这个可能比你想象中要大。

图9.41 非幻灯片内容，现场截图

这是因为它在背面是空的，而这个握把明显是能去掉的，正如你在图片中看到的那样。去掉了握把之后，你可以将它套在几乎所有已有的HMD或者说你想要做的原型上。在课程中，你会学到如何修改它的配置来形容你放上去的显示器，这样你就可以立刻进入VR。

当然，如果你加上了这个握把，你可以将它当作手柄来进行实验（好像雷神之锤啊）。内部就是那个小模块——只是一个插入了的模块——，所以当你已经获知关于这个目标体的一切的时候，你也可以拔下它，在你自己的设计中使用。它使用的是电池，能同时在有线和无线下运行，这就是让你起步的东西。我把它放在那里（放到了边上的小桌子上）。

图9.42

你会获得开发套件还不止这个，里面会有所有你需要用来开发手柄或是HMD原型的东西，比如额外的传感器之类的东西。我之前也说到过，我们在Watchman V3中试图用固件支持所有东西，所以触摸板，Haptics震动，按键（都可以）。套件中还包含有几个快速原型的选项，一旦你获得这个原型目标的模块，有一个特殊的FPC（Flexible Printed Circuit），柔性线路板用于连接所有的传感器以及直接与模块挂钩。而对于制作原型，我们有看起来更像Watchman V1的东西，在上面扣上模块，然后周围都是连接器，这样你就可以在工作台上相当快地做出原型了。一旦那个可以运行，你可以做自己的相对简单的定制电路板来插上模块。最终你准备好生产的时候，你可以使用Steam上的设计文档——所有的图标、一个样本布局——来讲Watchman V3的设计直接包含入你的产品中。

图9.43

接下来我要开始讲OpenVR。无论你是在开发硬件还是软件，你都能用OpenVR将你在做的东西和别人的进行连接。

图9.44 图中上下两行遮住的是：Applications。以及，Driver, others

我想谈谈OpenVR和SteamVR之间的区别。什么是OpenVR？它是提供给顶部应用的API，和提供给底部驱动的API。在我们开始的时候，我们不知道我们会做一个所有人都想放进硬件中的追踪系统。我们做了一个所有人都能接入的体系，我们只是众多驱动中的一个。在这两个API中，SteamVR是将两者关联起来的runtime。它提供像版本管理这样的服务——这点非常重要，它可以让所有的新旧驱动能在新旧的应用上运行——，同时也提供了很多服务比如监控、重投影、布局和通知，所有你能在VR中见到的好东西。它也有Steam集成，不过在SteamVR中的Steam集成使用的是公共API，所以当你按下系统按钮时显示的是一样的Steam，以及Viveport出现在Steam边上也用了一样的API，界面也在github上直接就有。如果你想要做自己的东西，你可能已经尝试使用过了一些第三方启动器。

帮你记忆的一个小东西：OpenVR是在SteamVR三明治当中的面包^图9.44。

图9.45

OpenVR有一点很好，由于是在构建两端，它变得更有趣了。多亏了今天在观众席的你们中的很多人，Steam上有很多可用的内容。而它在SteamVR追踪技术支持的硬件上运行，最广为人知的就是HTC Vive，而马上就会有更多来自于被授权者的硬件——得益于在场中的有些人——，而且它也在其他平台运行。我甚至不能给你们一个完整的列表，因为我知道很多致力于驱动的人甚至都没跟我们说过话，还有我没见过的HMD也都很棒。这就是『开放』的力量，你可以做HMD，可以写驱动，可以买一份theBlu在VR体验与鲸鱼的相遇，你不需要我们的允许，甚至不需要和我们进行交谈——虽然我希望你来（和我们交谈）。

图9.46

为了鼓励人们来写驱动，我们需要一个示范。所以我们为尊敬的Razer Hydra发布了一个示例驱动，很快被人所接受和扩展。我想特别感谢Andras Beck，他使我们的示例变成了产品，也帮助我们了解了很多关于在Steam上发布第三方驱动的东西，以及如何安装和运行。我认为这也很好的显示了OpenVR的力量，我记得Joe在他的幻灯片里面提到过每个人都付出点推力的旋转木马。在我在家让Hydra驱动运行的第一天，我想做一个人们会拿它来做的事情的测试，我拿了一个DK2（Oculus Rift DK2），拿出了Hydra，然后开始玩Space Pirate Trainer。

我认为我可以这么说，这是我拥有Hydra和DK2以来最开心的时候，正因为Hydra和DK2不久前都登上了这个旋转木马，所以它变成了可能，并且让旋转木马转得更快了一点。之后Vive出现了，HTC用力地推了一把，这使得制作Space Pirate Trainer很值。现在所有在旋转木马上的人都获得了好处。我尝试Google出Space Pirate Trainer是否恰好在早期是为Hydra开发的，结果我不能发现任何关于这个的信息，因为当你Google它的时候，你得到的都是人们谈论他们用Hydra玩Space Pirate Trainer时有多么开心。

如果你现在在Steam上准备发布游戏，那么机会就在于有人已经尝试过Hydra或是Leap Motion了，而你都不需要动一根手指。

图9.47

如果你想要开发驱动和应用，你需要的所有东西都在github上可用。它有一个标准的3条款BSD许可（https://opensource.org/licenses/BSD-3-Clause）。如果你想写一个overlay、放在Steam边上的仪表盘插件，或者你仅仅想做个研究项目、记录下所有的发布内容，你也可以去那里。这个界面就是SteamVR追踪技术、Steam、Viveport如何整合的，如果你有问题，请在论坛里问他们。我们会看到的，也会尝试让擅长这部分的合适的人来回答问题。

图9.48

我们已经在大多数主流游戏引擎里集成了OpneVR，现在你们可以在短短几分钟内快速上手。各种不同的引擎、插件和实验室渲染，这是一个庞大的课题，我今天不会深入到细节部分，不过我需要说明的是，版本管理是非常重要的部分。我们想要你对你的版本能持续运行保持信心，因为我们也知道回滚旧版本的痛苦。

图9.49

而另一方面，未来我们想做到的是，你现在做的能运行于目前硬件的游戏，在还未被设计出来、或是正被在设计的硬件上也能运行——设计的人可能是在座的人，甚至可能是还没成立的公司。我们知道我们不能面面俱到，但是只要你付出了，它就会连本带利的回来。比如说，为了预见到新硬件未来会变成什么样，我们有API来让你说明手柄是在左手还是右手的，因为有些硬件是固定了的。

我们也有渲染模型。如果你的游戏想要展示手柄的形象的话，就只需要请求API给个模型，然后游戏内就可以显示模型了。我们发布的模型，比如说Vive的，都是非常精细的，所有的部件都可以移动，也同步了所有的按键，如果你想要在上面加上箭头——我知道这比单纯载入模型、在上面拖一根线更有效——，最关键的就是，如果你这么做了，你的游戏在未来的新硬件上也能无缝运行。

我们甚至持续对旧平台进行支持，我们同时支持Oculus Runtime 0.8和0.8以上的版本作为两个不同的驱动，因为这对我们来说并不难，而这样也可以让DK1用户能继续游玩。

图9.50

如果你有一个定制驱动，如果你在开发完全定制的硬件，跟我们谈谈，将它放到Steam上发布，这样用户们就可以一键安装、自动更新了。同样我们希望驱动为应用提供向下兼容也能实现，所以如果你在做了一个定制驱动，而我们发布了让它不能运行的内容——这还是很有可能的，毕竟我们还在beta阶段——请务必让我们知道，这样我们就能尽快进行修复了。

图9.51

另一件事情就是，我们正在尝试在API中加入新技术，因为这些新技术找到共同点意味着开发者们能有一个单独的目标，也意味着开发设备的公司能以API为目标来写一个驱动，获取到所有支持它的已有内容。我们已经跟在做比如手部追踪和iTracking的公司进行交流，也找到共同点，不过如果你正在做写奇奇怪怪的东西，务必来与我们交流，因为我们想要给人们一个一致的目标。如果我们做到了，那么现在制作的游戏在未来的硬件上也能继续运行，在做新硬件的人也可以继承整个内容库。

图9.52

回顾SDD 2014，当我们给你们展示VR的时候，你们看到了很多方块——你站在方块上、方块里、被方块包围——实际上我写了很多使用你们当时看到过的这些方块的VR追踪技术。我非常肯定当时我把头倾斜到方块里的时候，我的大脑对我说，『嘿，继续靠进去，你的头会从这个方块里被弹出来，然后你就能看到Joe了。』——当时Joe在现实当中就坐在我边上。你再也不需要用程序员美术（programmer art，指用于测试功能时的临时美术）来设计新硬件了，如果你在真实内容中使用手柄和头显，你就可以得到可能你都不知道需要回答的问题的答案了，而这些问题中有些会让你推翻重做。我们推荐你在早期就同步设计驱动，并对Steam上的600个（VR）游戏进行测试。

图9.53

这些就是我要说的，接下来就需要你们让我们知道我们做的如何了。我的email是benj@valvesoftware.com。我们希望授权给任何人的SteamVR追踪技术可以代表在VR中，追踪技术是一个被解决了的问题。如果我们错了，我们还有你们，因为我们的体系欢迎所有的硬件。

图9.54

最后要注意的一点，我鼓励你们互相交流。我们邀请了所有被授权人来到了SDD，所以很多在观众席里和在大厅里走动的人可能已经是硬件开发者了。他们中有部分人在考虑做PC外设、HDM，有些人把垂直营销作为目标，为此需要定制的控制器。所以我鼓励你们，如果你在做一款游戏，而你又需要一个控制器来让游戏更好，那么就去跟他们交流、告诉他们你想要什么；同样地，如果你在做硬件，有很多开发者制作的有趣内容能体现你在做的东西，跟他们交流、给他们early access、让每一个人参与进来。这就是为什么我们有happy hour，会在5点跟你们见面。

图9.55

非常感谢今天的到场，接下来是提问时间。我们应该还有些时间。（观众掌声）

（Q&A部分）

Ben：

这儿有人拿着麦克风，第一排这里有位先生举手拿到了。

提问者1：

我想问关于多光源（multiple lamp-houses）的问题。如果我们想要有几个光源，现在的技术中有支持的东西吗？还是说你可能需要改变负载循环，让它在不同的光源下切换来产生重叠光？还是说未来为加入不同频谱之类的，将改变表达到ASIC和API上？

Ben：

我认为大家应该听清了问题，我不需要重复一次，对吧？问题基本上就是一次有多个光源——多于两个——，现有的技术是否支持它。答案是，是的，很多技术支持，我们也专注于传递我们认为现有的最好的家用VR系统，所以肯定有很多这方面的工作的计划。我没有什么特定需要的技术需要说明的，不过你提到的那些东西都可以实现，增强的传感器、调频，这些都可以实现。

另一个第一排的先生。有吗，哦对不起。中间这个地方有条线。

提问者2：

我们都是超级粉丝。各种形式上都是很出色的演讲，感谢你。

Ben：

谢谢。

提问者2：

我喜欢你们要做的，探索各种类型的控制器。我知道我们当中很多人考虑过枪类控制器，我以前见过Armory，不知道你们在不在场，我非常想跟他们见面。对于枪有什么计划吗？我知道在PS中有瞄准控制器，特别标准化，那我们在商店里有吗？

Ben：

哦，枪的标准化。我前面说过，300个人已经注册了，我要尊重他们的保密性，不能谈论他们的计划，我想让他们来宣布他们自己的计划。不过我大体上能说，我知道枪械追踪是很多人感兴趣的东西。我不知道你是游戏开发者还是只是一个超级粉丝，如果你考虑过枪如何标准化的话，显然在API中，我们会提供一个渲染模型，所以你就知道实际物体是什么样的，API也会提供特殊的整合比如各种按钮和其他控制的位置。完全通用地支持某个东西是一个挑战，但是肯定也是API能实现的。

提问者2：

那么定制控制器的运送呢？有没有什么计划，比如，将那些定制控制器集成到，呃，送货中？

Ben：

我理解你在说怎么了。我们不是那个运送，呃，包裹Steam，对不起，VR系统包裹的。不过我猜测，我们会告知更多的受众箱子里可以有什么，比如枪、棒球棒、网球拍、高尔夫球杆之类的，来作为配件，而不是将它们打包到箱子里。这只是我的猜测。

提问者2：

好吧，谢谢。

Ben：

谢谢。

提问者3：

我可以问个问题吗？我刚刚在想，在真实情况下开发板的固件有多开放？能加入额外的软件吗？还是说固定了算法之类的？

Ben：

这非常有挑战性。因为一直以来灵敏度和低延迟都是实时处理中的问题，如果你在嵌入式环境中做过的东西的话，你知道会共享这些资源也是个挑战。目前我们推荐的是，让对硬件特别熟悉Synapse参与到修改中。我们也知道人们会不满意这个限制，所以我们也在努力以能让你完全定制的方式进行提供。

好像中间还有些人（有问题）。

提问者4：

嗨，我想到不久前Alan Yates提到了基站的距离，范围是限制在5米以内，出于脉冲、好像是同步脉冲的原因。现在还是这样的吗？我们能加入自己的中继器或是外部同时发出脉冲的红外光源吗，使得游玩范围能扩展到25米，而分辨率只要求小于1米吗？

Ben：

当然，我的意思是，现在还是这样的。挑战在于，如果你想一想基站和同步闪光灯，当闪光灯发光的时候，想象它发出了在房间中**的一页纸一样的光。这张纸随着距离的增加会变大，因为它在长度和宽度上都会增加，所以是乘以R的平方；而那条线只是向外展开，所以他的增长幅度是R。所以他所说的限制的原因就是，天生地，不管闪光灯有多亮，它最终都会衰减得比激光更快。我们已经谈到过几乎所有你刚刚形容的选项，但是现在，为了有一个远离激光的好生活，激光的亮度是和闪光灯的亮度进行过平衡的。仅仅是让它更亮并不能让现有的基站范围更大。不过可能未来会有一个更亮的基站。

提问者4：

谢谢。还有个问题，我们必须将Watchman放到我们的最终产品中吗？还是说它仅仅是早期快速制造原型的选项之一？

Ben：

好问题。Watchman电路板只是快速原型制作的选项，并包含了所有的关于所有板载电子器件的文件。你有全部的图纸和这个模块的样品布局，可以完全包含在你的产品中。

提问者5：

我有个关于配置光传感器的问题。为控制器上的光传感器定制以一个布局的难度如何？以及，至少需要多少个传感器来有序运行？

Ben：

这两个是相关的问题。正如我说过的，基础外形对它被追踪的质量如何有很大影响。这个问题比较的复杂，不过我要说的是，显然越大越好，当你需要做小的东西的时候，就会带来挑战。你需要在每个方向都有能看到的传感器，你可以想象得到，因为你需要它在旋转的时候也能用。这差不多就控制了你需要多少个传感器，一旦你满足了有足够数量的传感器可见，我猜测可能不会比20个少太多，比如2015年我们发布的开发套件中的手柄有19个，Vive手柄有24个，头显有32个——某种程度上有点过头了，不过提供了很多的富余，因为你会到处移动你的手臂和手。这方面是有弹性的，特别当是你的目标物可能只需要在一个方向被看到就行时，传感器数量可以少很多。我们也有工具帮你放这些传感器，你可以做一个基本形状，而我们会建议出放它们的位置，然后你可以做出些改变，问问工具效果会是如何，它就会给你个热图显示你这里做得好、那里做得差，这样你就可以进行调整。这可能是设计一个追踪控制器中最需要努力的地方，因为HMD相对而言非常大，你放上了传感器，运行得很好；而相对地，你需要将控制器保持在小型，离手也近。手臂、手部会在特定角度进行阻挡，你还想要它是小的，这才是挑战所在。这需要你自己的创造力，我们也有帮助你测量做的怎么样的工具。

提问者5：

我还有一个简短的问题，未来有计划允许更多个光源吗？我知道在有超过两个光源的时候会有一些特定的干扰。（这人没听前面的问题吧）

Ben：

这个问题其实刚刚已经问过了。对于第一个问题的回答你有什么（问题）……

提问者5：

事实上……我猜我刚刚错过了那个问题。

Ben：

简短的回答就是，我们当然对允许更多光源感兴趣，但是我们现在没有要宣布的东西。

提问者5：

谢谢。

提问者6：

你好，非常感谢你的演讲，我学到了很多。我最大的一个顾虑是，做外设，尤其是做我们之前看到的硬件开发套件里的那个一样，遮挡问题。当有两个人在同样的基站下使用Vive的时候，遮挡变成了很重要的问题。我怀疑人们在开发自己的外设的时候，这更成了一个问题。这方面有什么正在做的和你能讨论到的可以解决或是防止这个问题的提升吗？

Ben：

我认为你能做的限制遮挡的第一件事就是将基站放在高处。这就是为什么在所有demo里面我们都这么做的原因。因为这样，帮助demo试玩的人可以绕着试玩demo的人来回走动，而光是从头部上方下来的。我们主要用于免除遮挡的方法就是，一旦我们开始追踪，我们只需要非常少的传感器就能保持追踪了。如果你进行过尝试，你拿到目标物后尝试覆盖它并阻挡它，其实是非常难的。我知道它是怎么工作的，但对于我来说也是出乎意料的难。我觉得这方面可能不会有别的那种特殊的计划，除了之前我说过的更多的基站可能在这方面有所帮助。这就是我今天能说的。

提问者6：

谢谢。

提问者7：

你好。我有几个问题。第一个，对于获得传感器的最高质量，你有什么样的推荐？换句话说，光线反射、玻璃、白板，这一类的东西，让干涉最小化。

Ben：

我们确实一直在软件上最小化这个。如果你在设计一个目标物，确保它不会将光反射确实是非常重要的，不然可能会很麻烦。同样地，将基站放在高处也非常有用。因为基站形成的图像是像，这样，图像，反射，然后图像就这样到了地板，而这不是你所在的位置。（感觉回答的不大对啊）

图9.56 现场截图，左手表示基站，右手表示目标物。

提问者7：

还有个问题，有没有关于IR（红外线）在使用的波长的信息？

Ben：

我本应该不用查就知道的，但是我不知道。我猜是835。

提问者7：

835，好的。

最后是，被追踪物体的数目有限制么？这部分跟蓝牙%&&…（被打断了听不清）。

Ben：

正如你说过的，只是遮挡的问题。你可以将整个房间从地板到天花板都放满被追踪物，如果不管它们会互相遮挡的话，因为完全没有返回基站的交流。你可能是这么考虑的，因为我们用类似蓝牙来进行开关，但是对于追踪操作来说，我们完全不会给基站什么信息。你想想那个铝色的原始基站，在里面没有无线电装置，它只是被放到了墙上，仅此而已。

提问者7：

我的意思是，被追踪的单独目标物越多，需要……（又被打断了）

Ben：

对于一个特定的主机，目前驱动有一个随意的限制，大概是16，不过那完全只是随意的。如果有人给我们展示了需要远超过16个的使用情景，那么我们会改掉这个定义，重编译驱动，发布一个新的。版本兼容，所有人获利，耶。

大概是工作人员：

好的。还有一个问题。

Ben：

好，看起来我们还有一个问题的时间。

提问者8：

谢谢。简短的问题，跟第一个问题有关，别人也问过了。但是，就目前来看，要实现的话，需要两个基站之间有参照。最终有可能做到吗？我知道人们有无私的目标来让它跟WiFi一样无处不在，你到处走、每个都可以有。它有可能——我不知道你能说多少——在目前的技术下有可能让它成为更像一个网状网络，你可以，从比如利用一个或者两个Lighthouse，让它们能从一个房间到另一个进行交流，而不丢失追踪吗？（一点都不简短）

Ben：

这显然是我们感兴趣的东西，很多核心软件的部分也支持它，而我们也在致力于制作让这成为可能的硬件。

提问者8：

酷，谢谢。

Ben：

谢谢你们的问题。谢谢参与。

（观众掌声）

10.《方舟：生存进化》中的用户创作内容与创意工坊

By Jeremy Stieglitz (Studio Wildcard)

（观众掌声）

大家好，我叫Jeremy。我是Studio Wildcard、当然也是《方舟：生存进化》（以下简称ARK）的主设计和主程序员。

图10.1

我今天要讲的内容是ARK中的用户创作内容（以下简称UGC）和Steam创意工坊。我们为何以及如何做这个，做的时候遇到的一些挑战，以及为什么你也需要这么做。

首先让我来给你一点背景情境。当我们发布ARK的时候，我们并没有计划在第一时间就有UGC，但是在发售后很短的是时间内，很明显我们跟不上玩家们预期的游戏内容。人们很快地就将我们已有的内容翻了个遍，然后想要更多、更快的内容。我们就想『我们真的可以做这个叫UGC的东西吗？』我以前在之前一款叫做Dungeon Defenders的游戏里面做过，我就说，我们可以在技术上提取出来，可能可以通过让玩家参与进来的方式解决部分挑战，而不需要我们每天做新内容。我们确实不得不仔细考虑这么做的优点和缺点，而这部分我今天也会讲到，UGC的一些好处和一些坏处。

图10.2

第一个好处就是更好的参与度。你基本上将你的玩家变成了福音的制造者（evangelical creators）。不同于你做出东西，他们进行消费的单行线，它实际上成为了一条双行线，他们做出的东西，别的玩家也能消费。我认为，这最终创造了一个更有协作性、更积极的社区。它非常的有建设性、创新性和艺术性，我认为这是释放了你的社区的能量来帮助扩散你的游戏，而不仅仅是消费者。

图10.3

第二点就是，我在第一张幻灯片的事实提到了，就是喂饱了野兽。从根本上减少了你作为开发者要开发日常新内容的压力。我认为每个做过游戏的人，尤其做过是不断更新的游戏，都会感受到那种不断加入更多内容、让玩家有新东西可玩的压力，而说实话UGC带走了很多这一部分压力。

图10.4

第三点就是，你们可能很幸运地得到了UGC里的unicorn piece（unicorn他幻灯片有解释，就不翻译了）。UGC内容实际上改变了人们如何看待这个游戏，提供了巨大的附加值。当然这并不能保证，事实上它们可能性不大，但是如果你支持了足够能力来让玩家为游戏做出足够强大的东西，那么还是有可能的。在游戏史中，除了这三个MOD改变了它们所基于的游戏的性质外，还有有很多其他的例子，不过近年来的著名的例子就是Arma 3（武装突袭3）上的Battle Royale（大逃杀），Warcraft 3（魔兽争霸3）上的Defense of the Ancients（DotA），以及Half-life（半衰期）上的Counter Strike（反恐精英）。我记得甚至是Team Fortress（军团要塞）如果我记得没错的话，在过去也是Quake（雷神之锤）上的一个MOD，这已经要追溯到很久之前PC游戏的MOD历史，而UGC打开了如此惊人的内容的可能性，改变了人们看待游戏的方式。

图10.5

自定义。每个人都想要稍有不同的体验，每个人都想要你的游戏有一点点不同，而如果你支持了UGC，创造者和玩家们就有更多机会来自定义游戏成为他们想要的样子。虽然不需要UGC，你也可以在游戏中提供足够多的选项让他们打开或者关闭各种特性，但是一个好的UGC实现方式可以让他们进入游戏本身内部，实实在在地改变东西。比如在ARK中，我们有科幻小说和现代技术元素，而有些玩家不想要这些，他们只想要更专注于原始生存的游戏，而这并不是我们会为他们做的游戏。但是UGC让他们可以在ARK基础上为他们自己做出这个游戏。

图10.6

另一个好处就是，UGC在某些方面是高效实验室，用于目前或是永远都不能出现在游戏中的想法，而对于玩家来说风险更小。有时候开发者们会在UGC上进行迭代，因为它们是非常可选择的、实验性的，如果你准备删除一个UGC，它不像删除DLC或是删除核心游戏的一部分。它可以同时为玩家和开发者——更多是玩家——所用，而它也可以作为新想法的试验田。有时候这些想法运作得很好，那么就可以加入到主游戏中，之后我们会有一些这样的例子。有时候玩家甚至解决一些问题，比如开发者遗留在游戏中的bug和平衡性问题。我们的ARK有许多玩家觉得比原来的游戏更好玩的平衡性MOD，有时候我们就会把这些改变加入到游戏中，即便我们没有加入，也至少提供给了玩家一种不同的游戏方式。有时候你的游戏是随着玩家修复游戏已存在的问题而变得更好的。

图10.7

另一个原因就是，它可以延长产品的生存周期。基本上所有游戏、所有产品都有自然的生存周期，而在某些时间点，开发者们可能会想继续续做下一个新游戏，即便他们没有这么做，他们也很有可能随着时间推移，创造的内容在不断减少。但是一旦有了UGC和有力的实施后，生存周期就可以得到极大地延长。我知道有人可以画出图来，我认为任何有UGC的游戏都会有更久的长尾效应，包括玩家基础、活跃玩家、以及最终的销量都会持续更久，而原因就是玩家们不断创造的新内容。而你会发现，无数个在多年前发布的游戏的例子，从开发者那里并没有什么特别重大的更新，而多年之后，玩家们仍在为这些游戏创造新内容，而这就保持住了玩家们在这段时间内的兴趣。

图10.8

最后一个原因，它很有趣。我们创造游戏是因为我们喜欢制作游戏、看到人们游玩的过程，另一层面就是看看人们能在你为他们开发的系统上做出什么样的内容。每天醒来看到游戏内新的物品、想法、创造性的美术非常的有成就感。那些我们不可能自己想到的东西，但是庞大的玩家基础可以想到，这同时激励和促进了我们这些开发者，也在我们和玩家之间建立了更稳固的联系，因为他们知道游戏是怎么工作的，从而对游戏有了更多的拥有感。

图10.9

当然也有一些坏处。并不是所有的都是鲜花。如果你要做UGC，那么你至少要考虑到这些：它们并不是都适用于所有游戏的，而是取决于——我认为——你加入的UGC支持的深度。这一点非常值得提到，它们取决于你所使用的引擎，从而会有一些技术上的挑战来实现一个好的UGC系统，它们也取决于你想给玩家多大的权力。同时值得一提的是，一旦你发布了UGC支持，你需要将它纳入到未来的更新中，以便不会破坏玩家们已经创建或发布的内容、不取消他们所依赖的特性。这就会使你的QA（Quality Assessment 质量评价）流水线变得复杂，因为显然不存在测试到所有玩家已经发布的内容的方法。所以你需要非常清楚地意识到他们是如何使用你的系统的，这样你在未来的更新中就不会不小心破坏掉它了。故意破坏它们，然后指望人们重新更新他们的内容并不是个好主意，你会发现很多玩家甚至是内容创造者会再也不会去做了。

图10.10

第二个坏处就是它会稍微稀释掉基础内容本身，人们对你官方内容的关注可能就不会那么多了。我其实并不觉得这个是负面的，但是值得注意的是，你不会是城里唯一一个玩家（指你不是唯一一个发布内容的人），所以说些话，为游戏发布新内容。如果有所顾虑，那么你需要将之和UGC实施的深度进行权衡。

图10.11

尤其对于在线游戏来说，这是一个潜在的会打碎你的玩家基础的顾虑。取决于你的用户基数的规模，你可能会希望所有玩家都玩一个相同的模式或是同一张地图。如果你支持了UGC，那么你可能会有很多的模式和地图，而最终玩家们会扩散到更多的可能性当中。如果你的玩家基数不够大，这会可能会导致在线游戏玩家的稀释。这一点值得牢记，再说一次，取决于你是否支持新地图和新模式。

图10.12

在发布支持UGC时有必要拉开点窗帘，将它是如何运行的暴露给你的玩家看。这可能会有些尴尬，他们可能会看到你用的一些小把戏、黑科技和作弊。取决于他们能访问到的代码和脚本的层面，他们会看到所有你的神奇数字；取决于你如何打包和分发内容，他们甚至可能可以看到你之前没有提到要发布或是尚未发布的内容。不过透明性一直都是个好政策，玩家很可能总是可以通过不同的技术反编译手段来找到所有这些内容。所以这部分也不是什么大问题，只不过提醒你们可能会重蹈我们在ARK和Dungeon Defenders上的覆辙。

图10.13

这里当然也有对UGC支持的挑战。UGC有自己的bug，其中有些是因为做了些错误的东西，但但部分情况下是玩家或是内容创造者加入了bug，他们自己不小心加入了bug。以一个最终用户的立场来讲，最终用户并不是必须要认识到『好吧，我是在一个定制内容上玩，所以如果我找到了bug，我应该联系这个的作者』。他们很可能会认为这是我们游戏、我们的内容的bug，然后他们就会来联系我们，所以这就会给顾客支持和问题分析带来一点工作量，跟他们说『你在运行的UGC物品有哪些？有可能是因为那个，让我们用那个重现一次试试』，然后在回去联系原始作者。你的顾客支持渠道会在某种程度上因此而变得复杂。

图10.14

取决于你如何将你的内容一起打包给UGC，你可能会需要发布比通常游戏该有的还要多的内容，或是更低效的内容，因为UGC大部分是依靠载入单独的资源。拿ARK举例，我们最初发布的优化后的内容是seek free loading（无需寻址读取？）文件，它们可以从磁盘上连续读取，来减少硬盘寻址。为了支持MOD，我们不得将游戏变为单独的文件，这样MOD就能以随意的顺序进行加载。这几乎使游戏的大小翻了个倍。在我们这个例子中，支持强力的MOD功能是一个很值得的交易，但是这取决于你的游戏引擎，也许你要考虑到下载的问题。

图10.15

最后就是，总是会有不适当内容的可能。对于很多、或者说大部分游戏来说，这可能不是一个问题，但如果你的游戏是明显以孩子们作为目标的，或者你想对在YouTube之类上展示游戏内容有一个非常严厉的控制或统治，那么你就需要注意到当你提供了强大的UGC工具时，人们可能会将他们能找到的最不合适的东西放进去，还有画其他IP里的东西这样的侵犯版权问题。这些在Steam创意工坊上可以手动管理，但坦白地说，开发者们可能要做其他更重要的事情。同样地，这也不是什么大问题，但也是你需要意识到的东西。

图10.16

我想谈谈我们在ARK里面支持的UGC类型，其中有些是ARK中的特定概念，不过我认为大体上有可以从中收集到的部分的。

我们支持地图，也就是可供游玩的完全新的环境。需要注意的是，你不能用一张地图来改变已有的内容，你可以加入新内容、复制已有内容并加以修饰，但是任何新的艺术作品之类的，都需要被打包放在新地图的一个特定位置。

图10.17

也有我们称为『地图扩展』的东西。扩展是可以堆叠的，所以上一张幻灯片中的地图是一个全新的环境，而地图扩展则是像一小块环境，而你可以将它们放上去。它们可以是浮岛、NPC、新的天气系统，而不需要明确的是实物上的东西，你想加多少就可以加多少个。我们在游戏里有一个界面用于最终用户选择想要多少就多少的地图扩展，加载到基础地图的上。地图扩展可以用于原始游戏地图，同样也可以用于任何一个定制地图。

图10.18

终于谈到了MOD。MOD不是环境，它们通常是新的物品和新的生物。它们可以堆叠，意味着你可以加载任意多个MOD，来加入越来越多的物品。也有一些MOD可用的不可堆叠特性，比如改变核心游戏模式，本质上就是核心游戏逻辑，你的目标、所有应用层面的循环逻辑都会在这里。MOD也可以改变这个，不过如果一个MOD能这么做，它会被认为是不可堆叠MOD，你同时只能在那些类型的MOD中选一个运行。

我认为对UGC来说，堆叠这个概念其实非常重要，这可以允许同时多个MOD的加载。因为没有一个人能创造出完美的UGC，在里面加入所有人想得到的所有东西，通常用户们创造的UGC都是针对一件事情。允许最终用户可以自行组合它们，也是定制化的一部分，我也认为极可能大地利用系统是非常重要的。

图10.19

最终我们有了一个叫做『Total Conversion』（完全转换）的概念。Total conversion是MOD的中特定的一种，让玩家可以直接改变游戏内的所有东西。通常使用MOD时，你不能改变已有的游戏素材，因为它们已经被加载了。你可以加入东西，但是你不能删除或是修改已有的内容。但是在Total conversion中，它会改变所有它想改变的东西——不管你愿不愿意——，没有任何限制。单从高效地开发一个全新的游戏来说，这个途径是非常强大的。

图10.20

这里有个例子：对科幻小说元素的转换，有人做了一个海盗船转换。它非常深入系统内部，给了它很多的权利。但是也有一些缺点。因为我之前有提到过的无需寻址内容，total conversion需要完全关闭这个系统，因为我们根本不知道用户会修改什么资源，就导致我们必须单独地无序地加载它们。这就不得不导致了更长的载入时间。

图10.21

下面谈谈做一个深层UGC应用时会遇到的技术上的挑战，我会先特定地讲讲虚幻4引擎，然后再讲任何引擎上都可能会有的全方位的挑战。

单就在虚幻4引擎上，我们至少要修改编辑器来支持『烹调』UGC，而运行时，客户端运行时也需要支持载入UGC。这跟『烹调』基础游戏不一样，在虚幻引擎中『烹调』意味着将董其打包成可以发布并分发给最终用户的形式，而UGC的『烹调』方式是它可能不会包含我们已发布游戏中的所有资源，从而确保文件是较小的。

不仅仅是如此，我们还需要修改发布给最终用户的编辑器，加入集成的SteamCMD。SteamCMD是一个命令行应用，允许上传内容到Steam云。我们将它集成入编辑器，这样用户就不需要担心需要发送给SteamCMD的准确命令了，而是在用户界面就可以运行。

虚幻4引擎还有一点很重要的是，你需要决定在『blueprint』中写入多少内容，相比于C++，blueprint是一个高级的脚本语言。毫无疑问，Steam创意工坊不是为支持分发可执行二进制代码而设计的，如果你能这么做，你也不应该做，不然会成为一个很大的安全风险。你在高级脚本里写的越多，你的最终用户就越有在UGC中修改东西的权限。高级脚本，尤其是虚幻4引擎中blueprint的缺点，就是需要牺牲性能。所以如果你的游戏像ARK一样需要性能增强，那么这是一个困难的选择。你想写多少在其中一个系统中，还是写在另一个。如果你用C++写的更多，那么性能更好；或是用blueprint更多，那么Moder就有更多的权力。

图10.22

UGC也有整体上的技术挑战，无论你是用什么游戏引擎，你都有可能需要面对。

客户端层面你需要有在运行时有异步下载UGC内容的能力。也就是说，当用户订阅了UGC，游戏会得到一个请求说明『已经订阅了新的内容，开始下载它』，可能也会提供一些用户界面通知表示UGC在下载或是安装——我的意思是你需要在游戏内的用户界面中能看到它。这一点是必须的。而在另一方面，如果你的游戏是一个多人在线游戏，服务器会有任意的UGC、任意的内容包、任意的MOD安装在上面，而客户端在连接服务器时可能完全没有安装它们。所以我们只好加入了一个系统，当你连接到服务器时，会进行一次握手，服务器会告诉客户端『我有运行这10个单独的MOD』，而客户端就需要检查『这些我都安装了吗』。如果没有，那么它在完全完成与服务器的连接前就会去订阅、下载和安装它们。这就是中间要做的一点工作，我认为可能是不管是什么引擎，任何一个在线游戏都必须要做的。

你也需要支持在服务器层面的UGC更新。如果你有专用服务器或是长期服务器，它们需要更新UGC，因为某个时间点最终用户会上传新版本，而在什么时候做这个事情是一个有争论的问题。在我们的例子里，我们只在你启动服务器的时候进行验证，我们不得不在服务器的命令行里实施（这一政策），这稍微需要一点额外工作。与此同时，总是有出现客户端和服务器不匹配的可能。一个长期在线服务器可能运行了好几天、好几个星期、甚至是好几个月，而且从来没有关闭过，而一个客户端可能每隔几个小时就会关闭和重启。如果最终用户更新了UGC，在客户端上有了更新版本，而长期服务器上是运行了好几个月的较老版本，那么当客户端连接服务器时，就会产生版本不匹配，有可能它们再也不能进行对话了。如果改变非常大的话，它们会破坏网络通信。这没有完美的解决烦恼方法，我们不想强迫服务器必须重启，最好的情景就是你可以给客户端呈现一段信息说『这个UGC在服务器上是V3版本，而你的是V4，发生了不匹配，无法连接』，然后客户端可以告诉服务器管理员说『你真的应该重启你的服务器来更新了』。这是一个让人头疼的问题，可能未来可以通过Steam保持Steam云中的UGC优先版本来解决，但这已经超过了我对这个系统的认知范围了。

图10.23

我之前也提到过长期维护的问题。游戏未来的更新需要在某种程度上回过去测试已有的流行的内容。同时也值得一提的是，UGC工具本身会成为一大块下载内容。尤其是当你还在EA阶段、并非常快地更新游戏的时候，你会每天或是每周加入很多新特性，你的最终用户会给你压力让你同时持续更新这些工具，这可能会在开发过程中加入一些开销。

图10.24

我要讲讲UGC是如何在ARK上转出的，以及我们使用用于确保它成功的一些技术。

我之前提到过，我们在游戏发售后没过几周就有了UGC的计划，因为我们意识到它会对保持一个大量、快速的游戏更新内容非常有用。我们大概花了6周左右的时间来实现系统，最终我们在2015年8月15日发布了工具，并支持了创意工坊。

图10.25

我们做的第一件事情就是发布了MOD比赛。它对于刺激玩家非常有帮助，而不仅仅是说『嘿这个超赞哦，你应该试试』。我们想给他们一个真实的——你可能会说是金钱上的——刺激，来展示他们能做什么，做出厉害的东西。我们觉得这非常有用，因为我们得到了很棒的结果，我们有数百位参与者，而其中有些最终让我们大开眼界。等会儿我们就会看看其中的一部分。

图10.26

我们也创建了一个程序。这是一个非正式程序——我们的用户也知道——，我们用它来联系那些我们认为足够好的MOD或是UGC的作者、询问他们是否能够通过补偿他们来将他们的内容加入到游戏中，不仅仅是在Steam上，同时也会带到其它平台。这就是我们运用UGC系统的结果，这就像我之前提到过的早期试验田，提供给那些额外的游戏内容。

图10.27

有些MOD最终被官方地加入到了主游戏中，其中一个就是《方舟：大逃杀》（Survival Of The Fittest其实我愿意叫他适者生存）。这是一个total conversion，我之前有提到过这个概念，意思就是它改变了游戏的每个方面。而它也需要这么做，因为它将一个长期的在线生存游戏变成了激烈的战斗竞技场、饥饿游戏风的体验。它最初是一个total conversion，而我们将它加入制作成游戏的DLC，或者说是另一个游戏。

图10.28

另一个就是一张非常棒的地图，叫做『The Center』，是由一个最终用户Ben Burkhart制作的。他将这个提交到MOD比赛上，最终获得了胜利，或者更确切的说是快要获胜了，然后我们觉得『这太他娘的棒了，我们要把它带进来，缩短比赛时间』。这是一张非常好的地图，我们最终把它带了进来，雇佣了他来现场和我们一起工作。现在这张地图在所有的平台上都有。创意工坊的东西从这个方面来说就是最终内容的试验田。

图10.29

另一个MOD叫做『Primitive +』。这也是一个total conversion，改变了游戏的所有方面，作者是Cedric——我忘了他的姓，对我来说他就是Cedric。类似的情况，这是个total conversion，将所有的科幻和现代技术从游戏中移除，加入了很多专注于原始生存的内容——各种各样的机械学、物品、武器，无数这一游戏层面的细节——，有许多的玩家、粉丝。我们觉得这是我们自己不会专注于的内容，我们就说『我们把它也带进来吧』，然后它就成了游戏的官方部分，同样我们也雇佣了Cedric。

图10.30

前面这些就是一些已经通过了官方MOD程序的内容的例子，而我们在未来几周内还会有几个。而我想给你们看一些ARK中UGC多么有影响力的一些数字。超过60%在线游玩ARK的玩家在多个或一个运行UGC服务器上游玩，比如地图、MOD或是total conversion。所以大部分玩家都从中受益，而且我认为如果没有这些内容，他们可能都不会来玩这款游戏。

ARK的创意工坊上最流行的MOD或内容，就从订阅者数量角度来看，有GlassMetal MOD——这是一个有点老套的MOD，基本给你很多你能造的不同的结构选择，你可以造很多金属和玻璃结构——，但是在ARK这样的游戏中有这么多人订阅就有意义了，他们想要这样的丰富度。有一个不在上面但也很流行的MOD——其实有很多这样的MOD——就是建筑类MOD，提供给你很多用于建筑的物品和结构，远远超过我们能提供的数字，让我们看到了数千个小物品、装饰品来让你的家变得像家。对于MOD制作者来说，这就是他们擅长的东西，而且由于它们都是可以堆叠的，就让最终用户或是服务器可以想加多少就加多少物品。

另一个流行的MOD是Annunaki Genesis，这是一个重新调整平衡性MOD，他们提取了游戏内的所有内容，并且改变了所有的数值。他们也加了一些新机制，不过重点是在于找到他们认为更平衡的游戏，更注重严酷生存的平衡。我们觉得还不错，只不过我们的目标是更休闲，而这个MOD是更硬核一点。

最著名的地图中有一张叫做Valhalla。它是一张美丽的、风景如画的大地图，有很多值得记忆的风景，提高了很多我们当时也不能掌握的东西的层次，拥有很多订阅者，是当下最流行的一张MOD地图——当然，要排除掉The Center。

图10.31

我们也有计划让ARK的UGC更强大。我们想要让虚幻编辑器产生UGC的功能变得更强；我们也想给玩家们直接有修改游戏内甚至是MOD中的素材的能力，而不需要复制它们；我们还想给玩家在更基础层面能控制自己在游戏内以何种形式出生的能力，现在游戏锁定你的出生是人类，到时候你就可以控制或者修改成别的；我们也在积极做出改变，让你能在不需要拥有角色的情况下控制所有东西。

一个非常好的测试是我们跟另一个叫做Primal Survival的组一起做的一个total conversion。这个total conversion可以允许你在ARK里直接扮演恐龙，经历恐龙的一生——我猜是从蛋到坟墓——而不是非要以人类的形态。这个应该挺有趣的。我们这么做的目的是为了让工具根本上有所进步，对我们来说这是用来看我们能让修改游戏变得多厉害的测试台。

我们同样也想给客户端更好的mod版本检查可见性。前面我提到过，服务器运行一个版本，客户端运行另一个，目前我们会说这中间有不匹配，但实际上我们想明确地告诉他们有的是哪个版本，而另一个有的又是哪个版本，这样就可以给他们关于如何解决的更多的信息。

图10.32

如果Valve在听的话，我确实有一些请求给他们，zaima？（buzai）我认为Valve可以为创意工坊做出一些改变或是特殊版本，来让它变得更强大。第一个是有争议的，可能每个人都会有自己的观点，而我的观点是这样的：我认为他们应该允许优质的UGC直接加入——我知道有个收入分配系统，而且还需要开发者把关，我认为将开发者从这个情况中拿出来会很有用，因为当东西没那么集中化控制的时候通常是最好，而容下MOD作者会提供财政上的收入选项，这样可以提供激励提高MOD质量，也为很多想要进入游戏行业、但还没准备好获得行业内全职工作的人——有些人不想，有些人还在学习——提供了垫脚石。这就是一个介于『我做的东西是免费的』和『我得到了一个在办公室的全职工作』之间的中间项，『我在为已有的游戏做优质内容』，而我也认为对于最终用户和内容创造者本身来说都是非常有用。

图10.33

更多的创意工坊储存空间。因为现在的游戏是3A级的，材质是4K的，模型有100,000个面，由于这些文件的大小，我们相当于在夹缝中爆发，而Steam云给UGC造成的限制也在逐渐增加。我认为它可以再前进一段路，让这些3A级内容可以更复杂。

图10.34

我之前提到过的概念，UGC中加入『分支』（branches）概念非常有用。作为开发者，我们显然有这样的能力，但是对于UGC来说，最终用户并不能。如果他们上传的东西，那么它就上线了，之前的所有版本都消失、毁灭了，只能希望所有东西都是顶呱呱的。发布分支意味着允许UGC创造者更有效、安全地进行测试他们的内容，甚至可以解决一些挑战，例如服务器是否有一个版本但是客户端没有，比如为长期运行的服务器提供不怎么更新的版本，而给日常迭代提供更不稳定地实验性版本。

图10.35

据我所知，SteamCMD是一个单独的命令行应用，制作一个库能帮助工具更无缝地连接。目前你不能将上传至创意工坊UI体验变为一个完全集成的UI，你需要启动这个命令行应用从中获取反馈。如果他们能将它变为一个库，我觉得这样可以在工具层面上带来更平滑的最终用户体验。

图10.36

这个概念很有趣，现在你上传UGC的时候，你就是它的拥有者——你一个人——，而如果你在一个10人团队里， UGC最终都会被个人掌握。我知道他们可以分享，说有别的人在这上面工作，但只有一个人能有权限来继续更新。这对于有较大团队的复杂UGC来说是比较困难的，如果那个人，或者说联系人、原始上传者，消失不见了，或是生气了，或者是发生了什么，导致把所有人都封闭出去，那么这个UGC就已经没救、注定要灭亡了。ARK上的一些大型的复杂的total conversion中就有发生过这样的情况，他们花了6个月时间开发，是一个比较大的团队。我认为分享所有权的概念会更加促进复杂团队开发UGC。

图10.37

在结尾，我会给你一些关于UGC需要记住的重点。

拥有UGC可以使你的游戏更强大，你会有更强大的社区和更长的寿命。我不认为UGC在什么方面是负面甚至中立的，它总是可以加强你的游戏。关键的潜在问题就是技术上的挑战和其它我提到过的缺点。这些是你需要问自己的问题，基于你所使用的游戏引擎，你是否想要解决其中的一些技术问题，你是否想要对你的产品有更少的控制。如果你的答案是肯定的，那么你的游戏肯定可以从中受益良多。最后，UGC中最重要的事情是，我们当初是为什么在这里的，做游戏是有趣的，看着人们制作UGC也是有趣的，可能比做游戏本身更有趣。每天看到游戏内有前一天没有的新东西的感觉非常棒，而你也不需要自己来制作，比如像值得敬仰的Pimp My Rex（ARK的一个MOD，图就是这个MOD的封面）这样的内容。下一页也有这部分特性。（我不知道为什么他要笑诶，难道这个内容很搞笑吗）（难道名字是『给我的恐龙拉皮条』？）

图10.38

差不多就是这样，我非常推荐大家严肃地看待ARK和Dungeon Defenders是如何获益的，还有很多Steam上的其他游戏，比如Space Engineers也有良好的UGC实施，这是值得的这么做的。

谢谢大家。（观众掌声）

11. 为 SteamOS/Linux 开发 Unity 游戏

By Na'Tosha Bard (Unity Technologies)

（观众掌声）

（PPT背景不统一啊）

图11.1

今天我们要谈一谈为SteamOS和Linux开发Unity游戏。

你们当中有多少人已经在用Unity？（观众举手，还挺多）哦，这个情况我很高兴看到。

图11.2

你们可能都知道Unity技术上是一个2D和3D内容创作工具和运行时（runtime），广为人知的是可以作为游戏制作引擎。但是跟现在的所有引擎一样，它在2D或3D内容扮演重要角色的各个领域都有应用。

图11.3

Unity有一个相当大的市场份额，我们非常骄傲。我们有很多用户发售了很多的游戏。另一个我认为Unity上很有力的数字是游玩Unity游戏的玩家绝对数量，我们非常严肃地对待我们的工作，而做一个像Unity这样接入到众多平台——这个数字我经常忘记，我猜可能是24左右什么的——是非常困难的。我们有一个相当大的开发组，很多Unity里的人都专注于引擎的平台诊断部分。Unity是核心功能，而每个平台都有一个小组的人站在后面，负责该平台开发所需端口和功能。我要谈到的一点，或者说是主要的一件事情是，我要谈谈Unity在Linux和SteamOS环境下是如何工作的。

图11.4

如果你不知道我是谁，你可能在疑惑，『这个女人是谁？她为什么和我说话？』

图11.5

我叫Na'Tosha Bard，我在Unity是R&D（research and development研究与开发）的技术指导。我在Unity已经有超过六年的时间了，在这段时间里，我参与了很多不同的课题、发挥了各种不同的作用。其中这些年来我做的一件事是Unity runtime的端口，最近还有Linux上的Unity编辑器，我们将会谈到这个。

我们会谈到，每当你尝试为Linux和SteamOS生成你的Unity游戏的时候，有哪些是你需要做或者牢记心中的。我们会讲到一些常见的人们会踩到的陷阱之类的东西，这样你就可以小心了。我们会讲到一些更让人兴奋的东西，Unity中与在Linux和SteamOS中指做游戏的人有关的新东西，包括已经发布的和将要发布的东西。最后我们会谈到我们作为将Linux看作游戏平台的人的想法，我们在过去几年里进步了很多，但是我们认为仍然将来需要改进的问题区。我们最后会有提问时间。如果因为某些原因没有了，或是问题太多了我们的时间不够了，别担心，我之后也会在这里，我们明天也会来。我还是挺容易被认出来的，之后来找我就行了。

好的，我们就开始吧。

图11.6

为Linux和SteamOS进行生成。你们好像或多或少对Unity都有些熟悉，最主要的事情就是，点击『生成（Build）』按钮，好吧，并不一定是这么直接，但是对于桌面平台来说它就是这么直接。

值得注意的一点是，在Unity环境中，Linux的独立播放器和SteamOS是被认为是同一个对象的。Linux独立播放器是兼容Steam runtime的，在保证它是兼容Steam runtime上我们非常的小心，如果我没记错的话，我们一年前不小心破坏过与Steam runtime兼容性——相信我，我们听说了——，所以（笑声）我们非常小心。Linux独立播放器和SteamOS被认作是同一个平台。

图11.7

每次你选择Linux作为你的目标平台时，你可以选择不同的选项。如果你想要自动启用概要之类的东西，你可以使用一个标准的开发build。你需要选择一个构架，我们支持32位和64位。我们也有一个叫做『通用』目标的东西，只不过它并不是听上去的那样，我们没有单枪匹马地定义并应用一个多平台构架二进制，然后发布它、不告诉任何人——虽然我觉得如果有人能做出这个会很酷。它只是复制游戏数据——不管它们是32位还是64位的——，然后提供Unity播放器的版本，或者是32位和64位的两个版本，这样用户就可以加载到随便哪个是正确的他们的平台上了。

我看到的很多情况是，那些不一定熟悉Linux的人常常只生成游戏的32位版本，然后发布。很多情况下，这对于你的用户来说其实是非常烦的。因为大部分Linux用户，尤其是Linux游戏玩家是在64位机器上的，而32位程序，尤其是像Unity这种非常依赖系统库的程序，是无法在没有一些安装32位兼容库的情况下在64位机器上运行的，这就非常的恼人了。所以确保游戏的64位版本可用，这是非常有价值的。

针对Linux，我们还有称之为『Headless模式』的东西。它使用一个完全剥离了所有X11（X protocol version 11，X协议11版，Linux图形协议）的dependencies的runtime版本来开发游戏，它被设计为，大多数情况下用于人们出于某些原因需要在服务器上运行他们游戏的某个版本。很多Linux服务器被设计为完全的headless形态，他们没有视窗管理器，X11也没有运行——很多情况下甚至都没有安装——，所以这就是你需要的游戏版本，（前面说的并不对）你需要使用的目标（指这样的服务器），如果你恰好需要这个，你应该选择这个选项，它就是用来干这个的。

我们刚刚讲了一点关于你能构建的目标，那么运行游戏需要什么呢？

总的来说，一个C++ runtime和足够的OpenGL性能就够了。不过技术上有一点值得注意的是，现在的目标机器仍然需要运行X11，就在最近，足够的OpenGL性能需要implied X11。所以因为Wayland（Linux的一个图形接口协议）的发展，现在这句话可能不大对了。不过基本上还是C++ runtime和足够的OpenGL性能。我之前也说过，我们对保持C runtime的兼容也非常的小心。

当我们开发一个播放器的时候，我们将dependencies的数量降到了最低。我们尽可能的减少dependencies，将大部分东西进行静态连接，使有可能出现在最终用户机器上的问题被减到最少。我们只发布我们需要的东西，比如我们发布了用于我们脚本引擎的Mono版本，这是一个高度定制化版本的Mono，也是我们所需的Mono中的唯一部分。我们不会发布这整个东西。需要注意的是，这是我们做的，但是如果你在使用插件——需要其他dependencies的本地插件——那么就要另当别论了。Unity不会为你解决这部分问题，系统也不需要这些。有时候这有些是意想不到的，所以了解你的插件有什么dependencies以及最终用户机器上需要什么是很重要的。

图11.8

一个常见的问题是，Unity支持那些系统？

目前我们官方支持Ubuntu 12.04及更新版本，我们要求目标机器支持OpenGL core profile 3.2或更新版本。在Unity 5.3中，我们更换了OpenGL的实现，如果你使用5.3或是5.4，有个选项可以强制使用传统OpenGL渲染，不过在Unity 5.5及之后的版本中移除了。

另一件非常重要的事情是，我们支持有供应商支持驱动的机器，这些驱动是由NVIDIA、AMD或者Intel支持的。Intel的驱动是开源的，而AMD的驱动也可以获得源。必须使用的是这几种驱动，有时候我们有些用户是依赖于开源驱动，比如Nouveau之类的，但是我们不支持这些。

图11.9

另一个常见问题，其它的Linux发行版如何呢？

你知道的，Linux有点像Android，深受分裂和用户空间的危害。但是通常情况下，Unity游戏可以运行，通常可以，我前面也提到过，只要系统有兼容的C++ runtime版本和合适的OpenGL性能。我们也有过分析，告诉我们有用户在用别的发行版，我可以肯定。在我们发布Linux支持之前，我绝对没有想到过世界上有这么多的Arch Linux用户。（观众笑和掌声）如果你的玩家是在用别的发行版的，或者你在用别的发行版，尽管报告问题。不能保证我们能做什么——我们要对自己能和不能支持的东西保持务实的态度，我们选择Ubuntu也有一些不同的原因——，但是我们会尽量回复这些问题，不管这些问题来自哪个平台。如果问题发生在一个设置环境重现问题需要非常高代价的发行版上，我们基本不可能有时间去研究它。不过一定要报告问题，没有你不该这么做的理由。

图11.10

以上就是你们如何生成、我们支持什么这类的内容。接下来我想讲一讲一些常见的我们发现很多用户会陷入的误区和警告。

图11.11

第一个就是，我猜也在很多人意料中的，区分大小写。这常常发生于用户们先在Windows上开发了他们的游戏的情况，那里的TFS（微软的Visual Studio Team Foundation Server，用于管理代码）是不区分大小写的。甚至是在Mac上，HFS+（Mac文件系统）默认也是不区分大小写的。通常这个问题会出现在，当有无视大小写习惯的游戏开发者试图加载资源或素材的时候。除了注意这一点以外，也没有什么太多可以做的，尽量不要一直走老路，不然你过会儿就会不得不修正它，不过这一点也是挺常见的。我希望有一天，新的Apple文件系统发布的时候，它会是只有区分大小写的，那么这个问题可能就会消失了。我想我们会看到的。

图11.12

另一个是，手柄。手柄有些难办。手柄的布局和他们在Windows上的布局上不一样的，比如当你使用你的输入管理器，你需要知道你要预期的是不同的输入。值得注意的是，除了你用Unity输入管理配置输入外——如果你在用这个的话——，我们也支持通过Steam大屏幕模式或是SDL_GAMECONTROLLERCONFIG变量——这实际上就是Steam大屏幕模式使用的——来配置手柄。

图11.13

这一个非常有趣，locale命令。

Unity有一个——我们称之为——『quirk』（怪癖）：在Linux上，Unity会将locale作为它的父shell；而在OS X上，它不会。我认为，这是因为我们所用版本的模型的错误有关。我们可以说从技术方面，Linux上的行为是正确的，而OS X上的那个却是更方便的。问题就在于，如果我们将它改成任何一个状态，都会破坏掉很多的游戏，所以我们什么都没做。

这通常会导致的是，你为Windows生成的游戏是没问题的，为Mac生成的可能也是没问题的，然后你为Linux生成了游戏，突然在解析浮点数字（parse floats）上出现了奇怪的问题，比如1.53会被解释成1530。

如果你觉得你有这个问题，你可以尝试在开始游戏前设置shell中的LC_ALL这个环境变量为C。如果问题消失了，说明这就是你的问题。

一件很棒的事情是——这个常常发生于，在北美的时候，你开发所用的系统设置是英语，所有东西都没问题，你没有发现任何问题，但是在德国或者法国的用户想玩你的游戏的时候，他们会发现这种问题，你不能肯定发生了什么或是如何重现它。你可以做的有一件很棒的事情就是，在你发布游戏之前，你可以用不同的locale测试它，只需要设定这个LC_ALL变量，就在你打开游戏前的终端里设定，你可以尝试设置为法语locale或是德语或是别的什么，然后再看会不会遇到什么问题。

如果你有这个问题，比较好的事情是它是你需要在用户代码中修复的东西，而且它非常简单。这里有个例子，如果你解析一个浮点数字，通常人们会说float.parse，这样就行了。但是你实际上应该做的是告诉解析功能去使用一个与文化无关的cultureinfo对象，这样就表示忽略

系统locale是什么，而使用嵌入英语的cultureinfo对象，从而给你期望中的结果。如果你知道这个问题的所在，那么修复非常的简单。

图11.14

另一种陷阱和需要注意的是，我在这次演讲中好像碎碎念了好几次了，关于OpenGL和它与Direct3d的对照。Unity掌握了大部分的不同，这是我们做的工作之一。但是在某些情况下，OpenGL的说明是模棱两可的，这体现在不同的驱动团队有不同的解释。

我记得当我们发布在线Unity runtime支持的时候，我们就遇到了一些问题，比如说明说的是『在这种情况下，你不能写入到这个缓冲器』，它在技术上没有说明你可不可以从那个缓冲器中读取，而有的驱动决定你可以，有的驱动决定你不可以、然后给你无用的数据。我们就遇到了这样类似的事情。我们广泛地尝试找到并隐藏所有这些东西，但是有时候问题仍然会得到暴露，你会在OpenGL上看到你无法在Windows上用Direct3d时看到的问题。

奇怪的问题往往和着色器一起出现，这非常的不幸，因为对于着色器并没有什么好的诊断方法。但是这仍然是我们有的一类问题，我希望未来的技术能够修复它。

图11.15

以上就是主要的陷阱和警告。接下来我们会谈谈新的和即将到来的东西。

图11.16

一个已经发布的就是Unity 5.x，有着更新的OpenGL支持。这里有人只在用Unity 4而没有用过Unity 5的吗？好吧，这也不错。（看不到举手情况）

Unity 5装载了很多新的OpenGL好东西：我们终于支持了OpenGL 4.3，提供了compute、细分曲面技术（tessellation）之类的东西。我认为这些都非常令人兴奋，因为我们可以高效地获得等同于Direct3d11一样的渲染质量了。在我们发布支持Unity 4的Linux runtime的时候，支持OpenGL 4是一个非常非常普遍的呼声，而我们现在已经有了。

图11.17

另一个即将到来的东西是，它切换到了SDL2（一个开发库）。它有点像是我的宠物计划。

对于输入和Unity播放器的视窗管理，我们过去一直在直接使用X11，我们想知道当最终X11逐步淘汰、或者越来越多的最终用户使用其它的显示管理器比如Wayland和Mir的时候，世界会变成什么样的，以及我们该如何进行支持。

一个尝试使用SDL2作为一个输入掌握和视窗管理的抽象布局的主要动机就是，使我们准备好能在不需要拥有三个单独的原生实现的情况下，就可以支持X11、Wayland和Mir。过程非常的顺利，它允许我们从代码库中移除了很多非常难看的X11代码，非常棒。Wayland和Mir都快要到来了，但是很多方面它们还很不成熟，所以我们需要看看它们进展得怎么样。支持它们的SDL看起来也不是完全完成了的，但是抢占先机总是好的。

我们不是很确定它何时发布，大概是五六、五七左右个time frame（这个应该是指完成一个项目所需的时间，也就是说要再做6/7个版本的意思？）。我们会知道的。

对于最终用户来说，它会改变什么呢？实际上远不如大家所预期的，它会是超不多透明的。我认为从最终用户的角度来说，关于这个可能最值得一说的就是，游戏世界剩下大部分都好像都已经使用了SDL，而我们就像局外人一样还没有用过。如果有一个SDL的bug，那么用户把同一个工作用到其它游戏的中。不过对于最终用户来说，它还是会变得超不多透明了。

我个人对于这个项目非常地兴奋，如果有人想讨论，我也很高兴更多地谈论它。

图11.18

另一个就是Vulkan（Linux中可用的图形API）。我们在九月发布了一个实验性的Vulkan支持。我之前提到过，OpenGL有一些问题，而我希望这些问题能在Vulkan里被修复。Vulkan的性能更好，它有，呃有，叫什么来着？根本上来说，它在开发者立场上有一个验证层，这样你就可以检查你是不是在做正确的事情，而OpenGL只能靠runtime验证。这个，呃，整体上是非常让人兴奋的。我个人没有在这个项目上工作过，但是其他人，比如有些做Vulkan的人也在这里，如果你有什么问题，可以问问他们。

然后是，我看看。

图11.19

谈谈我们对作为游戏平台的Linux的想法。

在Unity 4中，我记得是2012年，我们发布过Unity播放器支持，以让它在Linux上运行。让我们看看过去几年我们来时的地方，我们在Steam上有大约2750个Linux游戏，其中很大百分比是Unity游戏，这也是我们非常自豪的地方。当然也有大的，呃，来自后方的推力（口误），如此增长的大的动力也是来自于Steam和Valve在Linux后的推动。我们今天听到过的关于游戏的未来和开放平台的接纳精神，Linux也非常适合这个目标。

另一件我们非常高兴的事情是，SDL2有更好的授权。我说更好是因为，Unity可以在桌面使用LGPL（GNU Lesser General Public License，GNU 宽通用公共许可证）库，不过我们更倾向于非常非常非常不喜欢静态地移动东西。同样，我们过去没有使用过SDL，因为我们只需要支持X11的时候，我们试图不要引入第三方库，虽然并没有什么非常好的理由要这么做。（观众笑）但是现在Wayland和Mir即将一起出现，搞清楚如何良好地支持它也是我们的关注点，SDL使用的是GPL授权而不是SDL1的LGPL授权，这对我们来说也很方便。这很棒，非常方便，SDL社区对Unity接纳SDL也非常兴奋和愿意接受，拥有这个支持非常的好。

然后是Wayland和Mir一起的到来。我不记得Wayland有多久了，但至少它是被公布了的。呃，（沉默了一会儿）这是也是有趣的。我不是完全肯定我对它的感觉是怎么样的。当然我同意Wayland呃，拥有Wayland和Mir的争论。X11是非常旧的了，我们现在有了混合的视窗管理器，而在它被设计的时候还没有，它也有很多东西是我们不需要、不使用的，是时候是让它被别的什么代替了。当然接纳某个东西取代X11的进展会非常非常缓慢，有成千上万的应用比如Unity只支持X11，但我觉得这是一个有趣的进化，我们会见证它的走向。在游戏视角立场来说，我们会试着为无法论发生什么都做好准备。这些都只是进程。

图11.20

如果我们来看问题区域——这是个比较重要的事情——GPU驱动。这是一种标准的东西。GPU驱动有bug，我之前提到过而我要重复说一次，在模棱两可的规范上与OpenGL有竞争性的实现是非常成问题的。在Linux上也是这样的，让我们看到驱动实际发生了什么的图形debug工具其实非常非常的弱。图形程序会尝试做的第一件事情是——如果有问题——它会看这个问题在OpenGL和Windows下能否重现，在那些环境下的debug工具好很多；如果不能，那么非常地不幸，它的修复难度会高很多。这是这些debug工具开发者需要做的事情——也可能他们不会做。我希望他们会去做，但是显然这是为了开发者需要改进的地方。我有很多希望和信念，相信Vulkan会为Linux作为一个游戏平台做很多好事，取代或是摆脱我们在过去几年中在OpenGL中遇到的很多问题。

图11.21

接下来我讲一讲Linux编辑器。这里有多少人知道我们发布了Linux编辑器？（看不到举手情况）没有想象中的多。我们发布了Linux编辑器（尴尬笑），大概是在一年前发布的。

图11.22

我们将编辑器作为实验版本进行发布。Linux编辑器的较早版本是作为主流数据库的分支发布的。当时的背景是，我们是将它……呃，我们先将Unity runtime接到了Linux上，花费了一些精力让runtime能够运行。在编辑器中我们用到了更多的技术，支持编辑器到第三方桌面平台要难得多、工作量也大得多。

我们漫不经心地在这方面工作，在很长一段时间内都把它当作一个有趣的小项目。实际上我们让它运行了起来，但是当我们做到的时候，它更像是我们主流数据库的分支部分，而我们也不能用它来做什么，所以在我们准备发布build来看人们的想法、他们会用来做什么的时候，我们不得不持续地将上游主线拉取到这个支线中，修复损坏的部分，然后制作并发布。所以在作为分支发布的早期版本，这个编辑器是落后于主流版本的。

在5.5以及更新的版本中，Linux编辑器的代码已经变成了碎片一样，集成到了主数据库里，降低了延迟。我们没有发布，呃，Linux编辑器仍然还是实验性版本，它还没有在主流发布流程中和其它编辑器一起作为其中一部分被生成、测试和验证，所以我们没有为每一次发布版都制作和发布Linux编辑器。比如说对汇总版本，我们不会发布它们的补丁，再比如对beta版本，并不是所有beta版本（都有编辑器），但是只要有什么大的东西（更新）或者说有了几个类似的之后（，就会加入编辑器）。不过它是可用的，如果你去论坛，如果你有兴趣尝试它的话，会有一部分是专门给实验性或预先功能之类的东西。而且也有一个专门关于Linux编辑器的论坛，你可以看到所有我们发布了的版本，你可以下载并尝试。你不需要有专门的授权什么的，只要试试看就行了。

它还没有在非实验性状态下发布的计划，这并不是因为我们没有计划，而是我们需要看一下接纳度如何、人们用它在做什么、有多少人在使用，然后再做出明智的决定，它是不是未来支持工作的方向、它是不是值得去做。所以我们现在还是以实验性功能发布，未来我们将看到会发生什么。

无论如何，现在它已经稳定得多了，尤其是在近几个版本，我得到了很多关于较晚版本的编辑器相比之前的版本变得非常稳定的反馈，人们非常喜欢用它。即使你对以Linux作为主要的桌面平台进行开发（也就是说用Linux开发游戏）不感兴趣，但如果你想减少迭代次数，比如你想为Linux或SteamOS生成和测试Unity游戏、并且要不断重做播放器的话，那么它还是很有用的。在这种情景下，Linux编辑器还是很有价值的。

所以请务必尝试一下，如果你有反馈，请告诉我们。

图11.23

以上就是所有的内容了，现在开始提问吧。如果你之后想跟我联系，你可以在Twitter上fo我，或者你也可以去我的网站，我在上面写了很多东西，游戏、Linux，各种这样的内容，所以如果你觉得我写的东西有意思的话也可以来看看，也是另一条保持联系的方式。差不多就是这些了，有人有问题吗？

（Q&A部分）

（排队提问）

提问者1：

我之前不知道有Headless模式。你们有什么样的用法（usage）？有多少人在使用和开发它吗？有没有什么利用它的产品的例子让我们进行了解。（这人没好好听）

Na'Tosha：

我不知道使用率（usage，应该是理解错了？她或者我）是多少，我得看看我们的统计数据。我们获得过关于它的bug报告，所以我知道有人在用它，不过是的，我之前也说过，它通常是被用于那些需要headless服务器让客户端来进行连接的游戏。但是我并不清楚使用率，抱歉。

提问者1：

有什么例子吗？他们是把帧写出来然后串流这些帧吗？还是说更多地作为堆栈式机器（stake machine）使用？

Na'Tosha：

em，我不是很确定，我们有例子吗？好吧，我觉得应该是更多用于堆栈式机器，就像你说的那样，但是我也没有跟在使用它的网页开发者有过亲密合作。不过从我们已知的来看，我们认为更多是第二种用法。

提问者1：

好的。谢谢。

提问者2：

你好，我制作了一个刚刚开发的游戏。

Na'Tosha：

哦！

提问者2：

是headless版本的。我想问你一个我们发现的东西——不是我个人的，但是我知道的——同时使用Headless和Development的问题。你们有意识到这个吗？有计划强调这个、让debug更难吗？

Na'Tosha：

嗯，问题就在我们没有发布过一个development播放器的headless版本。我的意思是，headless版本是非常非常严格的，它不接受键盘输入之类的东西。总体来说，最好的方法呃，人们遇到的主要问题是他们想要headless播放器的profile（提问者2点头），但是如果没有development播放器的话他们做不到。我们考虑过发布一个headless播放器的development版本，但是我们还没有决定。不过我们有很大希望会做这个，尤其是现在我们的安装器机制允许我们加入我们需要的目标，而不需要加重大家负荷来下载我们要用的目标，所以有很大机会我们会做这个。

同时，如果你遇到了类似的问题，你需要做比如profile这样的东西，那么你能做的最好的方法就是开发一个普通的播放器，你可以用批处理模式-nographics运行它，这个非常类似（headless），唯一的区别就是它仍然需要机器安装了X11——即便它没有用到这个。（提问者2点头：对，对。）你仍不能从一个真实的产品服务器上获得profile，但是这是你能做的最接近的东西。

不过我们已经意识到这个问题了。

提问者2：

好的，谢谢。

提问者3：

你好。我先要说一下，我是一个SDL开发者，所以先谢谢你。

Na'Tosha：

（笑）谢谢。

提问者3：

这么多年来我一直在想，除了所有的视窗内容——我知道它展示了所有东西，在未来几年内会变成一个大问题——，你提到了你们已经为游戏手柄配置的环境变量提供支持；对于用SDL集成来配对，而不是用配置来说，你是直接使用SDL_joystick，还是说你是在用游戏手柄API？如果是后者，它如何融入——我知道启动器有手柄配置页面——所以我想知道SDL输入是如何被集成的，是否有我们能做的事情来让它不那么痛苦？（你问的是个几把啊）

Na'Tosha：

你说的『游戏手柄配对』是什么意思？你是说Steam游戏手柄配对吗？

提问者4：

有SDL_joystick和SDL_gamecontroller（这样的指令），来完成游戏手柄开放……

Na'Tosha：

哦我懂了，我们只用gamecontroller这个，我们不用SDL_joystick。

提问者4：

好的，所以在启动器对话框里仍然还是X代替按键0这样，还是说……

Na'Tosha：

我的意思是，如果游戏easyinput输入管理器以及用了一个启动器对话框，那么用户可以按照他们的想法设置按键绑定，然后我们读取。我们只是使用SDL，我们为event拉取SDL。我们得到的是按键event和摇杆event这样的东西，然后我们把这些传递给输入管理器，基于用户的按键布局由它来决定各个按键做什么、以及我们得到的是哪个按键。

提问者4：

好的，谢谢。

Na'Tosha：

不用谢。

你好。

提问者5：

你好。不知道你能不能简单讲讲Linux runtime和Windows runtime性能上的区别？

Na'Tosha：

我们知道有一些区别。显然，性能profile会是不一样的。呃（想了很久）。人们经常抽象地来说一件事情。如果有个人的游戏有性能问题、但是不提供那个游戏的话——我们需要profile、看看问题是什么，可能有我们需要修复的问题，也可能没有，我们也不知道——，那么我们其实没什么能做的。如果有问题，如果你的游戏或者你知道有人的游戏发生了问题，请用文件反馈问题，让我们能了解。我们当然很关心，但是正如我前面说的，这是你们抽象地知道的一件事情，而没有什么出错的详细的参考物之类的。

提问者5：

谢谢（一脸蒙蔽）

Na'Tosha：

你好。

提问者6：

你好。我已经关注Unity为编辑器提供的dll之类的东西很久了，你们在用定制的UI工具包来渲染编辑器内的所有部分吗？还是说你们靠一个多平台的工具包，比如Q？

Na'Tosha：

Unity编辑器使用的是一个GGK来管理视窗和获取输入，唯一的例外就是，未来会在游戏模式下用SDL获取手柄输入。针对渲染Unity UI，这个是由我们自己的UI系统完成的，在Mac和Windows上渲染编辑器的也是一样UI系统。GGK仅用来管理基本的视窗管理。

提问者6：

好的。很多人都在想，你们是否考虑过使用那些工具包的原生组件，来减少需要包含的渲染编辑器这部分的量？

Na'Tosha：

我们一直坚信，在多个平台上生成发布的编辑器拥有同一个实现方式，从各种方面对我而言都是更好的。过去我们也考虑过可能我们需要用，呃，想要搞清楚我们应该用多少原生组件在我们尚未使用的地方。如果我们只在Linux上发布，那么肯定地，使用尽量多的原生内容会很有意义，但是我们希望保持我们的数据库尽量保留跨平台数据库应有的功能性。（意思就是，考虑过了，不行）

提问者6：

好吧。

Na'Tosha：

谢谢。 

你好。

提问者7：

你好。我们现在正在Linux上是使用Unity编辑器，作为我们持续集成（continuous integration）流程的一部分，而这个过程有一些棘手。所以我们想问，你有没有什么计划来推出一个编辑器阉割版，专门用于持续集成和生成过程之类的？

Na'Tosha：

我们没有什么详细的计划。对于这个，我们自己讨论过，可能会用于我们内部的使用。我觉得这个想法很有趣。我们讨论过推出只能在批处理模式下运行的编辑器版本，而它也是针对这种特殊情境设计的。我不知道这个能多大程度上解决掉你的特有的问题。不可能……举个例子，将编辑器在一个完全headless的服务器上像播放器一样运行，这是不可能实现的。所以如果我们做了那个之后，它能不能帮到你，我们需要对其中实际的问题进行讨论。你建议的这个，我们已经讨论过了，它可能会是我们自己用的东西，但是我们没有详细计划来制作这个。

提问者7：

谢谢。

Na'Tosha：

还有问题吗？（排队提问的人走完了）好的，正如我前面说的，如果你还有什么问题，之后尽管找我。还有就是，祝你们好好休息。

12. Steam上的视频内容

By Sean Jenkin (Valve)

（观众掌声）

欢迎来到Steam上的视频内容。我希望你们在SDD度过了丰富多彩的第一天。

我的名字是Sean Jenkin，我在Valve工作，我每天都在Steam业务团队工作。你们可能在社区里看到过我回答社区上探讨的问题，希望你们在这次演讲结束的时候能更了解我。

我要进行这次演讲的原因是，我同时也在做在Steam上加入视频的开发工作。首先，我们先来看看我们今天会讲些什么。所有东西今天都运转良好，很好。

图12.1

为什么Steam上要有视频？我想要尝试回答这个问题。回答了这个问题后，我想要给你们看看它的特性和你在Steam平台有的条件。我们会谈谈目前为止的接纳度，对于你早上在幻灯片中看到的一些数据进行了一点过滤。我们会讲即将到来的特性，同样地，这部分会跟你们早上在幻灯片中看到的有关联。以及最后会有一个Q&A的时间，如果没有时间的话，我会在这部分结束后找你们。如果你们有视频方面的问题，那很好，我们会回答；如果你没有的话，这次演讲之后马上会有一个happy hour，来找我，我很乐意讨论别的东西。

图12.2

（观众笑声）如果你深入了解程序，发现事实上我们要谈论视频，然后这个问题出现在了你的脑海中，那么其实你不是一个人。每次我们宣布一个内容的合作关系的时候，每次我们给一个电影打折的时候，如果你看Steam视频内容的讨论区，甚至是在Reddit上，你很有可能会找到这句话。

在过去的几年里，Steam一直在**，我们会继续做一个主流游戏PC平台，而且显然我们也在进军VR，但是我们也**道理比如软件、原声带、数字画集、以及，是的，视频。事实上，到今天大概有1,700个视频在Steam上可以购买和观看。如果你不知道这些内容的话，看看这个：

（视频略，是各种视频的节选：

Mad Max: Fury Road, 

Hardcore Henry, 

John Wick, 

The Hunger Games: Mockingjay – Part 2, 

Kung Fury, 

Free to Play, 

Over the Dream, 

Man vs Snake: The Long and Twisted Tale of Nibbler, 

Double Fine Adventure, 

3DS MAX Substance Painter 2 Blade Tutorial, 

Forest Ground Tiling Texture Tutorial, 

Hard Surface in Zbrush: Recovery Truck, 

Sculpting and Rendering a Cthulhhu Bust）

关于现在的Steam已有的内容，我希望这给你们了一点提示。我们来谈谈为什么我们会花时间投资在视频上。

图12.3

在上一次的SDD，两年半，差不多三年之前，在2014年，Valve站在台上说，『我们从顾客那里听到的是，他们不仅仅想在他们的卧室、书房、办公室玩游戏，同时也想在客厅玩游戏』。所以我们更前进了一步，我们花费了时间和资源来做Steam Machine、Steam Link和Steam 手柄。既然我们会到电视机上，那么往回退一步、看看视频内容在这么一个曾经只有游戏的平台上有没有用就显得很有意义了。

大概在同一个时候，我们开始发现Steam上开始出现了一些视频应用，比如Indie Game: The Moive、 Super Game Jam甚至是Valve的Free to Play。这些应用基本上都是Flash基础的界面和MPEG4文件放在磁盘上，这就意味这，每个想要在Steam上发布的视频需要花费一些本来应该花在视频上的资金，来做一个界面或者是应用这样的东西。所以我们就想，可能我们可以帮助这个变得更好。而这些应用可能也并不是能全平台运行的，他们可能在Windows上可以运行，幸运的话在Mac、Linux上，但是他们基本上都是在Flash上生成的。回到Steam客厅计划的初衷，当我们考虑Steam Machine、SteamOS和Steam Link的时候，实际上是不可能在我们的平台上支持这一类的应用的。

我们也开始发现出现了很多市场营销内容，这些可能是游戏的trailer，甚至可能是更贵的章节内容，比如Mortal Kombat: Legacy和PAYDAY: The Web Series，这些是一个小时到两个小时时长的对游戏的补充内容，在Steam上进行产出和销售。所以我们就想，『我们作为一个世界范围的商店处在一个良好的位置，我们知道如何每天传输PB级别的数据，我们也听说了一些伙伴们想要发布视频内容，顾客们看起来也在看视频内容，那么我们能接受视频这个概念，并将Steam所有的伟大的东西都应用到这个上呢？』这就是我们今天所提到的，Steam视频。

图12.4

Steam视频是一个Steam上原生集成的内容。就和游戏、软件和DLC一样，视频是Steam的原生部分，所有Steamworks后台的东西、Steamworks客户端、库、商店，所有这些东西都了解视频。我们可以在Windows、Mac、Linux、Steam Machin上的SteamOS上将正在播放的视频进行回放，Steam Linke设备也可以安全地回放视频内容。

Steam手柄被原生集成入视频播放器中，下一次你在大屏幕模式下看一个视频的时候，拿出你从礼品袋里获得的Steam手柄，在右边的触摸板上搓动（scrub）——这是给你们的专业小tip——，你就可以向前向后地移动视频进度条，就像编辑一样。我们已经能在Steam手柄上采用这样的动作并且应用到视频上。你还可以使用控制按钮、肩部按钮、扳机按钮等等按钮在播放器里做别的事情。

我们也仍支持gamepad手柄、键盘和鼠标，在今天也公告了Steam手柄的API扩展，视频播放器在这些情况下可以有完全一样的功能。

我们是在已有的Steam直播的基础上做的Steam视频功能。Steam直播使用了一种我们称之为『Instant Watch Adaptive Streaming Playback』（实时观看自适应流播放）的技术，这就意味着我们可以自动调整人们观看的内容，来提供连续播放体验。它可能基于带宽、CPU使用率，也有可能你在用一个1280×720分辨率的显示器，我们就可以对播放进行自动调整。用户们可以自己选择在更高的质量下观看，但是我们会自行尝试帮助解决（画质选择）。

由于我们是自适应流，所以我们可以做一些例如，在播放时选择音轨或者字幕这样的事情，这些对用户很有意义。举个例子，一部电影有英语和西班牙语字幕，哦不对，是配音，而这个人从同样使用西班牙语的Steam客户端启动了这个视频，那么视频播放器会做出自动开启西班牙语音轨的选择。如果没有西班牙音轨，我们也会打开西班牙语字幕——如果有的话。同样地，这些东西用户们可以自行定制并在播放中进行更改，但是这也是我们会自行做出明智决定的。

所有这些归纳起来都是一个理念，就是为了只提供播放时用户们需要的内容。

图12.5

这部分技术我想稍微深入一点谈谈，给你们当中关注它的人。我们看到，在左边的是而视频的可视部分，右边的是视频的声音部分，我想把这两个区分开。当我们获得用于采集到Steam上的视频的时候，我们选取的是最高分辨率，然后在不同的码率下生成了多个版本用于播放。

在这个例子中，我在家开始看一部电影，在1080p分辨率下。然后我的妻子开始下载Steam上的东西来玩，就导致了我可用带宽的下降，所以视频播放器就切换到了720p。最终出现了网络拥堵，在拥堵结束前我只能掉到360p，然后我才能回到1080p。这就是我的视频体验，视觉上的体验，没有遗漏、跳跃或是黑屏，它自动地根据可用带宽进行了转变。

在右边，你可以看到四个分开的音轨。我要说的就是视频平台的另一个特性，那就是我们在音频和视频中都支持不同的播放轨道。现在我们来看看音频的。每种音轨都只有一个，音轨的比特率大概只有最低质量视频的一半，所以我们为每个音轨只提供一种比特率。同样地，我一开始使用英语音轨，然后我切换到了导演评论，而在导演评论里的有个东西让我突发奇想用西班牙音轨去听剩下的部分。

最下方就是播放的结果，这些就是实际上传输给用户的数据。再说一次，所有都是同步的，没有遗漏，没有黑屏，同样地受玩家控制、也受播放器控制。

我分享所有的这部分内容，不仅仅是因为我们未来的某些技术——我只后会谈到——是基于这个，而且也因为，如果你准备将视频内容带到Steam，用这个很容易理解它的工作原理，来充分利用平台。

在我讨论构成Steam视频平台的其他特性前，我想先谈谈一些已有的内容模式和商业模式，这样你们就可以考虑如何呈现你的内容了。

图12.6

首先是内容模式。这些很容易理解，所以我不会花太多时间在这上面。

第一个就是独立的视频，其中的代表有电影、短剧——Steam现在大概有30部短剧在售。独立的视频也可能有额外内容。让我们来看看这张图，这是电影Divergent，是一个独立的电影，它也有一些额外内容在商店页面的下面显示，这样顾客们就能准确地知道他们在购买这个独立的视频时会获得什么了。

图12.7

内容的另一种模式是系列视频。在右边的这张图里，你可以看这个的第一种类型，季和集。Naruto Shippuden Uncut（火影忍者疾风传完整版）有28季共361集。作为消费者，我可以点击各个标签来看到每一季里的所有章节，我也会有选项——之后我们会就这个讲更多——来买单独的几集，或是购买一季里所有集的捆绑包。

图12.8

我们也将这个应用在教程，你们在我最开始的剪辑片段里面也已经看到过了。在这个情景下，每个标签页代表教程的一节，而教程的每一章是作为单独的元素呈现的。同样地，作为最终用户，我可以看到教程每一章的名字、播放时间、以及它的描述，这样我就能完全明白点下『加入购物车』时我要买的是什么。

之后我会给你们展示更多的教程，不过还有一件事情要考虑到的是，额外的文件。对于教程来说，经常会需要额外内容来完成教程或是帮助你完成教程。我们可以传输这些文件，笔刷、模型、其他相关材料。或者独立的视频有一个原声带，我们也可以将它传送给玩家。这些内容会出现在库里的不同地方，不过用户们已经习惯了，也知道如何找到这些内容。

图12.9

我们来谈谈商业模式。

首先是购买。购买为Steam用户所熟知，在电影行业、电视行业，它通常被称为『电子销售』（Electronic Sell-Through），或者是『EST』，它的意思就是内容在用户库里是永久可用的。可能我不需要讲太多。

另一个模式是我们专门为视频内容投入了一些时间做的，租赁，或者叫『视频点播』（Video on Demand）、『VOD』。我们有默认的参数设置，在30天内开始并在48小时内完成观看租赁年日。我说默认，是因为每一个电影或是系列都生成了购买和租赁的package，在租赁package上，你选择可以跟我们一起定制它。如果你认为『我的内容需要7天内初次播放后7天内观看』或是『3个月内初次播放后3个月内观看』，我们很乐意跟你交流，做出最合适的方案。

图中的这个是一部动画，叫做The Last – Naruto the Movie（火影忍者剧场版:终章），我们能看到第一个package就是租赁，下面有租赁信息——『 30 天内初次播放后 48 小时内观看』的窗口，正下方则是购买选项。选项被清晰地展现给了消费者们，而作为内容提供商和经销商，你可以选择提供『租赁』或『购买』，或者『租赁』和『购买』。你可以根据拥有的可用内容和授权来做出选择。

图12.10

我想谈谈一些其他的商业模式，第一个是，『免费』。我想谈它的原因是，我们不可能将所有世界上免费的东西放到Steam上，我们会加一些限制，我现在就想解释这些限制。首先就是，如果内容是跟游戏相关的，比如Steam上的一个游戏、整体的游戏产业、或是游戏文化。我们的设想是，在Steam上的人很可能一开始是为了游戏来的，所以跟这个有关的内容可能是他们感兴趣、喜欢在平台上看到的。

这里有个例子，这个就是CS:GO Player Profiles（CS:GO玩家简介），CS:GO就是Counter Strike: Global Offensive（反恐精英：全球攻势），Valve制作的一款游戏。每年我们都会举办比赛，我们称之为『特锦赛』（Majors），在这一页上每一次特锦赛都代表了一季。每当我们要举办为职业CS:GO玩家提供的特锦赛时，我们会花时间做视频简介来介绍他们是谁、效力于哪个队伍、他们的家庭生活等等。我们会在特锦赛上展示这些视频，然后它们马上就会加入到CS:GO Player Profiles中。你可以分开地看每一集，你也可以使用『添加至账户』按钮，这意味着每当我们之后加入了新的季和集，它们都会自动加入到用户的账户中。这是实现你的内容长尾价值的很好的一个方法。这也意味着CS:GO，从玩家简介到实际游戏，都是点击一下鼠标的事情。这也是一开始，我们考虑的Steam视频内容时想到的，让这样的市场营销或者支持内容尽可能地接近实际的购买点，这个价值非常的高。

图12.11

另一个我们支持免费内容的方案，也是一个转为收入的机会。Kikoriki是俄罗斯的一档儿童TV秀，总共有173集，而前两集是免费的。你可以将它跟游戏中的demo联系起来。我们完全理解通过免费提供2集，人们为剩下171集花费10美元的几率会很高，所以我们也很乐意支持这种情景。

图12.12

还不仅仅是如此。这个是Steam上的Complete Figure Drawing Course HD，有225章、77小时的教程内容，教你如何画人物形象。它的量很大，而价格是50美元，也不是一个便宜的教程。前19章免费赠送，大概有2个半将近3个小时的内容。我们每天会去看它的销量，非常的好。更有趣的是，超过50%看过一集或更多免费部分的人将它加入了愿望单，这就意味着未来几周促销到来的时候，无论是万圣节、感恩节或是圣诞节特卖，这些人都会收到它在促销的email，对我们研究转换数据来说，这是一次很好的机会。我们期待对此感兴趣的顾客们能转变（为消费者），为制作了这个教程课的人选择购买选项，这是极好的。

图12.13

然后我想讲讲捆绑包。捆绑包是我们在过去大概一年半的时间里在Steam上投入了很多精力的东西，如果你不知道捆绑包，我会尝试解释一下它。捆绑包允许你将任何一系列的内容打包，无论是一个游戏、一部电影、原声带、你的DLC和你的游戏（说重复了），我会给你们一些和电影相关的例子。不过需要重复的是，它对Steam上任何形式的内容都是一样的。

这个是Mad Max的游戏。Mad Max游戏在2015年9月1日发布，而在同一天，Mad Max: Fury Road——去年很多地方的年度电影——，也开始了家庭数字视频版的销售。我们和Warner Brothers（华纳**）一起将Mad Max游戏和Mad Max电影——Mad Max: Fury Road——放到了Steam上。我们也和他们一起创建了一个捆绑包。意思就是，如果我买了游戏，那么我可以以9折购买电影；或者如果我先购买了电影，再购买的游戏，那么我也是以9折获得了游戏；或者我可以在一开始就以9折的价格将两者一起买。有一个有趣的数据就是，几乎50%电影的销量，实际上是来自于捆绑包的。这其中可能有很多原因，可能是人们真的很喜欢这个IP，他们已经玩过了游戏、想要电影，或者是他们喜欢电影而现在他们想试试游戏。不管怎么样，因为这个捆绑包而产生的购买量是非常大的，这一点是值得考虑的。

第一行的物品下面就是『购买Mad Max: Game + Fury Road捆绑包』。再下面是『购买 Mad Max: Game + Mad Max Anthology         捆绑包』——这是一个franchise，里面你可以在Steam上买到的所有关于Mad Max的东西，里面甚至有最初版本的Mad Max电影，除了通过这个捆绑包购买以外别无它法。这是一个全系列的捆绑包，如果我拥有游戏，我可以通过升级获得额外的四个电影，而这次，我可以获得一个15%的降价。

对你的内容来说，无论是游戏、电影、DLC、原声带，当你将你的内容带上Steam的时候，这里面有很多的选项供你们思考。

图12.14

几个捆绑包的选项。这个选项我觉得对于视频内容来说是独一无二的。这个系列叫做Crunch Time。目前有4集是可用的，而2集还没有发布。在如何购买这个上，我有很多的选项：我可以立刻就购买整季的捆绑包，我会立刻获得4集，当剩下的2集解锁时，它们会出现在我的库里。我们在Steam商店上也是这么做的，可能从远处看的不是很清楚，5、6两集没有一个真实的名字、没有运行时间、没有描述。我们对大家隐藏了这部分内容，这样我们就不会剧透这个故事。同时，作为消费者，我能知道我会获得6集，我要花6.90美元来买这6集。我可能会尝试，先购买了第1集，而这个第1集的购买，会让整季捆绑包里扣除一部分的价格，所以即便我先购买了第1集进行尝试，我仍然将它的价值从捆绑包里扣除了。这也是我们为所有章节式内容提供的支持。

图12.15

另一个是围绕着硬件，是我们近期开始的东西。这就是Steam Link——我们的硬件设备——，加上电影John Wick。你可以一起购买Steam Link和John Wick，而价格和单独的Steam Link差不多（单独购买为49.99美元，捆绑包图中为47.78，实际我写的时候为46.18 ），所以你可以认为是免费获得了游戏，或者就是你购买了电影、以半价获得了Steam Link。对消费者来收很值，而且老实说，我们看到的每个区域这两个产品的销量，都基本上是这个捆绑包，而不是只买Steam Link。如果你认为你有可以跟我们的硬件一起售卖的内容的话，我们很乐意看到它。

图12.16

谈到捆绑包，我想讲的最后一样东西是，VR。同样是John Wick主题，这次是John Wick Chronicles。这个捆绑包里有很多有趣的东西。首先它是一个VR游戏，它在2017年2月发售，所以是在预购阶段。如果你选择购买数字豪华版，你可以获得VR体验、John Wick电影、Payday2 游戏以及可能还有的数字豪华版里的东西。作为一个顾客，由于折扣，单个捆绑包的购买获得所有这些内容对我来说超值，捆绑包里的电影也更便宜了。所以再说一次，考虑如何在你的捆绑包中加入你拥有的所有内容，VR、电影、软件、原声带，等等。

在我继续之前，我想迅速地谈谈DRM。我知道有时候这是一个敏感的话题，我们接受的所有视频都是用Google Widevine和常规加密，作为内容提供商和经销商，你可以将它（DRM）关闭，用户们没有选择。这不会改变我们传输内容的方式，仍然是自适应流播放，而且我们在DRM开启的用户也那没看到什么负面效果。DRM开启的意思就是，从头到尾出现在屏幕上的所有东西都是加密的。

图12.17

谈到这，我想再讲一些Steam视频特性，之后我会讲到接纳度。

Steam，显然地，是一个全球性平台，早上你们看到过了数据，在亚洲有大概500%的增长，世界其他地区约200%的增长（演讲2）。不仅仅Steam视频播放器，你们的内容也可以尽可能的实现本地化了。我们的视频播放器已经对所有Steam支持的语言进行了完全本地化，你也同样可以为每种语言上传和加入字幕（caption和subtitle都指字幕，caption偏向旁白介绍，subtitle偏向对话）。我们也支持比如加拿大法语、墨西哥西班牙语，那些区域里的重要变种我们也支持。

所有的CC（closed caption）字幕和对话（subtitle）字幕都有用户完全定制，为什么这个很重要呢？每个需要字幕的人，可能有不同的观看方式，他们可能想要字体更大一点，他们可能需要一个不同的字体，他们可能要样式，他们可能要阴影，他们可能不想要字幕背景窗口色。所以为我们的用户提供所有这些支持是非常重要的。

我们也有特性支持强制字幕（forced subtitle，类似对画面上的字进行注释那种，或者是影片中说不同语言的人的翻译），这样你就不需要将字幕烧录至文件中，并且发送给我们好多个版本，而是给我们发送一个能给所有用户在所有情况下都自动开启的字幕。你也可以做一些例如音轨上的强制字幕，这是什么意思？这种情况在动画授权世界里经常发生，如果你在美国，而你想要一个动画视频的日语音轨，按照授权要求，你需要打开英语字幕。我不知道我是不是理解对了，但是我们支持这个。如果你在授权时需要这个，那么我们也会给你提供支持。

一个数据，10%——不是准确的10%，而是10%左右——，每天被观看的Steam视频中至少有10%的是开着字幕（subtitle和caption）的。这些受可用内容影响的人，可不是一个小数目。就像本地化游戏一样，如果你认为你的内容对某个地区有吸引力，确保你做好了字幕，这绝对会影响你的顾客的。

图12.18

我之前提到过，Steam视频是被原生集成到Steam中的。这就意味着，对于Steam用户来说，他们可以用到很多标准的Steam特性。因为我们是Steam上的第一类内容公民（first-class content citizen，first-class citizen指支持其他实体所有操作的实体），我们可以在视频中进行了支持。

首先是播放时间，或者说观看时间。每次你看一集或者看一部电影的时候，我们会追踪你观看的时间，我们就可以将这些分享到你的个人资料上、并做一堆其它的事情。屏幕上有一些图片，左上角的这个是我个人资料的一部分。这里有两个东西，Football Manager Documentary是一部独立的电影，我们对时间进行了专门的追踪；Kikoriki，之前我也提到过，是一个章节式系列，我陪我的儿子在看，我们看了这个系列1.1个小时，每一集都自己有被追踪的观看时间，但是我们把那些数据加了起来，这样我们就可以在系列层面上显示数据了。

为什么我们要在系列层面展示呢？因为商店页面是系列层面的，讨论区是系列层面的，用户的评测、即便是写给不同集的那些也是在系列层面的。所以对我们来说，保持一致性是很重要的，这也意味着电影和系列内容都有你能预料到的标准社区特性。

我们也支持集换式卡牌。Steam集换式卡牌，简短地介绍一下，它们就像是虚拟的棒球卡（baseball card，大概1900年之前就开始出现的棒球球员介绍卡牌。壕之玩物。），你可以在Steam上观看视频、玩游戏或者做其它任何事情的时候获得它们。不论你是在看一个视频，还是在看一系列视频，集换式卡牌功能都能运行。你可以获取这些集换式卡牌、收集这个系列、然后将它们变成一个徽章，它会提高你的资料页等级、给你表情和背景，也可以让你展示自己是你看的或者玩的内容的粉丝。

同样地，我可能看Kikoriki这个系列比如说17个小时，在这个过程中，比如每2至3小时，集换式卡牌就会给我掉落一张，然后我就可以用它们做任何集换式卡牌上能发生的事情（比如交易、合成），参与到我们的经济中来。

图12.19

我还想要提到的一个特性是，SteamVR桌面影院。你在Steam上看的每一个视频，都可以在SteamVR桌面影院上运行。只需要戴上头显，开始播放电影，然后你就会到达这个影院空间。你可以改变屏幕的大小，最高可以到5米或者说是225英寸，你可以让屏幕弯曲，也可以让它平坦，你可以将自己放在房间里的任何一个地方。戴上头显，找一张舒服的椅子，享受Steam在头显的视频空间里提供的所有东西吧。

图12.20

好了，接下来我们来稍微谈一谈接纳度。（喝口水）不好意思。

图12.21

跟DJ在今天早上做的差不多，我想要讲一讲内容、用户、收入的数字。在我看来这个图形看起来挺厉害，在我们开始发售视频内容之初，基本上就是大家给我发送视频文件，然后我会把它们放到一个安全服务器上、手动运行我们的采集脚本，我需要上传文件、设置后台，我还要帮忙设置商店页面和发售，就像五六年前的Steam一样，DJ展示了每个人都『着火』的样子，这个差不多就是视频这块一年半之前的样子。

认识到这个很蠢之后，我们开始自动化处理和脚本。现在，我们有了自助采集、云端处理系统，每天可以设置数以百计的电影。（转身点屏幕）这就是我们做的几件事情。在开始的时候非常慢，大概在2015年7月我们有了第一个自动化脚本，之后我们不断地以越来越好的效率和速率发布内容。

从去年年中一直到今年，我们一直在跟战略合作伙伴进行合作，例如Lionsgate（北美电影电视公司）、VIZ Media（北美动画发行商）、Cinedigm（数字影院）这些公司，它们拥有我们认为我们的Steam用户会感兴趣的内容。从今年3月份开始，你可以看到在内容的数量上有些颠簸（增长不稳定）。最后在今您8月份，我们上架了TV连续剧和章节式内容、更多的教程，这些内容让这条线直冲而上。我们知道，基于我们在处理的部分以及（和厂商的）对话，这条线会继续一飞冲天的。

DJ在今天早上提到过Steam过去每年，对不起，每周发布5-10个游戏，大概花了10年的时间到达500个游戏。我们现在正快速地超越这个速度并继续前进，视频内容在上架到Steam平台方面是非常快的。

图12.22

用户。每个人都想要一个数字，所以这里有一个数字给你们。436万用户在Steam库中有视频，不包括视频应用（就是最早期的视频形式）这一块。这就是曾经看过视频的人数，至少到目前为止我们没有以任何方式强加过任何视频到任何人的库中，所以这部分436万用户都是有意识地做出了这个选择：『我要在Steam上看一个视频』，然后它就在他们的Steam库中了。

用户数量的增长来自于很多个方面，我想要选取其中两个。同样地，这也跟DJ今天早上讲的内容有关。我要讲的第一个就是免费游戏相关内容。我想给你们几个例子。第一个例子就是基于一个叫做Agent Origins的系列。Ubisoft（育碧）几个月前发布了一个叫做The Division（Tom Clancy’s The Division全境封锁）的游戏，然后他们发布了一个系列剧，总共4集，名字叫做Agent Origins，讲述了每个角色的背景故事。当Agent Origins在Steam上发布的时候，它成为了之后72小时内的最受欢迎的内容。我不是说最受欢迎的视频内容，我是说，在Steam上所有新发布的东西里最受欢迎的，并持续了72小时的，是Agent Origins。拥有The Division用户中的75%看过Agent Origins中的一集甚至更多，这让育碧的市场营销团队非常开心。考虑考虑你的顾客，他们会对游戏、IP以及其所处的世界产生兴趣，并会在其他方面扩展它。想想看，如果你今天在这里是一个游戏制作人，如果你有能力去做比如『幕后故事』或者『我们是怎么做出这个游戏的』这样相关的故事或是纪录片。你的顾客也想参与到游戏的创造中，而这显然就是你能做其中的一种。

另一个我们看到在支付方面更多的是，地区性内容。它的意思是什么呢？在我之前展示的剪辑里，有一小段影片Over the Dream的内容。Over the Dream是由一家俄罗斯电子竞技公司制作的，他们追随了一个Dota电子竞技玩家（查了一下是VP的一个队员）和一个Dota解说员到Dota 2015西雅图锦标赛（就是TI5）。这个影片整个都是用俄语的，现在有英语字幕，但是（语音）是俄语的，所以这是一个给Dota社区中关心俄罗斯的、关于俄罗斯人的、用俄罗斯语的影片。当它上架Steam的时候，销量数字吓了我们一跳，也吓了那个电子竞技公司一跳。每次他们上架围绕这个话题的东西时，销量就会爆炸。重点就来了（敲黑板），你可能有一小块的内容，而你觉得——比如因为它只有法语——可能只有这一小块社区里的人会喜欢它，而将它带到Steam也只是因为有顾客的存在。实际上他们对此非常感兴趣，也非常想要这些无法从其它途径获得的内容。

除了所有这些好消息外，我们也发现了，发现视频内容本身仍然是需要解决的问题——整体上在Steam发现内容都是需要解决的。DJ在今天早上讲到了一些我们会如何对首页进行改革。之后我会展示一些未来视频内容发现的发展方向。

图12.24

然后是，收入。你刚刚可能只看了这个饼状图，我来解释一下。这个饼状图代表的是从目前Steam上100个收入最高的视频里获得的收入的总量。你看到电影占了50%，这并不意味着前100里有50个是电影，而是意味着50%的收入是来自于电影——这并不让人惊讶，这一类型的视频内容比其他的类型多得多。

对我来说很有意思的是，9%收入来自于教程。如果你是一个游戏制作者，你也知道如何谈论你做的内容、建模、举例、设计和音效设计，给你自己录像，告诉我们，让我们把这个内容放到Steam上，这样别人就能学习制作优秀游戏的技巧了。Steam上有一块教程内容的市场。另一个部分就是，很多教程内展示的软件，也是在Steam上有售的。所以同样地，这将人们感兴趣的视频、教程和软件结合到了一切。

另一部分是动画。这些前100名视频收入中有20%是来自于动画内容。我不知道这是不是惊喜，我也不知道这个和亚洲（销量）的增长是否有关，可能这是有这个的原因，但是毫无疑问动画内容表现得很好。我们拥有纪录片的时间也不短了，所以纪录片的表现也没有那么惊人。

并不是我决定了这四个分类，而是我看了一下前100名的视频，发现每个都属于这四个当中的一个。如果你可以制作一部纪录片，内容是关于某个人制作教程，或者是关于如何制作动画内容，那么你可能可以对此会心一击（交叉分类难以确定分类），不过这不是我这一页或是我这次演讲的重点。不过这也算一件有意思的轶事。

我们知道主要的工作室、新的发售，主要是由于电影产业的运作方式，家庭数字版的发售首日带动了很多收入上的关注，所以我们不会远离这个，这是需要注意的一点。我前面也说过，类似本土化、有目标性的纪录片之类的东西，或者是有类似YouTube明星参与的东西，它们的表现比我预期中的要好，人们看起来（音频断了，可能是『很喜欢』）这些内容。

图12.25

那么你如何能够adopt入Steam呢？我应该将这一页幻灯片放在某个地方的（应该是说单独作为标题内容）。

如果你有一个现存的Steam Distribution Agreement（Steam分配协议，SDA），它已经涵盖了游戏、软件和视频等等你想在Steam上售卖的东西。如果你没有，那么我们有一个专门给视频的SDA给EST（电子销售）、VOD（视频点播）或者是产业中别的名词之类的东西。如果你有现有的SDA，但是你也想要专门给视频的，我们也可以进行安排。

之后就跟将游戏放到Steam上一样，你会创建Steam页面、所有的素材、所有的capsule美术描述。你会上传和配置视频，跟游戏的一样，可以在任何有新版本的时候进行替换。然后你再提交审核。一旦审核通过后，你就可以在准备好之后发布它了。

所有的独立的视频的章节内容、季度内容、额外内容都被加入到了平台中，我们在尝试把我从这种中间移走（意思是去除人工审核），这样你们就可以将你们的内容带给你们的消费者了。

图12.26

即将到来的特性。我还有多少时间，哦还好，还有很多。

我们是如何做到即将到来的特性的？我们是如何走到今天这样的？

在Valve，我们充分利用了三个东西——但愿每个人都做了。第一个，顾客们关心的是什么？他们用我们给他们的东西在做什么？第二，合作伙伴们想要做什么？我们是不是在支持他们的立场或者我们能不能为支持他们建立基础？第三，Valve还在做什么？

我们现在有的Steam视频平台，就是基于上述的三个原则。同样地，在SDD 2014上，我们谈到了扩展到客厅，我们看到合作伙伴试图发布（视频）内容，我们看到了用户们在看它们，所以这就是我们现在拥有的第一版平台。我们会做相同的事情来继续前进，比如让我们来看一看其中的VR。

图12.27

（上图右边黑框其实是视频，视频略）引子什么的我不知道，我只是编了这个名字，Steam 360 Video（Steam360视频）。我们跟西雅图的一个著名的公司Pixvana、资深最终提供商Akamai以及其它领先的内容提供商合作，（研究）一个叫做Field of View Adaptive Streaming Open Projection Format（自适应视野流媒体开放投影格式），简写是FOVAS。这是一个开放标准，我们试图用开放的形式开发VR技术。这是一个非常有趣的场景供我们参与，因为它是开放的，所以它跟我们的目标和优先级是一致的。

FOVAS支持的是高效率地播放8K至10K分辨率母带——也就是播放内容时你拥有的画面大小——但是只使用1080p的流或者说1080p流的带宽。它是基于我之前给你们看的那张图里同样的技术，Adaptive Streaming Format（自适应流格式）,也就是我们目前在Steam视频里使用的技术.

那么它是如何运行的呢？在现在的360视频世界，如果你尝试过它的话，你得到的是单帧1920×1080个像素点，但是当你戴上头显后，你得到的像素点却远远超过这个数字。那么这中间发生了什么？像素点变大了。它看起来像是被压缩过、看起来也并不太好，这影响到了人们对于真正优秀的VR360视频内容的理解。

那么FOVAS是如何修复或者帮助解决这个问题的呢？

图12.28

（实际画面会动，应该是下文提到的Pixvana SPIN Technology Preview实际画面）希望你们可以看清楚这个。我会读我的笔记，因为我不想搞错东西。

我们做的就是获取了原始的母带——我们就定10K分辨率吧——然后我们将它分成几个视角，在这个例子里是30个。通过将它（母带）打碎，我们可以在每个观众看的角度都保持高质量——我们是怎么做到这个的呢？

这些视角中的每一个，都是一个1080p流，但是我们选取了视角的中心部分，然后将它与预期中与10K体验匹配的像素、细节一起打包。这就意味着，它仍然是360度的视角，如果你快速转动你的头的话，你可能会得到相较标准1080p流而言更低质量的内容。但是——这也是让人激动的地方——在我们现在的播放器可以自适应地在分辨率和音轨之间切换的同时，我们可以切换你看实际在看的视区，也就是说，在几百微秒内——目前是这个数字，今后会更快——，你可以在眼睛的正前方保持最高的细节、最高密度数的像素点，这样360体验就变成了10K母带体验。

从这里面的举个例子。比如说我在看-30°，180°，我在正前方看到了一个非常清晰的画面，但围绕我的是更低质量的（画面）。然后我网上看，比如说180°，30°，向上两格，我们切换了你看的视区，而你可以继续观看高质量的视频。

图12.29

我们对这个技术非常兴奋，所以我们现在正致力于采集和发布处理FOVAS为基础的360视频。会有几种不同的方法，你可以通过一些正在开发的工具进行发布，比如一键发布到Steam。我们也在寻找一些方法，来让你们能直接采集到Steam，而我们会来做FOVAS这部分转换，让你能播放这个。这就意味着现存的视频，只要是1920×1080形式的，都可以这样播放。

我们会对Steam商店和库进行扩展，这样你就可以发现并播放这些360视频了。我们能播放360视频是因为，在与Pixvana的共同工作下，我们会发布一个集成的视频播放器，同时提供给桌面和VR头显。所以如果你没有VR头显，在桌面上你也可以使用鼠标或者键盘到处看看（360视频），你可以体验到全部的高质量360视频的效果。

如果你今天想看一个demo，Pixvana SPIN Technology Preview已经上架Steam了，上周发布的。如果你有Steam VR兼容头显的话，你可以戴上它，下载这个程序，然后你就会获得几分钟关于我们现在讨论的东西是什么的体验。

我们希望在2017年初发布它，我之后会谈到你们怎么参与进来。

图12.30

下一点，我前面讲到过的一点是我们想要实现无论Steam在哪里、都可以支持视频的播放，但结果是我们有Steam移动应用，我们意识到视频播放在移动应用上可能是很重要的。并不是我们没有想到过它，也不是我们不想解决它，而是针对我们已有的顾客基础，我们有其它的东西要先做。

不过，我们宣布我们会在在2017年致力于移动端播放，所以你以后可以打开Steam移动应用、浏览你的视频库。我们会首先在iOS和Android平台上开始，然后再看看之后我们是否会继续到其它设备上。

最开始它会在这些设备上播放流，但是我们也理解人们要坐飞机、他们要开会、他们想要看Steam上他们已购的视频，所以我们也会做出离线和下载播放，这样你就能随时随地享受内容了。过几年还有更多（功能）即将到来。

图12.31

我想谈的第三个即将到来的特性是，视频发现队列。

今天早上我们展示了一张简要的图片，说明了主页会变成什么样子。期待它的到来，你知道的，马上了。我们想做的是，我们想创建一些不同的hubs（hub就是指愿望单、购物车下面那一行的蓝底灰字内容，大概可以翻译成『（分类）中心』），这就是一个例子，我们的视频中心。我们会将这些相同的概念用到VR、软件和其它东西上。顾客们不需要去搜索结果页面来寻找他们感兴趣的内容，而有这么一个地方是我们主持和良好地影响不同类型内容的曝光。

在最上方会有主要推荐内容（promotional main carousel），它会由最新发布、销量榜以及其它我们跟合作伙伴一起促销的内容所构成的。有一个叫做『推荐新品』的部分，推荐新品是基于比如你在玩的游戏或者其它你在看的视频内容。我们会应用一个处于新品发布期的作品的窗口，我们会为每个单独的顾客提供我们认为他们可能买的东西。还有一个『热门新品』表标签和列表，你可以看到人们观看的其它内容。有『热销商品』列表，这样你可以看到总的来说卖得好的内容。优惠（specials），是我们还没有花很多时间在视频内容上的一部分。我这么说的意思是，作为一个获取划算的内容交易的地方，Steam在游戏行业中是著名的，所以我们想要不仅能进行曝光它们，同时也想进入一个有规律的视频内容打折促销节奏中——可能随着时间，以后会每天都有优惠。同时我们也在探索一些想法，比如『我将这个视频加入了愿望单，你能提醒我（买）吗？有哪些流行的新免费内容是可用的？其他推荐的是什么？』甚至是比如『我有了Crunch Time的第一集，鼓励我买这一季剩下的部分。』这部分会在未来的几个月内出现，我们在积极地致力于这部分工作，我们非常希望这可以成为Steam视频内容主页上伟大的第一步。

图12.32

好的，只剩『呼吁行动』这一页幻灯片就结束了，然后是Q&A时间，我们之后会进行的。

如果你有视频内容，或者你认为你可以做视频内容，如果它跟你的游戏有关，如果你可以做一个教程，我们想让它上Steam。我们想要将这个内容带给Steam上的用户——他们已经非常喜欢它（视频）甚至更多。

如果你在考虑360或者VR视频内容，我们很乐意和你交谈，不仅仅是『嘿，我想把我的350视频发布到Steam上』，不，我们想谈谈你在生产360内容时的想法，你是怎么拍摄、编辑它的，你预期是如何发布它、分销它的，你认为商业模式是什么。我们想跟你一起开发这些内容。如果这就是你的话，那么请来和我们讨论。

如果你有我们今天没讨论到的商业或是内容模式，但是你觉得你的顾客会需要它们，那么请告诉我们，我们会看看构建它是否有意义。显然有其他的内容和商业模式，比如说订阅服务、独立的VOD服务，我们其实要支持这些也不难，我们只是需要知道是否有人有实际的需求。

如果在这次演讲之后，你仍不关心视频，我对你过去一小时花费在我这里的时间感到抱歉。但是，利用我们的捆绑机会。使用捆绑技术这对你和你的顾客来说有很大的价值。

以上。

谢谢，我非常感谢你们来到这里。

（观众掌声）

（Q&A部分）

Sean：

我们这里有个可爱的年轻人拿了一个麦克风。如果你可以举起手，他会到处跑动（送麦克风），而我也会尝试回答你的问题。

提问者1：

我有几个简短的问题。

Sean：

好。

提问者1：

你们有计划支持3D 360视频吗？

Sean：

3D 360视频，怎么，你有看到什么不同的吗？

提问者1：

立体声（stereos）。

Sean：

哦，立体（stereoscopic似乎发生了释义漂移）3D视频。这是一个好问题。如果你认为你在做这个，那么好的，我们来谈谈。

提问者1：

你们有计划为360视频支持Ambisonics（高保真度立体声响复制）音轨吗？还是只有定向音轨？

Sean：

是的，这是一个正在进行的讨论。因为这也是在整个VR内容中，我们投入精力和感兴趣的东西，而且我们也想要将这个应用到视频上。对。

提问者1：

你们有计划支持360视频的移动VR吗？

Sean：

会有播放器支持FOVAS技术，这点我刚刚忘了提了。我们要发布的这个播放器的意图就是，它会变成一个即插即用的东西。所以如果有人做了支持FOVAS的视频播放器，他们可以在Steam上进行进出交换，所以同样的一个技术也在扩展成列数Samsung Gear这样的东西，和我们在Vive、Oculus和其它VR头显上的一样，所以我们可以让那样的内容变为可能。它也是计划的一部分。

提问者1：

你介意分享一下你的email地址吗？

Sean：

我有名片，大家可以从我这里拿，就在演讲之后。

提问者1：

谢谢。

提问者2：

对于360视频，有没有……

Sean：

不知道我要看哪里。

提问者2：

就这里。

Sean：

哦，谢谢。

提问者2：

你好。当它分裂成多个视频流，它使用的投射是哪种呢？是一个圆柱还是说它要进行一次permitAll？你会加入一个圆柱然后让它从这分割吗？投射的几何学是怎么样的？

Sean：

它有点……所有都包含了一点，我们可以采用不同的输入。我猜Forest在这——Forest在那儿。Forest是Pixvana的CEO，他有很多幻灯片谈到了投射矩阵。我大概可以让你和他过会儿谈一谈。不过，是的，目的是在最后，结果看起来基本上是一个立方体映射或者者球面映射，这样我们就可以投射了。实上如果你用了demo并且暂停demo的话，实际上会发生的事情是我们会展示给你另一个类似立方体映射的版本，这样你可以看到它是怎么样的。然后你可以继续播放，而突然地你就回到了Centurylink Stadium（Centurylink Field，也叫Qwest Field，西雅图海鹰队主场球馆），而且看起来非常棒。你可以将它代入，看看实际的几何学是怎么样的。不过是的，确实有很多种投影方式，以及很多种代入内容的方式。

提问者2：

谢谢。

提问者3：

非常简短。我记得你提到了流式视频，不好意思，移动平台上的视频离线播放，这个在桌面端也会提供吗？

Sean：

这也是计划。由于安全原因和别的这样的原因，这里面有很多的限制。它不是……计划是同时解决这两个问题，我们已经知道如何在移动端解决了，所以接下来我们会看看能不能应用于桌面情景。

提问者：

那么你有预计营销的时间吗？

Sean：

我在Valve，所以我可以说是Valve时间。（观众笑声）不过我觉得我们预计的差不多是2017年中。

那边这位。

提问者4：

这太棒了，我之前都不知道Steam在做这个，我现在想尽快地了解他。如果我们有一个现存的SDA，你提到了所有的东西都是自动化的，你的意思是所有的东西，比如我下周想放一个先行版之类的，我还需要给你发email来获取一个视频的app ID吗？还是说我可以自己创建？

Sean：

单独的？

提问者4：

是的。

Sean：

单独的视频，你可以生成……对于那些有应用权限的人或者通过了绿光，会有个按钮写着『创建新程序』（Create New App），当你这么做的时候，你可以选择游戏、软件或者视频。如果你有一个单独的视频，你可以立刻就做。而对于系列基础的内容，因为它是新的，我仍然要点击写着『创建系列』的按钮，但是这个就是创建最顶层，然后你创建所有的季、集，你决定什么时候发布你的剧集，完全都在你的掌握中。

提问者4：

棒极了。谢谢。

Sean：

就在前面的这边。

提问者5：

你好。我要从哪里开始。我们有游戏，我们也有源自游戏IP的视频，你刚刚提到了捆绑包，将这些捆绑包放到一起有多容易？比如你可以让游戏有第1-6集，而捆绑包有游戏和6-12集。

Sean：

捆绑包是单独的package，你们今天会知道的。当你制作一个游戏的时候，你会有一个Steam package，或者是一个零售package。在你可以管理你所有的package的那一页里，有一个按钮写着『添加捆绑包』（Add Bundle），你只需要写入捆绑包的名字、设置好，然后加入那些package，这样你就会有匹配这个package的游戏和6集剧集了。所以这实际上是完全由你来创建的。捆绑包会叠加价格或者说是每个package的价格，如果你想的话，你也可以加上一个折扣。你可以写上『你可以随时购买每个部分，或者是一次性购买整个捆绑包』。

提问者5：

谢谢。这个在别的地方也是一样的吗？一样的概念只不过主题是视频，添加它……

Sean：

对，它的工作方式是一样的。捆绑包……（变了个声调，假装播音腔）专业的税收窍门。游戏内容的税收比例和视频内容的是不一样的，将它作为人生中的好东西怎么样？捆绑包存在的原因，有很大一部分是因为视频。因为我们打包或者说一起销售一个游戏加上一部电影的唯一方法，就是捆绑包的概念。我们不能放，你么也仍然不能放一个游戏和一个视频到同一个package中，由于税收原因他们需要被打成捆绑包。

所以，是的，它在两个地方都能用，而视频已经是捆绑包技术的最大应用内容。

Sean：

John

提问者6（John）：

对，我有个问题。在早上的幻灯片里他们提到的一点是，Samsung Smart TV app（三星智能电视应用）。假设视频播放会成为它的一部分，我想知道会是什么时候？会是比如2017年的模具？

Sean：

我的理解是，我们……三星其实大概在一个月前就宣布了，但是我们保持了情报。不过是的，应该是每台Samsung Smart 2017 TV上会有内置Steam Link软件。所以是的，到时候它会变成完全加密串流，通过Steam Link设备直接传输到电视上。

提问者7：

一个问题。我们是一个游戏的开发者，我们没有激活的SDA。就我们能发行的视频内容种类来说，能是跟这些一样的吗，比如播放YouTubers的视频，或者是我们自己的如果玩我们的游戏的视频，这之类的？

Sean：

再说一次，如果它是免费内容，我们会说，确保它跟你的游戏是相关的。如果是类似游戏指南的东西，在每个社区讨论区其实都有一块专门给指南的部分，所以这种情况下，我们鼓励你们，可能只需要把它放到YouTube然后在指南里放个链接就行。但是如果它更像是纪录片的话，我们有很多与游戏制作、游戏背景故事有关的纪录片，那么就可以放上来，你可以拥有一个包含所有内容的独立商店页面，或者你也可以在游戏里加入这个视频内容——在购买的那个地方。

我还有五分钟，所以，还有最后的问题吗？我看到了一只手，一只手，对，就在后面。

提问者8：

你能就哪类教程你认为是合适的、以及是否有正在赚钱的教程的例子再展开讲讲吗？

Sean：

老实说，所有的教程都比我能想象中他们能到的更好，而我们在去年9月份才开始发现他们。当然，跟建模、绘图的教程可能做得比其它的内容更好一点。新手教程在YouTube和其它一些地方有很多，而稍微复杂和深入点的东西看起来也做得更好，人们愿意花钱在能获得更深层基础内容的地方。如过你可以用3D Studio Max（3D软件）或者Maya（3D动画软件），或者你知道如何做材质，我们出售Modo（3D软件）和Cakewalk SONAR（音频软件）的各个版本——Seth（好像是Cakewalk软件创始人）正坐在第一排。如果你知道怎么使用这些工具，那么让我们把这个内容带上Steam吧。

提问者9：

你好。

Sean：

你好。

提问者9：

视频平台听起来非常让人兴奋。它听起来还在早期阶段，而且也在走强。我有个关于未来的问题。你和你的团队考虑过加入互动和分支视频？

Sean：

你提到这个问题非常有趣。之前问了个问题的John和我，一直在致力于叫做Media Lab’s Manifest的东西。它的概念是，你如何形容内容的传输以及与之相应的交互体验？可能你想到了你曾经有过的终极Blu-Ray DVD的体验，想将它做出来，这样它就能跟internet进行交流、随着时间更新、可以互动、社交，还可以有Steam聊天和讨论论坛，各种各样这类的东西。我们在思考它会如何工作，我们试图将它做出来，人们会关心这个概念吗？不过，是的，我们当然可以动态地在实时视频播放器中做一些事情。最简单的例子就是当你看章节式内容的时候，会有个按钮写着『看下一个视频』。我们知道下一个视频是什么，因为我们实际上会返回到服务器、找出你拥有的是什么、我们要带你去哪里，我们可以，（听起来是吸了个鼻涕）对不起，将同样的逻辑构建到更多的交互体验中。

好了，还有问题吗？

很好，感谢大家来到这里。为happy hour稍微呆上会儿吧。祝你们SDD第二天愉快。

（观众掌声）

13. 游戏即服务

By Robin Meijer and Joost van Dongen (Ronimo Games)

（Robin部分）

（观众掌声）

早上好。感谢各位在一大早来听我们的演讲，我们的演讲是关于『游戏即服务』。我看看这个怎么用（幻灯片遥控器）。

图13.1

我的名字是Robin Meijer，是Ronimo Games的一个制作人，我将会和Joost van Dongen一起进行这个演讲——他正坐在那个阴暗的角落里。他是我们的主程序员和共同创始人，我们都来自Ronimo Games这一家小型荷兰独立开发工作室，创办至今已经9年了。

图13.2

这就是我们的团队。比起同事，这些人对我来说更像是家人。

图13.3

我们一起做了一个叫做Awesomenauts（王牌英雄）的游戏。这是一个2D横版卷轴多人游戏，于2012年的时候登录到Steam，算上发售前花的时间，我们至今已经花了7年的时间在这个游戏上了，而我们为它提供支持也超过4年了。我们能经营下入全靠『游戏即服务』的商业模式，这也将是——我们的经验将会是这次演讲的主题。

图13.4

在我们深入讲解我们的经验之前，我想要先讲讲『游戏即服务』是什么，以及我们为什么很庆幸我们选择了这个，之后我会讲一讲2012年以来我们的经验，然后Joost会讲到我们所使用的补丁流程。

图13.5

据我所知，在游戏发售后，之后的走向基本上有三个选择。你可以基于你做得不错的游戏制作续作，试着让它更大、更好；如果你不想局限于你之前做的东西，你也可以做另一个游戏；或者你也可以选择『游戏即服务』模式，这就意味这你需要围绕你发售的游戏、对它进行扩展、尽力将它变为你想要的游戏。

图13.6

我坚信这个对几乎所有的游戏都有效，但是它更适用于有无限的可重玩性的游戏，这样玩家可以长期地驻留、而不需要你不断地制作内容。如果你的游戏除了最初的购买外有额外的收入点，它很有用，因为它能让你做更久的生意。如果你可以用一些有意义的内容扩展游戏，那么它也很有用。而如果你提供的是一个单独故事驱动的体验，那么保持一致做更多的内容就没那么容易了。

图13.7

而这些都在Awesomenauts上有体现。我们在这几年里发布了很多内容，我们一直牢记两个核心原则。首先就是将我们的玩家数量和活跃玩家数量放在短期收入之上，我们非常想要吸引更多的玩家，而这可能意味着要做很大幅度的促销。正因如此我们一直参与很多例如Humble Bundles之类的东西，或者在Steam上进行大幅度促销。当我们拥有更多的玩家参与到游戏时，它极大地提升了匹配游戏的体验，而这样反过来来创造了更好的游戏体验、吸引了更多的玩家投入进来、给他们更多游玩的理由。

在这个过程中的某些时候，我们不得不从发售后内容，比如DLC、皮肤之类的东西，获得收入。另一个目的也是为了通过不断地为玩家们发布有意义的内容让游戏保持新鲜。这也同样可以给他们一个回来进行游戏的理由，也保持他们能参与进来。

图13.8

我们很庆幸自己选择了『游戏即服务』而不是其它项目的，因为致力于一个活跃的游戏非常棒。我们做的每一件事情，我们开始开发的每一个东西，都有可能在几个月后发布，而这也就意味着玩家们会享受到它，我们也可以获得很多积极的反馈。这比发售一个游戏、享受几个月的赞美，然后关上门锁上窗、埋头再做两年游戏要好得多。这也让我们能更接近我们对Awesomenauts最初的设想。

Nathanile Blue在昨天的201中提到过，他的一个建议是『在你能达到的能力范围内开发你的游戏』（原文是『做一个你承受范围内的游戏』Build the game you can afford）。老实说，我觉得几乎没有一个开发者在游戏发售前能真正地认识到了他们想要的游戏，因为有一大堆的约束。而在游戏发售后扩展游戏，可以让它（真正认识到想要什么游戏）变得更有可能。甚至在发布Awesomenauts后的四年时间里，我们仍然没有真正地达到能说这就是我们所预期的最好的地步。

通常来说，对游戏提供长期支持一直是一件3A级的事情，不过得益于Steam上的一些功能，对我们这样的较小的工作室来说这实际上是可以做到的事情。我们只有15个人在做这个，但一直都进行地很顺利。总的来说，提供长期支持也非常的有趣。

图13.9

从我们公司的财政状态来看，在发售之后，我们已经出售了很多份内容、DLC和游戏。但是在第一年之后，我们其实获得了97%，对不起，69%的总收入。大部分游戏与之相比，它们的首年之后的销量通常只占总收入非常小的一部分。如果你贯彻『游戏即服务』，那么持续更久（收入增长）的可能性就更大了。而且我们在这个Steam游戏上做的东西，也让我们能在Steam外、比如说主机上获得大量的额外收入。到现在，我们已经卖出了超过200万份游戏。

图13.10

接下来我将按时间顺序回顾自发售以来的Awesomenauts，以及我们在这段时间经历的高潮和低谷。

（此后但凡图片出现右边黑**块内的内容，均为副屏幕内容，主屏幕只有左边蓝底部分。副屏幕内容基本不出现在视频中，因为这部分副屏幕内容比较重要所以一并从pdf中截取）

图13.11

在最初，Awesomenauts于2012年8月1日发售。在当时，它的表现非常好，对于正在经历困难时期的我们这个团队来说，简直是上帝的礼物。游戏表现得非常好，也被人们很好地接受了，而且迅速地超过了我们的预期。我觉得我们做得非常好的一件事情就是，我们承诺了发售之后会发布更多的内容——我们实际上也确定我们可以遵循承诺。

如果你有发售过一款游戏，你可能会注意到在发售之后，你可能会花几周甚至是几个月的时间来解决没有预见到的发售时出现的问题，比如bug、游戏性问题。不幸的是，你可能也会发现，玩家们会将bug修复视为理所当然，而真正能让他们兴奋的是新内容。我们想要确定的就是我们能发布这个。

我们做的方法是，在发售前确认内容是已经完成的，而这通常并不是玩家们想听到的——你只做了内容，但是又隐藏了部分。但对于我们来说，这是我们唯一能用来确保我们能履行承诺、给他们更多内容的方法。一旦发售之后的混乱减弱之后，我们就可以再次挑出更多的内容持续更新。

如果你考虑要采用『游戏即服务』，我非常推荐，你们承诺做出更多内容，将此作为必不可少的给玩家们的pitch（怎么翻，蓝图？企划？）的重要一部分，同时也要确保你能够做出来。这可能意味着，在发售前就需要完成内容。

图13.12

一个月后，我们发布了包含了游戏第一个DLC内容的更新，它们是给角色的9个服装、9个皮肤。自此以后我们开始了自初始销售后从玩家那里获取收入。你在这个饼状图里可以看到，从2014年8月以来的两年时间，DLC占了超过一半的收益源，而且基本上平均分到了装饰性DLC和游戏性相关DLC——在我们的例子中是更多的角色——中。随着我们发布越来越多的DLC，这部分带来的收入比例在不断增加。

即便是现在也让我们吃惊的一件事情是，在玩家们卖皮肤的时候，他们讲到的是为了『支持我们』的说法，而不是觉得有义务买它们。这就给了我们一个信号，那就是我们对他们有很多良好的意愿，而他们也没有觉得我们在内容上欺骗了他们。而对于游戏性相关内容，它稍微更混合一些。有时候玩家认为我们在对他们隐藏内容，而最终我们也会做一些折衷。我们售卖的DLC帮助我们继续我们的业务，确保未来有更多的内容。

正如有些别的演讲指出的，在发售后你制作的东西上，你需要对内容和价格进行实验，这可能会给你带来损失，但是也能让你获得大量数据，让你在未来能更好地调整报价。

图13.13

自发售快一年时，在6月份，我们开始在社区中做得更好了。我们当然跟他们讨论了很多，而我们也搞懂了他们会对什么打勾（喜欢什么）、对什么失望。这时候我们开始在新内容上玩起了花样，我们会给他们一些非常隐蔽的线索或者发送一些扭曲到不像样的图片。我们非常惊喜地看到玩家们在看到这样的谜语之后有多么的兴奋。这个内容可能还需要还几周的时间，他们不知道即将到来的是什么，但是他们非常想知道，从而我们的论坛里充斥着对它的宣传。

这对我们而言是非常重要的一课——要和最核心的粉丝进行交流。因为这些玩家、你的最核心的社区可能会去找到每一点滴你分享给他们的信息，然后进行讨论。如果有值得讨论的内容，他们会进行非常详细的讨论。这就在我们的社区里创造了很多的声音、很多的宣传。

图13.14

在发售后一年的时候，我们开始了一次Kickstarter众筹。这么做的原因是我们遇到了一些问题。我们在这之前一直是一准备好内容就进行发布，偶尔一个月做两三个补丁，就在我们如此努力的时候，我们发现这并没有真的将很多玩家带回到游戏。

我们通过外力获得了很多曝光率，我们通过Steam特卖或者Humble Bundle引入了很多玩家，我们和一些YouTuber进行了一些合作，效果非常的好。但不幸地说，不管我们自己做什么，我们并不能得到想要的结果。我们面临越来越多玩家进入『休眠』——也就是他们拥有游戏，但是没有活跃地在玩它——，这就意味着他们并没有加入到社区中，也没有加入到游戏匹配中，我们从他们那么没有获得任何的收入——虽然这是次级目标——，但是他们在让游戏成功的任何方面做出贡献。这就使人非常担忧，因为这些外力是我们不能直接控制的，如果我们想要长期对Awesomenauts进行投入的话，我们就必须要搞清楚是怎么回事。

但是玩家是不知道发生了什么的，他们可能听说了一些东西，知道我们在做一个新角色，但是他们不知道他们在未来的一两年里能期待什么。然后我们就进行了一次Kickstarter众筹，完全专注于分享我们的长期计划，某种程度上说，是将Awesomenauts的未来『出售』给他们。

图13.15

我们称之为Awsomenauts: Starstrom，像是扩展包一样。它含有一些可玩的角色和很多的额外的免费发布的内容。这次众筹最终是一次巨大的成功。包括Slacker Backer的众筹额在内，我们一共众筹了超过50万美元的资金，达成了125个目标。我们发现，在我们分享了游戏的长期设想之后，玩家们非常地兴奋。我们想讲的故事和我们想要达成的目标，和他们想要游戏实现的内容非常接近。玩家们非常地兴奋，他们支持了这个、以此帮助我们认清了Awsomenauts的未来。

我们没有看到很多游戏有类似的尝试、进行一次众筹，来发现他们游戏的未来设想。我知道Skullgirls（骷髅女孩）也差不多，它也非常的成功，而说实话我也没法再想出做过这些东西的游戏了。如果你考虑过『游戏即服务』，或者你已经在以服务模式运作有些了，已经有了一个稳定的社区，我相信这是值得深入考虑的。因为你的玩家如果对你的游戏的未来很感兴趣的话，他们会帮你发现它的。

图13.16

可惜的是，并不是万事都能顺心的。我们的众筹本身是非常有野心的，而且我们也对未来加入游戏的内容做出了很多承诺。三年过去了，我们仍然没有把所有这些（承诺）都实现，因为当我们继续的时候，我们发现并不是所有的东西都值得立刻放上开发日程的——我们是一个小团队，拥有非常有限的资源来实现这些东西。但是每次我们发布一些不是我们承诺过的特性的时候，玩家们会马上变得沮丧，所以之前做出的承诺变成了困扰我们的东西。当然，我们最终仍然会完成这些承诺，但是并没有那么容易实现。

我们发现，你谈论设想越多，它会越让你的玩家兴奋，但是做出详细的承诺有可能会反过来困扰你。在我们进行这次众筹之后，我们也尽量可能地对我们正在做和要做的内容保持开放态度，这样基本上就再也没有反过来困扰我们，仅仅是那些通常无法做到的详细承诺（会产生困扰）。

图13.17

众筹非常的成功，而Awesomenauuts也回归了正轨，社区里也很热闹。在2014年3月，我们将游戏发售到了PS4平台。你们可能经历过，在主机上发布游戏比在Steam上要困难地多，而且持续支持也是完全不一样的，这一部分会由Joost在之后谈到。在主机上做游戏对我们来说是非常宝贵的经验，同时也非常地成功。我们在Steam上提供支持、然后再带到主机上，事实也证明完全可以这么做。如果我们当时只做主机内容，我们肯定无法做到。

图13.18

大概两年前，在上一次的SDD上，我们俩（指和Joost）都坐在一个厅里——我记得是6楼的那个方向，我们听了Robin Walker的演讲，名字是『游戏即服务中的社区和交流』，它让我们看到了我们面对的问题的一个可能的解决方法。我们当时仍然在做很多的更新、仍然有吸引玩家回流的问题。而Robin Walker的演讲中，他讲了他们在Team Fortress 2里是如何做的。总结起来就是，将更新打包成更大的内容包，并围绕它构建一个故事，让它远不仅仅是一个只有补丁信息的更新，并且也是玩家们能为此讨论、兴奋和期待的东西，将你的社区与即将发布的内容紧密结合起来，而不是简单地发布了事。所以我们开始了将一些更新打包成一个，而不是每隔两三周就发布一个更新。我们每隔两到三个月更新一次，将我们在做的相同的内容打包到一个更大的包里。这对我们来说其实更简单，因为更新要花很长的时间，而这也让我们可以打磨内容，将它变为一个更让人兴奋的包。

图13.19

我们之前也做一些花样，但是我们开始以更大的规模进行。为此我们创造了一个叫做Voltar’s Vault的东西（更新），用于指向一个游戏内的神秘角色的。我们也做了一个网页，上面有一次更新中所有即将到来内容的列表，但是每个字不是直接给出的，在几天之后才会揭晓。在（更新发布前）数周，让社区参与进来，并为即将出现的内容感到兴奋。

图13.20

这些就是我们有的一些例子。我们做了个更新，我们给它一个名字，比如Seismic Shift、White Hawk Down、Secret of Space、Eye of the Storm，以及一些很棒的和游戏有关联的想法。我们开始发布这样的图片。（指向左下角）这样的扭曲的图片，每天我们会稍微降低一点扭曲度，然后玩家们可以稍微更多一点地了解我们即将卖给他们的东西。或者是直接给他们有隐喻的图片，比如右下角这张，这一张对我们其中一个角色进行整理（clean-up），让他变成一个更直白的角色。这些大部分最终都被我们的玩家猜中了，只不过我们需要在几天的时间里看论坛里超过200页的主题。

图13.21

这些在社区里产生的讨论帮助了宣传，它给玩家们提供了即将到来的信息，也帮助玩家回流。你可以看到右边2.3版本的更新，是我们首个这样的更新，在没有外力帮助比如覆盖和促销下，我们看到了玩家在回来，他们都对正在发生的事情感到很兴奋。在这之后，这就是我们一直贯彻的东西。

图13.22

除了将这些内容发布给现存的玩家之外，它也将『休眠』玩家带了回来，给了他们一个回归的理由。如果你给玩家的是小型更新，他们可能听说了然后就（没啥反应）；但是如果你每隔两三个月发布内容，他们听说了即将到来什么、你在游戏中加了什么，他们很可能就会很兴奋、很愿意再尝试它。同时，我们也尽量多地接触玩家，我们会使用比如Steam活动、Steam公告之类的，我们也看到了效果很不错，尤其是如果你提供给玩家签到、在Steam上关注你的游戏的动机——我们最近给在社区论坛签到并在Steam上关注游戏的玩家提供了一款皮肤，而在一个星期内，我们看到玩家的数量翻了个倍，这就意味着我们所有正在进行的交流，都有双倍的回流玩家的效果。

图13.23

正如我所说的，我们继续用这种方式提供更新。在2015年12月，我们又有了同样的问题，我们做的更新影响力越来越小，而且媒体也完全不报道我们，因为当时已经是一个发售3年半的游戏了。我们就决定再往前走一步，打包更多的更新。

图13.24

这就是Awesomenauts第二个扩展包，叫做Awesomenauts: Overdrive。它跟Starstrom众筹并没有明确区别，我们只是将我们已经计划的未来6到9个月的内容进行了打包，告诉给玩家们即将出现的什么。与Starstorm相呼应，Overdrive也是有3到4个更新组成的。简单地通过对内容进行重命名，我们终于又有更多的媒体关注——媒体又重拾起它，玩家们也对它非常兴奋。我们花了3个月的时间有规律地放出了各种beta、open beta给玩家们尝试即将进行的更新。在这3个月的全程，玩家们都非常兴奋，最终发布的时候，我们获得了玩家数量急速上升。

图13.25

在内容发布的时候，我们看到玩家的回归，他们也对这些内容非常的兴奋，而且它也让游戏体验焕然一新。内容是如此的大，以至于完全改变这个游戏。由于我们做的新角色、新特性，如果玩家们6个月没有玩过游戏并在这个时候回归，他们会看到一个完全不同的游戏。

图13.26

但是并不是所有东西的结果都是好的，跟上次的扩展包一样。右下方的这张图是我们的销量，左边的峰值是冬季特卖，2月早期的应该是Steam上的另一个特卖（春节），而右边的这个峰值是我们发布新版本的时候。它跟之前的促销某种程度上差不多，但是这是完全在我们控制之中的东西，它产生的收入帮助我们能够更长时间地开发游戏。我们现在能至少再开发这个游戏一年，甚至是更久，这都是因为我们从这类更新和扩展包中获得的收入。我们当时发布了第二个角色捆绑包，而且它也带给了我们很多收入。

不幸的是，我们看到了每次我们发布游戏性相关内容，而不是纯装饰性DLC的时候，玩家们会有些不满。我们从游戏性相关DLC那里得到的抵制远比装饰性DLC要大得多。你看到的右上角的评测，都是对游戏本体的评测。这类DLC确实影响到了我们的分数，但是它也帮助我们保持对游戏的支持，所以我们就不得不做一些权衡。

还有一个比较负面的是，我们将这持续6到9个月的体验叫做Awesomenauts: Overdrive，而在我们发售的时候，扩展包也用了这个名字。这就导致玩家们对他们能免费获得什么、什么内容需要付费感到困惑。一旦这种困惑在社区中产生，这并不是我们能轻松声明的，我们花了好几个月的时间告诉玩家们去预期什么，以及什么内容会是免费或是付费的。不过那次之后，我们仍然坚持了故事的所有内容、游戏匹配更新或是新地图都是收费的。如果你想要做类似的事情，尤其是你准备用一个名字发布免费和收费内容的时候，我非常推荐你——就跟昨天别人告诉我的一样——测试一下你的沟通能力，尝试接触玩家，在发布给社区之前看看他们对你的沟通有什么反应。

图13.27

这样就造就了我们的今天。我们仍然在做更新——被命名的更新——、打包内容，也计划做更大的故事、谈论我们对此后6到9个月的设想并在之后这么做。Awesomenauts今后会有更棒的东西，我们现在也计划开发到第五甚至是第六年。同时我们也在兑现一些我们以前做的承诺，即便他们可能迟到了3年，我们也希望玩家们能在它们发售的时候能变得兴奋。不过我们确实得到了一个教训，不会做出更多的承诺，而目前我们也不会宣布什么东西。

这些差不多就是我的演讲部分了。Joost马上会过来，从头到尾讲讲我们的补丁流程。就是这样，感谢大家今天到这里。

（观众掌声）

（Joost部分）

图13.28

好的，谢谢大家。欢迎你们来到『游戏即服务』的第二个部分。我的名字是Josst vvan Dongen，我是Ronimo的一个创始人之一、也是主程序员。我也是Joost’s Dev Blog的作者。我有点好奇，能举个手让我看看有人读过我写的文章吗？哦，不错，我看到了好几只手。非常荣幸，谢谢。

Robin谈到了我们对于『游戏即服务』的看法，以及我们是如何做市场营销、如何接触玩家这类的东西。我会讲我们是如何发布补丁：我们如何开发、中间发生了什么。更多实用方面的东西。

图13.29

我先简单地过一遍这个流程。首先当然是开发新内容。这个部分我不会讲很多。然后我们会进行几周的beta测试。然后就是发售周，我们会有一个非常紧的时间表，在这个时候做QA（Quality Assurance，质量保证）、周三发布——在我们这里都是周三——、以及几天后可能有的修复程序。然后几周之后，发布一个平衡性补丁。最后在几个月后，将内容发布到主机上。我会对这些逐一解释。

图13.30

在我开始之前，以防万一你们没有在Steam上发布过补丁（我要介绍一下）。Steam其实是一个发布补丁非常好的平台，它非常的简单。你只需要在你的硬盘上生产一个版本，将Steam指向这个文件夹，然后告诉它『这是游戏的新版本』，而Steam就会明白要做什么、哪些文件是被更改了的，它就会上传这些文件，然后你就可以随时启用你的补丁了。非常简单的流程，也非常快，一旦补丁完成之后，如果它不是太大，它在10分钟之后就能上线，有时候甚至更快。如果你愿意，你可以在一天之内发布多个补丁，玩家们会在同一天得到补丁。如果你搞砸了，你可以撤销你的补丁回到之前的版本。这些都是Steam的功能，非常的棒。你也可以自行发布DLC，你需要提前告诉Valve去修改你的商店页面，但是你可以在你想发售的时候按下发售按钮。如果你只用Steam，这个可能看起来非常平淡无奇；但是如果你做过主机开发，你就不会这么认为了。在主机上，这些都要难得很多很多。

图13.31

第一步，当我们要做一个新补丁的时候，我们会搞清楚我们要加入什么内容。这需要结合很多的因素：我们的想法，我们可能有很多之前想做、但是没有做的东西，而现在可以做了；我们也经常看社区的要求是什么、他们在抱怨什么，这样我们就能解决了；是否有我们想要重拾的东西；我们也有一个长期的设想，我们并不是开发给，『好吧，下个补丁还有两个月，我们现在要开始』，大部分都有更长的开发周期，我们同时会有几个补丁在开发中。

图13.32

我提到过我们会看玩家的反馈。玩家的反馈可能是非常粗暴的，他们经常不能将情绪和事实分开。如果他们刚刚输了一场比赛，那么他们可能会非常生气，然后会写一些像上面这个这样的东西。这在评论里面挺常见的，尤其如果你在做多人游戏的话。你需要弄清楚的是，在这背后的问题是什么。还有一个问题就是，玩家们经常对他们想要的东西不认同。所以当一个玩家发布了这样的东西，你经常会看到有另一个玩家因为他的观点感到生气，因为他有不同的观点。这就让该怎么做变得更难判断了。

另一方面就是，我们注意到如果你更改了游戏里的东西，总会有人不喜欢它。不管你改了什么，或者你加入了什么，总会有人不喜欢。我们甚至有玩家抱怨『这让游戏对新手更好，但是我不想要新手玩家因为他们太菜了，所以我不喜欢这个游戏』——这是我们真实地获得过的一个反馈。

总的来说，如果你不发布补丁，玩家们会抱怨你什么都不干；如果你发布补丁，那么他们会抱怨你做的东西。这很难平衡，你也需要做好准备长一张厚脸皮，不要太个人地看待这些东西。因为如果你看了太多这些内容，并且带入到自己的话，我猜你可能最后会从一座桥上跳下去，这可不大妙。

图13.33

『游戏即服务』也很适用于调整平衡性。因为你要做很多补丁，可以在平衡性上进行迭代，随时都可以进行改善，你不需要在发布前做到完全平衡。在每一次大更新中，我们会有很多的平衡性修改。Awesomenauts是一个大游戏，有很多角色、很多平衡性参数，所以在一个大型补丁中你会看到长达六页的平衡性调整——这已经排除掉了补丁里的新内容。有一件很重要的是，你需要以玩家的反馈和数据为基础。你需要很多的数据，收集它们，你也需要玩家的反馈，因为如果玩家玩你的游戏的成百上千小时的话，这些玩家其实比办公室的任何人都要了解游戏。如果办公室里的没有人能成为排名前1000的玩家，那么就很难为专业玩家的判断平衡性。所以你需要跟数据结合，在这上面做工作。

图13.34

我认为，完美平衡是不存在的，平衡太复杂了以至于只可能在理论上存在，但在实际情况中你永远不可能达到完美平衡。即便它存在，即便你的游戏有了完美平衡，你仍然需要发布丙丁并修改平衡性。这个可能听起来很奇怪，但是我们看到的是随着时间，玩家们都会趋向于使用相同的战术——通常他们会用过强的策略。即便过强的策略不存在，他们会讨论游戏，搞清楚一些东西，教给别的玩家如何玩游戏，然后他们就会开始做相同的事情了。这就让游戏变得陈旧、无聊，你会知道『哦，他是Lonestar，他会做这个』，因为这就是Steam指南里说的，也是游戏里所有Lonestar所做的。所以我们注意到了，即便游戏的平衡性部分看起来是好的，我们仍然需要改变它。

一个很好的例子就是，在一次锦标赛中，一个队伍使用了一个之前从没有人尝试过的新战术，并赢得了比赛。但是这个战术其实已经可以实现好几个月了，他们在锦标赛中使用了一次这个战术之后，很快所有人都知道了，并且所有人都用这个战术。这个策略其实是有点差劲的，所以我们需要修改平衡性来摆脱它。

图13.35

反馈是非常重要的，但同时也是非常困难的，因为玩家们反对的太多，即便你阅读了很多的反馈、对社区进行了很多的回复，他们仍然会抱怨你没有跟他们交流，会说『你是怎么想到这么蠢的一个想法的』。所以我们现在会根据这个计划来做平衡性调整。

我们的一个设计师会阅读论坛，他会在Twitch上跟社区讨论，他会和几个核心玩家进行电话会议，然后他就会列出一个他想要进行更改的列表，然后放到Google Docs上，让玩家们能对每一个更改进行评论。他会看这些评论，然后再进行修改，稍微进行一些迭代后就会实施。它会进到beta里，人们会玩到它，他们会给更多的反馈，然后再进行修改。这样几次后就进行最后的发布。你能看到这里有很多步骤里，社区都能提供反馈，而这些都是为了确保他们知道即将到来的是什么。

图13.36 （木哈哈个鬼啦）

我们开发新内容，而主要部分并不是平衡性问题。我们发现如果我们发布的只是平衡性改动，就算它有10页的内容，也不能带回来一个玩家，所以你需要新的东西。我不会讨论开发什么样的内容，这部分有很多别的演讲来说明。

图13.37

一旦一个内容差不多做完了，我们需要测试它。由于我们定期地做大型补丁，一直对它进行QA是非常昂贵的。如果你想要在Awesomenauts上做一次完整的QA，我不是很清楚，可能需要10个QA人员进行一周或更多的工作。对我们这样的小工作室来说非常贵，所以我们不会这么做的。我们的方法是在beta中做尽可能多的QA，在最后进行少量的付费QA来对一些特定内容进行专业测试。用Beta代替了很大一部分的付费QA。

图13.38

如果你在Steam上进行beta测试，你可以用很多种方法实现。你当然可以在Steam外进行，但是我并不推荐，因为Steam非常擅长进行beta测试。但是如果你的游戏还没有发布，那可能你需要这么做。在发售前，你也可以在主程序上进行beta测试，给想尝试beta的玩家分发key，在游戏发售后你可以选择禁用这些key。如果你分发了很多的key，Steam并不推荐你这么做，因为禁用key会在发售后的头几天产生一些罕见的商店行为。这些就是我们在发售前的策略。而一旦发售后，我知道有四种可以在Steam上进行beta测试的方法。我会逐一进行讲解，而这些方法我们也都做过。

图13.39

第一个方法就是创建一个完全单独的Steam应用，然后把beta放在这里面。你能看到，这是我的游戏列表，它同时有Awesomenauts和Awesomenauts Beta。我们之后没有选择过这种方式，但是在四年前做过。由于他是一个完全单独的应用，玩家可以选择是否下载它，他们会自动获得它的补丁——beta版的补丁。值得注意的是，它跟主游戏是完全分开的，这就意味着成就、积分榜、以及创意工坊物品，都是不能跨版本使用的。这可以是很好的，因为这意味着当你有bug将积分榜搞得一团糟的时候，它不成一个问题；但它也可以是坏的，因为如果你想测试成就系统，如果你在beta中错误地设置了它们，那么你在beta终究会有bug，而不是在主游戏上——或者反过来——，而这会让测试更加困难，很难搞清楚到底在哪里出了问题。这也是bug的一个诱因，因为你需要在Steamworks上连续做两次。

图13.40

Steam上最常见的beta测试的方法是使用可以切换的Steam分支。如果你在Steam上右键点击游戏，进入属性，来到测试标签页，用户就可以选择游戏的不同版本，Steam就会自动下载那个版本的补丁。这是Steam上完全自动化的一个系统，它运作得非常良好。当你发布一个补丁，你只需要点击『这个是游戏的默认版本，这个是给beta的』，如果你愿意，你还可以有好几个beta。如果你想限制进入的方法，你还可以加上密码。注意，黑客们在Steam上能找到很多的信息，所以即便他们不能获取到那个加上密码的版本，他们也可以获得它的名字。我们就因为这样的事情导致过泄露。

这是最简单的一个方法，但是它也有一个很大的问题，那就是无论用户什么时候想要尝试beta，他都需要选择beta并等待下载，然后才能玩到它。如果你的下载量有500MB，这会花费很长的时间。我们经常看到玩家们说『我没有尝试过beta，因为我需要等很久，而我又不愿意等』，所以我们因此就停止了这个方法，因为我们想要尽可能多的玩家尝试到beta，或者至少对他们来说尝试beta应该是容易的。

图13.41

这是我们用在大多数beta上的方法。我们将beta作为一个DLC发布，只不过是一个免费DLC，而且默认是禁用的。如果有人想尝试beta，他们需要右键点击游戏、进入属性，到达DLC标签页，然后启用Beta dula-load PC DLC或者Beta dula-load Mac or Linux DLC就可以了（实际上直接在游戏简介中的DLC栏就能点），然后它就会自动下载。如果一个玩家这么做了，他在硬盘上有两份这个游戏，而beta是主游戏下的一个子文件夹。如果这么做，两个版本都会由Steam更新，所以如果你发布了一个beta补丁，用户们会自动下载它，而他们也可以非常简单地在两者之间切换。如果玩家有两个版本，在他启动游戏的时候，游戏会问他『你想启动哪个版本的游戏？』

至今为止，我认为这是最简单的方法，能让玩家在beta之间快速切换。Valve也告诉我们，他们喜欢这种方式，因为我们可以完全自行设置，我们不需要联系Valve的员工来为我们做一些定制的工作，而且按照Steam上发布游戏来看，我觉得他们已经够忙的了，看起来也无法再忙点了。

图13.42

这是我们曾经用过几次的另一个方法。我们只在最近用过，也只用过几次。这个跟beta，呃，跟DLC那个方式差不多，但是在这里，每个人都被强制下载，我们在游戏内有一个开关，用于强制打开游戏的一个或者两个版本。我们会在想让整个社区都尝试beta的时候使用这个方法，但是一般只会用上几个小时。我们有新的游戏匹配，但是又不能在小范围玩家中测试游戏匹配，所以我们可能会在周一早上的时候启用这个beta，然后在周一下午从整个社区获得足够数据的时候禁用它，只会持续几个小时。

重点就在于，这个方法让我们能快速地切换，但是对于玩家来说仍然是困惑的，因为他们获得了一个新版本，但是后来突然又没了。如果有什么明显的bug，那么每个人都会注意到，而不仅仅是那些点击了beta的人。

图13.43

给玩家提供beta权限。你可以允许他们免费使用beta，是一个open beta。这会提供给最多的玩家，也是我们现在在做的。如果你想要限制beta，你也可以有密码。你也可以售卖你的beta，在Steam上以DLC形式出售，或者在Kickstarter上作为奖励出售。这张图就是我们Kickstarter上的Iron等级，花费30美元，你可以获得beta权限。我们大概持续这么做了两年，然后我们就将beta开放给所有人了。这也是Kickstarter众筹上驱动收入的一个因素。有一组好的奖励对于进行一次成功的Kickstarter众筹是非常重要的，而对于玩家也是非常有力的奖励形式。

图13.44

另一件需要注意的事情是，即便玩家获取了beta，这也不意味着他会去尝试它。我们有的一个问题就是，如果我们有新内容比如新的角色，玩家们尝试了新角色一次，提供了反馈，然后他们就再也不会打开beta了。我们经常看到的就是他们告诉我们，『哦，那个新角色太强了，你需要改这里和这里，你也要改这里让它更好玩』，然后我们进行了这些修改，然后发布了一个新beta，但是基本上没有人会玩。很多玩家只是读了beta补丁信息，然后根据这个来提供反馈。这非常不好，我们想要他们体验游戏，而不是阅读游戏、然后对不符合他们所想要的内容感到生气。

我们做的是，在第一轮之后得到的相同反馈，我们会重视它，我们试图不将需要大型测试的内容放到第二轮，尽量在第一轮解决。如果我们觉得需要更多的玩家参与beta，我们会做围绕beta的市场营销。我们可能会在Twitch上玩游戏，在beta测试中跟在线玩家进行对抗。这可以很好地刺激玩家开始玩beta，因为每个人都喜欢出现在开发者的直播里（『上电视』）。

图13.45

我们做了几次beta，并且快要发布的时候，就是我们需要开始进行翻译的时候。在此之前我们不会进行翻译，因为通常在beta中的修改可能会同样改变文本。我们发现很多玩家都非常愿意帮助翻译游戏，而我们做的就是，为每一种语言，我们的都有一群愿意帮助翻译的人，这样，当我们需要新的翻译的时候，我们将文本放到Google Doc上，给这些想要帮忙的玩家发送一封email，然后他们互相检查彼此的工作，万一有玩家恶意翻译，也能帮助修复这个问题。我记得Minecraft有个例子，在南非的翻译的主菜单中有脏话，也很难查到是谁干的。这就是为什么我们总是有几个检查文本。

我们给这些玩家的主要奖励是这个图标。在游戏中，这是在分数榜和排名榜的名字边上的很小的一个图标，只是一个金色鸭子，而玩家们非常想要得到它。他们可以通过任何形式下帮助我们、或是帮助社区比如持续更新wiki、论坛管理员，这样的途径来获得这个鸭子。而这个在我们的社区里非常受欢迎。

图13.46

另一个问题就是当你同时开发了一些东西，而其中只有一部分发布的时候，你需要以某种形式进行划分。其中一个非常明显的方法就是，将它们进行分支。其中一个分支做一个新的角色，另一个分支用于市场营销，再来一个提供给旁观者模式——我不是很清楚——，这样几个不同的东西。这些都可以同步地开发，而等到想要做一个补丁的时候，你只需要将它们融合到主体中就可以了。这是一个常见的方法，可以用来看你是否在旁观者模式中加入了什么bug，而因为还没有完成，这些bug也不会影响到下一个你在做的没有旁观者模式的补丁。

虽然这是一个常见的处理方面，我们也不喜欢它。我们注意到，如果其中一个版本有比较大的重构，那么我们就会遇到很多的矛盾。另一个我们注意到的是，它对内部隐藏了新内容。比如一个美工在他的分支上做了什么东西，而程序员在旁观者模式中又不能偶然地迎合这个内容——我们认为如果你的东西能一直偶然地跟别人的内容『撞车』是非常好的，因为这会给你更多的反馈，了解团队里的其他人在做什么。当然你可以切换你的分支来达到这个目的，但是在实际当中你并不会这么做，而且很多美工自己并不知道怎么切换分支，他们常常会忽略一些非常复杂的命令行什么的。

图13.47

在我们正式发布补丁的一周前，我们会将整个游戏分到一个单独的分支中，这样任何的开发都不会影响补丁。然后我们会在这个分支中，进行对补丁做修复。我们会禁用所有未完成的内容——我们开发的方式使我们很容易就能做到。当我们进行旧的修复的时候，我们在这个分支的基础上进行，这样就不会将其他开发中的bug带入到修复中。

图13.48

与此相关的是，如果你有很多玩家，而他们喜欢破解你的游戏来看里面是不是有什么秘密。我们有几个例子，有一次我们有非常棒的市场营销路线来揭开一些东西，然后大概在我们开始前一周，有人在游戏中发现了实际的材质、还没完成的美术，然后他就将这个发到了论坛上，然后就没有剩下什么我们能用的了，因为所有人都已经见到过它了。我们做的就是，我们做了一个工具来自动删除所有与特定内容相关素材，在之后的每一次发布和开发之前我们都会用这个更新一次。当然如果你不小心删得太多，这也会是自身bug的源头。

图13.49

在补丁发布前的周五，我们会有一个外部的QA公司来做QA。这是一个小团队的一天的QA，非常的集中，我们要争分夺秒地选择与测试相关的内容。我们跟我们的QA公司有一个协议，就是我们可以在这周一决定周五要做测试。如果开发耽搁了，我们可以在下一周做这个。在整个流程中，非常重要的一点是，让整个流程需要的时间尽可能的短，尽快地做修复和让它们上线，这就是为什么我们会在周五进行QA。我们只会在比较大的更新的时候做这个，因为做这个还挺贵的。

图13.50

在周五他们发现bug之后，我们会在周一到周三修复这些bug，然后我们内部会做一些有限的测试，不会太多。然后在周三，我们可以最终发布补丁。

图13.51

为什么我们在周三发布呢？这是我们做出的一个特定选择。

我们不想在周末发布，因为如果有任何的问题，我们不想要我们的团队在周末也要工作。同样地理由，我们也不想在周四或周五发布，因为如果补丁有大问题的话，我们也还是要在周末回来修复，尽快上线修复程序。

如果我们在周三发布，那么我们仍有周四和周五来制作修复程序。总的来说，如果游戏发生了不好的事情，而也很容易修复的话，它就像是『哦，我加了太多的0在这个角色的伤害上了』之类的，虽然你需要找的通常稍微比这个难找一点，但是也是很容易修复的。

我们也不想在周二发布补丁，因为我们的比赛匹配有点依赖Steam的稳定性，而在周二Steam会有服务器维护。在我们比赛匹配的方式下，这就意味着每次服务器重启的时候，每个在这个服务器上的某个房间里进行游戏的人都会被踢出游戏。玩家们因此不喜欢周二，而我们也是。我们也不在周一发布，因为这是周二的前一天。

图13.52

在发布补丁的时候，我们能自行做所有的东西。我们可以在准备好的时候按下按钮，这样就发布了。我们同样也可以自行点击就发布DLC。我们会在周三傍晚——欧洲时间周三傍晚——发布，因为这个时候Valve员工们已经到了办公室（原来V社10点开始上班），如果发生了什么意外，我们可以请求他们帮助我们。总的来说我们基本上不需要用到这个，但是以防万一有些东西很糟糕，那么能联系Valve帮助我们是最好的。

图13.53

在即将发布补丁的时候，我们会做一个直播。总体上每周三我们会做一次直播，而当我们要发布补丁的时候，我们会先做直播，然后在直播的中途会将补丁发布，这样人们就不会跳过直播了，因为他们都会想要玩到新内容。然后在直播剩下的时间里，我们会和线上玩家一起游玩新内容。做这个很有一次，对我们来说就像是庆典一样。它有很多的观众，因为大家都对新内容非常兴奋，而它又没有上线，所以这是用来欣赏他们兴奋的最好的方法。

图13.54

在Steam上发布补丁有几个问题，并不都是玫瑰和阳光——我不知道在英语里这是不是一句格言，但是我就这么说了。我们要说的是，大概1%，或者0.1%的玩家——记得准确的数字了，不过我有一个大概印象——会得到损坏的下载内容。也就是说，有些文件在我们发布补丁之后坏了。解决方式就是，他们需要右键点击游戏，然后验证Steam缓存的游戏完整性，Steam然后就会检查所有的文件，然后进行修复。有时候甚至这个方法也不行，这就很操蛋了，这就意味着我们总会得到一些关于崩溃的报告，而在这些问题上我们并不能做什么事情。

对于一些玩家，大部分玩家，这些补丁只要他们不在任何游戏中就会下载，但是对一些玩家，这可能需要花上多达24小时的时间、甚至需要重启Steam、重启电脑，才能等到补丁开始下载。这意味着在补丁发布后，有一段时间玩家们同时在玩游戏的不同版本，补丁发布后，Steam也没有将这些玩家踢出游戏。所以在游戏匹配中要小心，不要让这部分玩家相互连接，因为这很容易导致奇怪的崩溃。

图13.55

这一部分说起来就比较羞人了。每次我们做了一个大补丁的时候，我们总是需要在两天内做修复程序。Awesomenauts太复杂了，即便有几个月的beta、付费QA和内部测试，也无法寻找到补丁里所有的问题。这里常常有非常隐蔽的内容，或是特定的平衡呃，特定的战术，会变得过于强，而在补丁发售前都没人想到过。做足够的QA来确保他们能发现所有的问题对我们而言，我们是承担不起的，所以我们只能接受每次补丁后，都要在两天内做出补丁程序。当我们周四早上回来的时候，程序员已经知道我们那天要修复bug，而第二天我们要做出一个build然后发布它。

当然，用户们不喜欢我们经常发布带有bug的内容，但是同时他们也对我们能迅速修复而高兴。因为在两天内做出修复，甚至有时候在一天时间内，是相当的快了。

图13.56

几周之后，我们会发布一个平衡性补丁。理论上，你会在beta期间就有足够好的平衡性，但是在实际操作中，一个新角色或新内容有多么的强力直到在被社区游玩过很多次之后才能搞清楚。我们发现甚至在内容发布后最初的几天，也有很多玩家提供的平衡性反馈，但是这些反馈跟几周之后你看到的反馈是完全不一样的。

一个很好的例子就是这个角色，Ix the Interloper。在发布后的前几天，社区似乎都同意他的平衡性非常好、我们终于做好了一次。但是2周之后，天都要塌下来了（all hell broke loose），因为他们都觉得我们干了一件非常差劲的事，而他的平衡性也非常糟糕。

所以我们总是会等上一段时间来获得好的反馈。

图13.57

现在它已经在Steam上线了，我们完成了补丁，内容也不错，我们也很开心。但是当我们开始开发主机补丁的时候就变了。如果你曾经做过主机开发，你就会知道，如果你想要发布什么东西，你需要通过一个验证。验证需要大概一周的时间，而直到完成之前你都不能发布。实际操作中，从你做完补丁的时刻，到你能发布新补丁的时刻，中间通常会花2个星期。而这让整个事情——比如像我们要2天内容作出修复补丁——变得非常地糟糕，因为你不能那么快地做完这个事情。

同样的，如果你要加入新的付费DLC，情况就变得更糟了，因为你需要在欧洲和美洲地区、有可能还有亚洲地区——如果你在这里也卖的话——设置商店，而且你需要通过很多官僚机构流程，而2周是理论上的最短时间了，实际当中需要4周来让所有的商店准备好所有内容、准备好准时发售。

主机上的另一个挑战是，没有能用来做beta的简单方法。虽然（主机上）有了不少改变，出现了一些选项，但是你最好还是假装你不能在主机上做任何与beta有关的事情。

图13.58

我们的补丁工作流程的大体理念是，我们的周转期很短，如果我们想用它，我们不能把它用在主机上。

图13.59

所以我们基本上就把Steam当作主要平台，在内容于Steam平台上多次迭代上线，并且我们确认内容和破坏性都是好的之后，我们才会将它带到主机上。等到没有糟糕的地方，我们才会发售它。这意味着我们在补丁内容在Steam上发布数周后，才会在主机平台开发补丁，而实际上的发布时间通常要好几月之后。主机玩家当然非常讨厌这样，他们在Steam上看到了新内容，他们在我们的Facebook上看到了所有的营销等等，而他们知道一段时间内他们玩不到。但是我们已经在这个上面进行过不少研究，仍然并没有找到一个能做得更好的合理做法，而不需要花大量的金钱在上面。我记得有些游戏在主机上有比我们快得多的补丁速度，我们的玩家告诉我们，例如Smite，在这个上面做得非常好。但是我也在网上读到了他们团队有大概150个人，是我们的十倍，所以他们的预算和限制是完全不同的。

图13.60

然后就是做一些总结。

对我来说最重要的一件事情是，开发一在线游戏是非常棒的。在有些情况下，我们会想到新特性，而几天或者几个月之后它就是上线了。这是一种非常有意思的开发游戏的方式。这对我们来说是最主要的一件事。

另一件事，正如Robin展示过的，『游戏即服务』可以提供源源不断的收入，而不是每隔两年一次性获得大量钱，你每个月都可以有钱，你对现状如何有更好的理解。如果你是个热门，那么『游戏即服务』尤其是一个良好的方式让你的工作室继续运作。即便你不是热门，我知道的是，Renowned Explorers的开发组Abbey，在发售的时候销量并不是特别好，但是他们持续支持了很久，而现在它的销量已经非常不错了，他们工作室也非常高兴。所以即便你的游戏在发售时并不热门，『游戏即服务』也能在长期运作中拯救它。

Steam对『游戏即服务』而言很棒，它有很多功能可以帮助你做这些东西。

在游戏发售前想好是否要做『游戏即服务』，以及可能有一些内容不在发售时发布是非常重要的。最后这的一条也是一个很好的例子『学会如何跟社区交流』，有些东西你可以告诉社区，而有些不能。不要做太多的承诺。在发售时拥有不会发布的完成的内容，这个可能是你不想告诉社区的。在你不想告诉社区的同时，在很多情况下，在你需要解释你在干什么、以及询问社区他们在讨论什么的这些时候，这些时候你的交流永远也不嫌多。所以不要承诺任何东西，但是一定要解释你在做什么，也要问他们『为什么你们这么生气，发生了什么问题？』

将内容放到更大的补丁当中也非常重要，我们也使用了很多beta。我们也养成了厚脸皮，这样我们不会把自己丢下桥了。

图13.61

我们今天在台上不会做Q&A，不过如果你想问一些问题，尽管来找Robin或者我，或者是给我们email，我们的email就在这里。我也说过，我有个Dev blog，在上面我写了很多关于游戏开发的东西，也有很多关于Awesomenauts的文章。如果你感兴趣的话可以去看一看，读到更多的内容。谢谢大家。

（观众掌声）

14. 游戏服务器托管

参与人：Spencer Rose (Bankroll Studios)、Steffen Heigel (Valve)、Richard Lawrence (Daybreak)、Karl Bergström (Stunlock Studios)

主持人： Kassidy Gerber (Valve)

（note：这是一次panel，全程基本没有出现幻灯片，所有都是根据官方网站给的pdf我自己对应插入的）

（观众掌声）

Kassidy：

大家早上好。我是Kassidy Gerber ，在Valve工作。首先感谢大家今天早上能来。

你们当中可能有人在疑惑，为什么我们要在SDD上进行一个游戏服务器托管的专题讨论会，可能你们在想，『真的有足够多的有意义的创新空间来专门为它进行这么一个专题讨论吗？』

（棒读开始）而事实上是，由于经营在线游戏的服务器很难，但对游戏来说有很有意义，我们看到它们在最初的发售之后好几年的时间都保持了健康。这些在线多人游戏在平台上常常位列最成功的游戏中，因为当做得好的时候，经营在线游戏服务器需要游戏开发者和社区之间的联系。有时候我们认为这对游戏的成功是非常关键的。

当SDD计划开始的时候，筹备委员会联系了Steffen和我来进行一次在Steam服务器上托管第三方游戏的演讲，我们对此很感兴趣，因为这对我们来说非常新鲜。过去我们在我们的服务器上只托管过Valve游戏。当我们非常兴奋地想要做这个、给我们的伙伴提供支持的时候，我们的托管解决方案对每个游戏来说并不是一个好方案（a silver bullet）。Steffen和我在过去一年里已经有所了解，因为我们跟你们和你们的工作室一直在讨论，也理解你们想要不同的服务器部署。我们知道你们在做非常有创新性的东西来接近你们的顾客、将你们的游戏体验传递给他们。

所以我们并不是告诉你们我们是怎么做的、Valve是怎么做的，我们从世界各地的开发工作室中组成了一个小组，这些工作室都在他们生命周期的不同阶段。我们有一个游戏是在一个月前以EA形式发售，在世界各地都有玩家，比如巴西、亚洲、西欧、北美。我们也有一些行业老兵，他们在云托管出现前就一直在运营在线游戏服务器了。所以我们有很多的视角，而我们也非常高兴今天早上能来这里，我们也很感激你们都能这么早就来。

我们会先进行一些介绍，然后就从第一个问题开始——『为什么你需要官方游戏服务器？为什么不让社区托管它？』

图14.1

首先就是Karl。Karl来自于瑞典的Hovde（地名），他设计和落实了Battlerite的分布式服务器构架，以及很多其它游戏的系统。最近他专注于运行和提升Stunlock（Battlerite开发商）的服务器部署。在Battlerite之前，他在Stunlock的上一个部署上应用了类似的规则。

Karl，你能告诉我为什么Stunlock觉得对最近发售这几个游戏来说，官方服务器是非常重要的呢？

Karl：

好的。Battlerite是一个在线竞技游戏，所以给每个玩家提供一个稳定和公平的游戏场地对我们而言就非常重要。我们觉得，为了保证这种体验，我们需要负责服务器，并且确保对所有人都是运作良好的，不管身处何地。

另一件同样重要的事情是，能掌握人们可以拥有的东西，这样我们在游戏中就能拥有自己的经济。以上差不多就是主要东西。

我们当然同样也考虑到了作弊这类东西。比如，如果我们不泄露我们的服务器代码，作弊难度是更高的。这也是我们做的事情之一。

图14.2

Kassidy：

谢谢Karl。然后就是Spencer。Spencer来自澳大利亚墨尔本，他是Bankroll的创始人、主程序员、以及Hurtworld的创造者。他有很多头衔，不过他首要关注的是创建紧密的多人游戏体验。在创办Bankroll之前，他为公司制作大规模数据库应用。

Spencer，在你开始致力于Hurtworld的时候，你知道需要部署官方服务器吗？为什么你不依靠这些呃，（不知道点开了什么内容）你一开始就有的2000个社区托管服务器呢？

Spencer：

在最开始开发的时候，我们需要自己的服务器。所以我们在开发期间相当早、封闭alpha测试的时候就部署了。我们需要很多的测试来基本搞清楚在服务器上的性能，CPU和RAM的要求是多少等等，这一类在这之前我们都不知道要研究的东西。现在坐在边上跟我一起的这些人，他们肯定有很多深入了解的经验。但我们是一个全新的工作室，我之前也完全没有做过游戏，所以肯定要在这个过程中搞清楚。服务器最开始某种程度上是我们的试验田，我们也准备有社区服务器，但是我们发现随着我们的发展，玩家们更喜欢的体验是他们确定有质量保证的，而我们能确认硬件配置能不落后于我们做的东西。很多的社区服务器会让它们的服务器超过能表现良好的那个点，然后说『我们想要每个服务器200个玩家』而不是『我们知道可以掌控的60个玩家』，他们也在很长的一段时间内不会wipe（差不多就是重置）他们的服务器，这样可以让社区服务器更大一些。我们可以强制一定程度的质量控制，而这对我们来说是最主要的。

图14.3

Kassidy：

然后是Steffen Heigel。Steffen和我一起在Valve工作，他今天穿过了整个华盛顿湖过来的。他在Valve的网络运营团队，负责构建和运行时间各地的游戏服务器以及和游戏团队的合作，以确保我们的玩家有最好的游戏体验。在此之前，他在动视（Activision）做了10年的相似工作，所以Steffan是我们行业里的老兵了，也出现在了这个组里。

Steffen，你能告诉我们Valve为什么要运作自己的游戏服务器吗？

Steffen：

好的。这是在我进入Valve之前，2011年的时候我们将TF2变成了f2p游戏，然后我们也有Dota 2进入了beta阶段。在TF2的案例中，我们是想要实验游戏经济。我们发现我们需要对服务器体验有更严格的控制。在Dota 2中，我们想要有一个——因为我们想要创造一个竞技性非常强的多人游戏，我们发现把控体验、让游戏能成为开发者想要的样子的最好方法就是托管我们自己的服务器并且自己运行他们。因为我们已经有相对多的运行全球网络和服务器的经验，我们觉得这是我们自己能构建的东西，所以这就是我们从此以后一直在做的东西。

图14.4

Kassidy：

好的。最后我们有请Richard Lawrence。Richard是Daybreak Games的CTO和工程部高级副总裁（SVP of Engineering）。他们只做了EverQuest、Planetside 2、H1Z1，以及很多其他的MMO和在线游戏。他之前有在EA、Digital Anvil工作，然后创办了自己的Kazmi Corportaion。Kazmi在80年代就开始制作MMO。考虑靠圣地亚哥（Daybreak所在地）的情况，这应该是从上次SDD将近三年来，Richard第一次在现实生活中看到降雨。（吐槽下雨少）（笑）

Richard，同样的问题，为什么Daybreak要运作官方游戏服务器？

Richard：

对我们来说，这有点是一个历史问题。在1999年Daybreak第一次发售EverQuest的时候，基本上这些服务都不存在，所以如果你想做的话，你就得自己做。实际上我非常嫉妒现在像Spencer这样的人，有强大的环境可以部署一个游戏服务器或是任何的在线服务器，真的。现在有多种选择、多种角度可以处理它。

我们另外的原因就是，我们的游戏基本上都倾向于只有在线体验，所以我们需要长期地保持.当你有很多持续的保持时，你就会有很大的规模，在这种环境下，你很难让单流程架构运行良好，因为它们的规模不够高，所以我们总是运营高度分布式平台。当你有一个分布式平台时，它的拓扑学就比很多人预期中的要难一些了。它会帮助你自己运行它，因为比起一般的裸机托管设施（bare-metal hosting facility），你对它性能的理解要好得多。

Kassidy：

这些开发工作室的共同点就是，他们将服务器部署作为整体游戏设计流程的一部分，而这就是我们今天请求参与的每个人很酷的地方，我想你们也会随着我们的提问——我们专门为这个专题讨论会设计的提问——慢慢了解。

图14.5

第一件我们要做的事情就是，保证我们都明白有什么是可用的。你们可以跟我们谈谈，如果你想要托管一个官方服务器，可用的各种选项、或者说选项的主要类别都是哪些吗？

Spencer：

我从最小的开始，基本上也就是我们起步的地方。你从一个游戏服务器提供商那里租了一个Minecraft服务器，我们发现需要这个初始的官方服务器成本非常低，而且他们也会为我们管理，他们利用在网络构架中、硬件要求等等的专业性，让我们不需要在最初应付它。这是最便宜的选项，但是它显然不能随着你的发展而变大规模。

至于更大的选项，这部分让他们来说。

Richard：

我会讲DIY。

Steffen：

你想讲一讲Rent-a-Server吗？

Karl：

是的，当然。Rent-a-Server就是当你得到操作系统的时候，你有对机器的root权限，你可以运行任何你想运行的东西，由你来管理服务器。你可能没有网络和发热的控制权，但是你也不需要担心这个，而你也获得了在上面运行任何东西的权限。这可以是在一个虚拟机管理程序上的虚拟机，或者你会获得裸机服务器。当然，对那些授权敏感的游戏，裸机可能是更好的选择，但是可能同样会更贵一点。

Richard：

我来稍微讲一讲DIY，然后Steffen可以进行补充。我认为，当你研究DIY的时候，你首先需要问你自己的问题是，『你真的想要做这个吗？』这是一个非常重大的付出，真的是。你通常会在1到3年的合同里，会花费很多资本，我的意思是第一次你会扔20万美元在你的

边界路由器（border router）上，而你会觉得，『喔，我真的需要也给我自己资格边界路由器吗？』还有在人身上会有很明显的花费，我的意思是技术熟练的人。我有一个非常棒的网络小组，我们做得非常出色，但是他们都是有娴熟的人，而且他们都不在游戏上面工作。也就是说，如果你真的这么做，所有你获得的东西都是最好的，因为所有东西对你来说都很有趣，而你也可以自己实施。我们有我们想要的准确的硬件配置、准确的堆栈和准确的拓扑。但是再说一次，这是一个成本上的考虑，在网络里的所有东西都是成本考虑。我们花费了很多来获得它，因为我们需要那个最优行为。但是如果你不需要这种最优行为，那么你就要注意了。你可以做得不那么完美，而仍然可以完全透明地服务你的顾客。至于优秀的体验，他们也不需要担心这个。

Steffen：

我想要补充一下，做这个的时候你所需要的团队大小。你要考虑到，如果你要全球化，那么你需要有人能和不同的运营商和数据中心管理这个业务关系，这部分也就是Kassidy花费了很多时间在做的，你也需要多个SME（subject-matter expert，领域专家），所以也要承担很多。这就是一个，需要你的游戏在生命周期的一个特定点、并且你非常确定这是你想要做的时候才该做的事情。

图14.6

Kassidy：

那么让我们从真·第一个问题开始。一旦你们下定决心——我们都听过了为什么你们决定运行自己的官方游戏服务器——，告诉我们你们考虑过的不同部署策略是哪些——就从刚刚说的有三个当中——？以及你们评估这些托管解决方案的时候，你们看重的是什么？这个根据情况会有所不同。帮我们理解当你考虑进行下阶段的Rent-a-Server或者DIY的转折点是什么。

Spencer：

最开始的时候，我之前也提到过，我们使用GSP（game server provider，游戏服务器提供商）。他们会为我们托管，我们也不需要管理任何东西。但是随着我们的发展，这个就不好用了，基本上服务器都会整晚整晚地爆炸。我们没有能管理运行所有东西的网络团队，所以我们需要快速地学习。

我们发现在IBM Software和OVH（一个专用服务器提供商）那里运行裸机是最好的选择。对我们而言最关键的一点就是要能推送更新。因为我们的开发速度很快，所以使用一个推送按钮就可以更新100多个官方服务器、而不需要整晚都在干这个就显得很重要了，玩家们也不会因此有糟糕的体验。这就包括了安全地结束服务器、踢出所有玩家、保存游戏、确保没有不一致、从Steam CDN上下载、推送更新、再尽快地将服务器上线。而使用GSP的话，我们就无法做到这个，因为他们只有一个基本什么都做不了的网页界面。所以我们就决定了使用我们自己的机器。

第二件事情就是DDoS防护。我们从来没有想到过会一直被大规模地DDoS。在第一周内，我们的服务器基本每天都会宕机——即便是在IBM Software上。而一旦我们被攻击，他们就会在未来24小时内停止提供我们的对外IP，所以在寻找新提供商的时候这就是一个很大的考虑了，他们是不是能够吸收这些攻击、我们能不能保持在线状态。

Karl：

之前我们做过两款游戏：Bloodline Champions和Dead Island: Epidemic。在这两个游戏中，我们尝试过好几个选项，比如说，我们评估过云服务器。我们的所有游戏都有非常严格的延迟要求，理想情况是30到50ms。我们发现，有些时候，比如当我们使用云服务器或是共享托管解决方案的时候，它大多时候能运转良好，但是特定的时候，比如有人在同一台机器上做数据库备份的时候，我们就无法获得足够的CPU比例来满足我们所有的期限了。 这对于玩家来说不是一个很好的体验，所以我们就不得不转向租用服务器。我们的规模没有在座的很多人那么大，所以我们没有足够的资源来部署和管理一个大型的网络基础设施。

在我们选择托管合作伙伴的时候，我们会评估的一件事情是，各个运营商、各个地方的传输和配对协议是什么样的。比如我们试过在巴西租用服务器，它有一段时间还不错，但是突然我们就从一个地方得到了很多报告说，『我们不能在这个服务器上玩，它是没用的，移除掉它吧』。因为当时我们只是租用一个裸机服务器，所以我们对网络没有控制权，我们能做的只有给提供商打电话，告诉他们这个问题。这大概就是我们决定从一个合作伙伴那里获得帮助的时候，之后我们肯定会提到的。（Kassidy笑）所以这里面有很多东西……

Kassidy：

你的合作伙伴是Valve，对吧？你们的服务器托管在了我们……，你可以继续说（笑）。

Karl：

对对，所以在Battlerite这个游戏上，我们从Valve那里获得了一些帮助，在这个服务方面。Whatever……

（观众笑）

Kassidy：

有一件有趣的事情是，我们在之前对话的时候，我记得，你说过你最初的计划只专注于西欧和北美，是因为获得其他的市场实在是太难了？

Karl：

对，没错。在西欧和北美，网络的连接性非常好。你只需要跟一个大型运营商有传输协议，就基本上可以提供给所有人了。但是在其它地区，这就变得有点困难了。你需要和很多不同的运营商有合作关系。

Steffen：

对Valve来说，我们有17个不同地区——你在Dota 2客户端看到的每一个都被看作是一个地区。我们总共有17个。我们并没有把每个游戏都部署在每个地区，因为有时候这样的意义不大，你不会想把一个地区分成太多块。对于像CS: GO这样的游戏来说，它们有相对严格的延迟要求，我们就需要让这些服务器尽可能地靠近玩家。我们有17个区域，而每个区域有至少一个簇，每个簇有160个服务器，我们尽量让它们稳定、易于管理，我记得最大的一个区域我们有8个簇。我们设置好它们、让它们运行，我们花了很多时间在自动化和开发简化工具、给我们良好可见性上。我们通过Steam客户端——Linux上的Steam Modeling客户端——推送数据，把所有东西都放到服务器上。这个方案对我们来说，这几年来都运行得很好。

当我们评估托管解决方案的时候，我们关注的不仅仅是地理上的位置，也要理解它跟我们玩家有多近，因为在一个国家里并不意味着对所有的玩家实际所在的本地ISP都有良好的连接。所以你要好好考虑这个，和本地ISP及你的数据中心之类的好好谈谈，确保他们会使用正确的你所需要的运营商。

Kassidy：

Rich（Richard），你能给我们解释一下，在什么时间点，工作室需要开始考虑『我们要租用服务器』、『我们看到了很大的增长，可能需要DIY了』？你是怎么判断的？

Richard：

这显然跟你认为长期的需求是什么有关。我是说，比如我们运行了一个混合基础设备、有永久的地点、有4个数据中心、一起合作了很久的伙伴：SwitchNAP和EQUINEX，SwitchNAP在美国，EQUINEX在欧洲。这是因为我们知道我们会在这些地方长期多年地运作，有大量的大型安装的需求。对于比较灵活的东西，比如『今天是发售日，我们需要为发售多准备几个服务器』，或者说有较少参与人数但数量还比较大的区域，我们会在那里加一些，但是不会是一家老小齐上阵（full rack）的。对于这些情况我们会用AWS（Amazon Web Services？），创建一些游戏旁例，返回到永久设施那成为永久性数据。这样我们就在本地得到计算储存和带宽资源，而永久储存、维护和操作都是在这外面（AWS外）进行处理。

这是一个成本决定的东西，你也要非常小心——我重复一下Steffen说的——成本当然总是很重要的，这是一个运营成本，也是你业务的『税』，但是你不会去选择报价最低的，对吧？除非报价最低的竞标者能满足你所有的需求，而你也对他们能高水平地为你的需求而运营有强大的信心。和这里的有些情况不一样，比如这里你可以叫上Valve说『我们在这个紧急部署上需要帮助』；当你依靠自己的时候，就只有你了，对吧？我的意思是说，我们没有任何人可以依靠，我们可能可以叫上Level 3（Level 3 Communications，通信公司），说『请帮我们』，他们会这么做因为他们是很棒的伙伴，但是这个层次完全不一样。不能请求什么服务，你能做的是提升自己的服务。

AWS就是这样一个很好的伙伴，还有很多跟它类似的伙伴可以供你（部署）混合（服务器）。他们可以提供服务、提供良好的连接性，他们是已知的因素，也有良好的持续性；同时他们也让你能够部署自己的（服务器）、构建你想要的东西。这就是我们用的混合体。

图14.7

Kassidy：

现在你们完成了发售，你们在全世界的一些地方部署了一些服务器。在发售后，为了提升用户体验，你们不得不做了哪些基础设备更改？

Karl：

我们在三周前发售了，所以我们还没有那么多时间来做改变。不过我之前也提到过有的时候运行的不是很好。在发售一周、我们成为DDoS攻击受害者之后，我们做了一件事，就是改变了我们的API服务，来让它们更能抵抗DDoS攻击。我们还没有改变太多，服务器运行的也还可以，多亏了那些人。

Richard：

顺便说一下，你要随时准备好遭受DDoS攻击。基本上只要你配置了一个服务器，它就会被DDoS。在你第一次配置服务的时候，你就应该有这样的计划了。有很多种方法可以减轻这个——如果有人想要长期用这个形式的话，我们可以稍微讲一讲。

对我们来说，谈到发售后的改变，我们在H1Z1——这是我们最近的游戏——就有了计划：我们如何在世界范围内部署、如何做区域基础设施。而当计划遇上现实时，我们需要做出改变，因为玩家们展示了他们自己的兴趣、做了他们常做的事情（应该是涌入游戏之类的吧）。我们看到了比我们预期中多得多的来自于亚洲区域的玩家，因为我们还没有准备好服务这些人、没有良好的翻译这类的东西，但是他们无论如何也要玩。所以我们就在新加坡、澳大利亚设置了基础设备——我们基本上跟随玩家的兴趣——，我们在巴西也有一个（服务器）。对于游戏来说，尽早做这些非常重要，因为不然的话，游戏体验对每个人都是不够好的——对巴西的人不够好，因为他们有很高的延迟；对跟他们一起玩的美国的人也不够好，因为他们会看到高延迟，而这表明游戏本身有波动或是有没有预料到的意外。

Spencer：

我们也在到处出现的新区域上有类似的体验。我们发现，寻找到能满足我们最初游戏版本的延迟要求的提供商很难。这个时候我们就更多地运用我们自己的力量，而不是去跟网络提供商配对什么的。我们跟专注于我们自己的网络代码应用，让我们的游戏变得更有延迟抗性。人们在200ms延迟的情况下也能游玩，而且也不会有糟糕的体验。这差不多是一种创新性的方法来解决这个问题，因为我们是个小团队。而其他的一些事情我之前也说过的：保证我们能够快速地推送更新，在服务器数量增长时保持用户数的透明度。

Kassidy：

我非常喜欢昨天晚上我们​​​​排练的时候，你谈到的你是如何搞清楚你需要做的东西是什么来让用户们开心这一部分。你能讲讲你如何处理的吗？因为我觉得你们有一些有趣的见解。

Spencer：

这是EA阶段的火之洗礼，我们每天都上Reddit，在我们发售的时候，我们几乎每个开发者都在论坛上跟人们交谈。我们的反馈就是——我们其实没有什么事先的计划，我们只是看到有什么问题就解决什么，然后防止这个问题在发生，最终我们的基础设备达到了稳定点，不会发生什么问题——而我们获得的反馈就是，当人们不再在论坛上对我们发怒的时候，就是我们知道万事顺利的时候。

Kassidy：

这就像是IT人总是用户体验后的无名英雄一样。用户停止抱怨，是你用来知道你这时做得不错的方法，很有趣。你也谈到了社区感知，你谈到了你是如何感到自己无法在游戏更新上进行太多工作的。

Spencer：

是的。因为作为一个EA阶段游戏，我们在提升基础设施上投入了很多的专注，这就给我们带来了很大的压力，导致我们无法按照预期那样致力于新内容。我们专注于保持我们的服务器在线，而不是发布补丁、新枪、新物品之类的。从社区那里我们得到了很多压力，在那段时间我们看起来什么都没做，但是我们是在提升体验质量到我们认为玩家会期待的程度。这大概花了4个月的时间，然后我们才能回到实际的内容开发中。

Kassidy：

谢谢。我来看看。Steffen，（轮到你了）。

Steffen：

在我们发售后，我们不得不投入很多时间在——我之前也提到过——靠近用户上。在北美和欧洲都非常简单，你可以选择你的数据中心的位置，然后在它周围画一个50ms或者30ms的圈，这就差不多能体现能获得良好体验的玩家的范围了。但是在别的区域，就没这么简单了。比如说在东南亚之类的，你可以将数据中心放在新加坡，或是别的一个地方，但是你需要投入很多努力，来确保这个区域里所有不同的玩家都能在跟你的托管服务器有良好的连接。对我们来说，我们有过很大的投资来构建这些关系、了解玩家来自哪里、让网络连接性良好，并且进行监视、确保大家都玩得开心。

除此之外，DDoS在当时从频繁的困扰变成了一个大问题，所以我们也开发了很多的解决方法，你懂的，都是专利的、内部使用的东西。我们尽量让自己有弹性，而不是现在还会发生，一次DDoS就让单独的游戏会话或是一个游戏服务器宕机，我们希望我们可以做得更好，确保游戏能保持运作，人们可以很快地重连、重新路由通信。我们一直在这方面努力。

Kassidy：

你（讲过了）？

Richard：

我讲过了。

图14.8

Kassidy：

抱歉。（笑）

你们已经发售了游戏，有了健康的玩家基础，那么你们决定在新地区发售时考虑的标准是什么呢？重点是在完全新的国家，甚至是新大陆。

Spencer：

我认为，我们已经发现了玩家在哪里玩游戏，然后就在这里设置服务器。实际上你没办法选择你要在哪里发售，尤其是例如Twitch驱动的销量之类的东西。用一种语言上了Twitch这辆车，然后你在很多区域都会有人玩这个游戏，这些地方你甚至都没有做本地化——想象这些玩家是如何玩游戏的，我们都没有为他们翻译。但是玩家在哪里，你就得去哪里，你没有这个奢侈的权利说，『我们要不要到这个区域、我们要不要到那个区域？』只能去人们在玩的地方。

Kassidy：

之前我们讨论的时候，你说过，Steffen，你能说说这个吗？你谈过你的顾客是怎么不根据ping来选择的。

Steffen：

对，的确是这样的，我们在这几年里看到了很多。你将服务器放到一个区域里，它应该会给所有人更好的延迟，但是人们就是不想去那里玩。他们觉得『嘿，这个能用，我不会改变的』。你会发现除了ping以外还有很多其他的标准会让他们决定去哪里玩。

他们做的决定可能是基于你给区域的名字，这可能会导致他们在或者不再这里玩。

他们可能会在其中一个区域有不良的体验——我们在用很多的VM（虚拟机），因为在这个区域获得硬件还挺难的——，而游戏体验对玩家们不是很好，他们就会去别的地方玩，这时候当我们部署了硬件——我们自己的标准配置——，即便有了更好的游戏体验也很难（让他们回来），他们仍然会想去之前玩的地方游玩。一旦玩家们有了不良的体验之后，让他们回来游戏是非常困难的。这大概就是我们得到的教训，要考虑到如何让玩家们选择游戏区域。

Kassidy：

同一个话题，有人能谈一谈割裂玩家基础的顾虑吗？它（顾虑）会怎么影响到这个（基础）？

Richard：

这个对我们非常重要。MMO和长期游戏有一个基本的原则，不要制造社交障碍。你需要尽量给玩家们想要的社交方式提供便利，而不是基于你的网络基础设施之类的东西。我们做的就是，我们尽量让玩家选择，除非它会给每个人都带来负面体验。比如作为一个H1Z1的玩家，你可以选择你想玩的区域，但是如果你的ping很糟糕，我们会告诉你『不，你不能这么做』。这个可能是一个很短暂的事情，可能你明天回来就可以了，但是现在不行。这就让我们给在美国服务器上开始玩、在这些服务器上有朋友、有社交生活的人，提供了再跟他们一起玩的机会。这是非常重要的，你的朋友圈、你认识的人或是驱使你更多地玩游戏的人。对我们来说这就是非常重要的顾虑，我们也一直试图适应它，但是你迟早也会不得不对现实的游戏性做出让步。我们不得不在H1Z1中加入——根据我们以前的经验，我们幼稚地以为人们会自行选择避开体验差的服务器，但是事实却不是这样的，他们只是（笑）『-我想在美国东部服务器玩』，『-但是ping是非常非常糟糕的』，『-不管，我就要在那里玩』——，所以我们不得不加入一个锁，告诉他们『你今天能玩，但是如果你的延迟超过了某个ms，那么你就不能玩了』。

Karl：

对我们来说，我们有一个游戏匹配系统，把你放到对你和跟你匹配到一起的玩家而言最佳的区域。当你进入Battlerite，我们会尝试测试你和我们所有地区的ping，然后基于这个进行选择。我们会跨越多个区域进行匹配，防止割裂玩家基础。因为在一个竞技游戏中，它会是……我的意思是你住在西欧的时候，你不可以跟亚洲的一个人对抗的，你会有至少300ms的延迟，而这在Bttlerite中可不是良好的体验。这就是事实，物理上就是这样的，我们需要将你跟本地匹配。我认为非常重要的是，当我们加入一个新区域的时候，它应该提升这个区域玩家的体验，而不是让体验变差。另一个要考虑的是，当你加入新区域时，至少在Battlerite中，如果玩家不能和所有人游戏，那么就很难有一个全球的排行榜。这就是我们仍然要搞清楚的东西，在他们不能互相对抗的情况下，怎么来确定谁是最厉害的玩家。

Kassidy：

昨天我们彩排的时候谈到了，『你考虑过的其他的业务上的顾虑』。有人想谈谈当你要建立新区域时出现的这类问题吗？

Steffen：

这是跟专业人士的交流。如果你决定在一个区域部署服务器，有一些管理上的顾虑可能会影响到你，确保你们已经和完全了解这个的人讨论过。

Kassidy：

尤其是你在做DIY的时候。

Steffen：

尤其是你在做DIY的时候，没错。要一直记得这个，非常重要。

图14.9

Kassidy：

我们来看看……这个是我最喜欢的问题：这些人本质上都在实行『游戏即服务』，很想听你们讲下一步要做什么？尤其是它如何会影响到你们的服务器部署？以及你们要做出哪些改变？

Steffen

其实我不是一个游戏团队里的，我在Valve是跟一群游戏团队工作。对我们来说，只需要专注基础设备就行了。今年年末，我们会部署三个新的区域，我们部署服务器的位置在芝加哥、南非和……

Kassidy：

华沙

Steffen：

还有华沙，提供给多人游戏。我们也在继续构建我们的全球骨干网络，我们有一个环绕世界的完整网络，这样我们就可以尽快地获取玩家的通信，然后将它们发送到骨干网络上，让所有人都有稳定不错的ping，并且没有丢包。

我在之前也提到过一些改变，我们提高了对DDoS、网络事件类似的抗性。目前只用在Dota客户端和服务器，我们也在跟CO:GO和TF 2团队合作，尽快将这个也应用到这些游戏上，从而获得更好的抗性，让玩家也有更好的体验。对我们来说，这部分也是近在眼前的大事。

还要提到的一点是，因为有相对较多的努力花在将服务器加入到新区域中，我们通常会稍微过度地构建性能，这样就会给我们一些富余空间。这就是为什么我们可以提供很多性能给Stunlock，因为他们的服务器构建非常高效，而我们也可以在相对较小的服务器上托管相当大数量的玩家。我们现在也在探索这个，也会尝试优先处理它。这样你们就可以给我们一份（部署）文件、图片或者别的什么东西，然后我们可以为你在全球部署它，而你们的玩家也可以跟我们玩家一样获得在我们网络上运行的好处。

这些就是我们主要的东西了，当然还有很多。

Karl：

对我们来说，游戏服务器运行得还挺好的。以基础设备为单位进行构建，可以提高我们的分析、以及一些需要更多基础设备——比如缓存层之类的东西——的新功能。我们在三周前发售的，所以你们得给我们一些时间。

Richard：

我们的目标是在不同的地区进行**。之前Steffen也间接地提到了，亚洲是一个非常困难的地区，因为没有一个解决方案，你必须看到有几个不同的区域。我们另一个目标其实是，这些人做了但是我们没做的事情，就是让我们整个服务器基础设备在每个玩家或是每次体验基础上更灵活。我们在H1Z1做的一件事情就是，白名单服务器是能直播的人可以进入并带入他们的社区的地方，有他们自己的规则，也做他们自己的事情。在游戏中这是老概念了，但是当你有非常大的分布式处理过程服务器的时候，这比简简单单加入一个设置文件要难得多。我们想要再往前走几步，让更多的控制权掌握到玩家手里。到时候我们可以看看它运行的怎么样，我们现在还在做。

Spencer：

我在这里比较特殊。我实际上也在游戏上有工作，我们做的东西会影响到我们的服务器布局。从短期来讲，我们最初会非常专注于UGC。当你需要你的服务器和客户端同步的时候，这是一个比较微妙的问题。如果你们有人听了昨天的UGC演讲，我们遇到了很多里面讲到的一样问题：在一个服务器启动的时候，它会选取一些mod，然后说『这是我的mod堆』。而这就会在客户端连接时，影响到存档的写法，它需要获取已经激活的mod的列表，这样就可以将内容像客户端运行时需要的素材或者脚本一样展现出来。（组织语言中）不好意思。对于UGC方面，创意工坊现在绝对已经是现象级的了，我们有一些版本管理的问题，但是我昨天跟Tom Buoy谈过，他说了可能很快就有版本管理了。这听起来非常棒，如果你在做什么东西并觉得它们有帮助，一定要跟Valve谈谈。我一般不拿这些问题跟他们接触，因为我觉得可能这个问题比较大，不过其实过很棒。

第二件事就是，我们服务器的最大的两个限制就是，我之前也说到过。

第一个就是，每个世界服务器的游玩账户在60个左右，香一个小型的MMO，而这个世界也在这个服务器上存在。如果你要有新的服务器，那么你就不得不为玩家创建一个全新的世界。**这个容量在目前而言只是个梦想，因为这是一件很难实施的事情，有很多我们尚未解决的挑战。但是我们可以将多个服务器连接，让玩家们在服务器之间移动、传递他们的数据。利用同一个游戏区块，在一个区域里我们可以有无穷多个玩家。基于我们的投资和我们最初的基础设施——我们会构建一个中心主服务器来管理我们所有的游戏服务器部署，可以连接到其中任何一个节点，运行一个服务器、下放一个存档。我们会从每个服务器移除所有的状态，把它们留在中心服务器。因为我们现在能做到这个了，我们就可以把这些服务器拴在一起。

另一个就是擦除（wipe）。随着服务器变得陈旧，我们发现最好的体验就是定期擦除它。但这对于在服务器里投入很多时间的玩家来说比较尴尬，他们可能刚刚几天前才开始玩，然后内容就被擦除了。最终我们认为，人们开始明白了这是运作游戏的最好方式，而我们也是在进行类似回收服务器到游戏性中的工作。服务器运转得更好了，玩家可以进去也可以出来，他们会看到火山爆发、我们就擦除服务器，然后服务器就会下线。我们试图将这样的流程加入到游戏中，到时候看看我们能不能做到。

Kassidy：

我们还有一点点时间。我觉得人们困惑的一件事就是，我们谈到官方服务器就是成本，我们能修正一下我们谈到过的内容吗？你们能不能及时一下成本的来源，是网络还是授权？

Richard：

这个取决于你的布局方案。现在有良好的环境，因为所有东西都是瞬时每秒运行的，到VM、VPS、自有裸机服务器、以及我和Steffen倾向做的DIY。成本结构在每个阶段是完全不一样的。我认为在DIY阶段的区别是，你在经常性成本上有很大的责任。你会有很多和你运行的基础设备有关的MRC（Mannul Reference Counting，手动管理内存），你也会有运行1到3年的合同，因为没有人会做按小时结算的带宽挂钩。你需要将一切都联系起来，这会是一种责任。问题的一部分就是在你这一边你想要负责付出的东西的程度。对于Steffen和我来说，这是一个多年的内容。对于短期服务器来说，这可能不是提供这类环境的最好方案，你可能需要按小时、天、通常按月租用——不过这个取决于具体情况——的裸机。

Kassidy：

授权，这个需要关心吗？我注意到你是唯一一个有Windows服务器的，而这里的其他人……

Richard：

对，我们同时运行Window和Linux。Linux是免费的，非常棒。而Windows在某些开发者喜欢的方面是功能完整的，尤其是debug。但是不要忘了这么一个事实，每台机器都有一个授权成本。你要么就在租用机器的时候付了，要么你就在裸机状态下直接付了授权费。如果你去比如他们在用的OVH，他们会有个成本说『这是机器』、『这是带Window授权的机器』、『这是带OS X授权的机器』——如果你正好需要它的话——，这是大量的成本。我是说这个数字非常大。我为Window授权签过5万美元的支票。它（Windows）功能完善，给你很多的性能，但是你需要问自己『我真的需要这个吗？』或是『我足够稳定吗？我知道我的基础设备足够好吗？如果我部署这个服务器，我想它基本上只是在做计算任务。』这样的环境下你才真的需要问『Windows还是Linux更好？』这是开发中的问题，但是也有成本附带在这个上。

Steffen：

上次我们从一个流行的云提供商那里租用了一天的VM的时候，一个实例要40美元，而这差不多可以支持同时存在的100个Dota游戏，这（成本）还可以。然后我们去做了点带宽方面的数学题，然后突然就将价格翻倍了。通过这个练习，我们很好地认识到了所有的成本在哪里。同样不要忘了这些支持人员的成本，这里面有很多隐藏的成本——之前有人谈到过了，我在这是只是为了保证你们都抓到了这一点。但相对于它给你的玩家的体验，这个成本肯定是值得的。

Kassidy：

还有吗？

Spencer：

我们发现的一个大的挑战是，当我们进入比如巴西、俄罗斯或是亚洲这些区域的时候，价格会变成你在北美所要付的2到3倍。那里也很难找到提供DDoS保护的提供商，而你也会遭到攻击，所以我们要付两倍的价格，只是为了在上面加一层DDoS保护——很多提供商会提供给你这个报价——，而当服务器宕机的时候，才发现其实他们并不能解决这个问题，然后给你退钱。

Richard：

说句公道话，我们在澳大利亚，花在带宽上的钱比在北美也要多得多。

Karl：

当你是一个游戏公司的时候，你非常的上进，试图发布一款游戏。而另一件很难的事情是，为一个服务器位置坚持三年，甚至是一年。当你不知道它会进行的如何的时候，这是一个巨大的承诺。

Steffen：

我觉得，这就是为什么提供给你灵活的选项是如此的宝贵，这是他们能提供的非常棒的东西。

另一个有时候会出现的非常重要的成本是进口税。如果你将硬件带到了一些国家，一旦你带进去了，价格就会翻倍。当你真的需要一个很大规模的时候，这部分会让人很惊讶。这是需要注意的一点。

Richad：

一个例子就是，如果你这么做了，其实你还不如购买那个地方制造或是出售的物品。比如你不想在美国买机器、把它们运到欧洲——反过来也一样——，税收的情况在两个方向都是非常丑陋的，所以你最好买来自欧洲的东西——或是买来自美国的东西。但这也意味着你需要有负责物流的人或是某个人，你可以在欧洲下订单。同样地，这时候裸机提供商就很有吸引力了，因为他们会给你一个每个月每个单位固定的价格。他们（Spencer、Karl）可能有协议，需要付的钱根据性能而不同，从40到70美元每段时间每台机器。而这是一个完全可以确定的价格，『它会花掉我多少钱』然后就没有别的了。由于DIY的天性，Steffen和我面对的是更加可变的成本，某个阶段，可能你的性能会受到你的路由设备的限制，那么你需要买新路由，而这对于一个数据、企业级数据路由来说是非常昂贵的提案。

Kassidy：

这就是我们今天的内容了。我想要感谢所有到来的人。我们四个五个人在SDD接下来时间都会在这里。哦，除了Rich（Richard），他要逃离这场雨。我们也会在今天晚上的活动力，我们希望，尽管来跟我们交流你的情况，以及我们是否可以一起解决的方法。期待和你们的合作。

Richard：

我们不能给你们准确的成本，我们可以给你一个相对成本。（笑）你问准确成本的时候，律师就要介入进来了。我之后会在这里，别人也会在这里。只要问我们问题就行。

Kassidy：

谢谢大家。

（观众掌声）