《星际公民》每周ATV Performance and Optimizatio

发条钢笔

-UI小组几乎完全重写了头盔显示的飞船状态全息影像，他们使用了渲染小组开发的RTT（Render to Texture，画中画）技术，现在该影像将会真实反映游戏内的物体，这意味着它将真实地反映出目标当前的状态，包括部件的完整程度。3.1中你将可以在座舱的MFD（多功能显示器）上选择显示。



-小组使用同样的RTT技术来渲染视频通讯，你将可以在头盔显示屏、MobiGlass和MFD上显示它们。
图2

-当你在观察飞船状态全息影像的时候，你将可以手动设置观察角度。
图3

-3.1中你将可以向仪表盘上连接辅助的显示屏（比如头盔显示器），你可以自由地选择哪个显示屏显示什么内容（武器、飞船状态图、能量分配等）

-行星技术进一步创新，小组使其支持了多通道渲染并增强了颜色混合/分离表现水平，同时保持性能与现在的行星技术一致。拜其所赐，在3.1中从地表到宇宙的过渡会更加平滑，这些新技术主要可见于Yela。

-改进了现有的工具以便重新放置所有地表前哨基地。


-美工小组正在完善truckstop的外观。
-内部过程型布局工具已经成功地生成了一千多种成功的布局（并不是这一千种都要用，只是要表明这不会让玩家感觉到重复）
图10


-Anvil Terrapin 水龟、MISC Razor 剃刀、Tumbril Cyclone 飓风小车和Aegis Reclaimer 回收者都已经接近Flight Ready阶段，小组正在为其添加VFX特技。


-武器小组重新制作了下列武器的命中冲击效果:Gemini R97、PRAR 扭曲散射炮、Scourge电磁炮。


-将Star Marine的自定义装备界面与MobiGlass所使用的的代码库统一起来，不仅不需要两头更新修BUG，还可以单独选择部位的装备了，以后的任何对于自定义装备的更新和优化，两边都能立刻感受到。


-UI小组努力提升Mobiglass的视觉效果，其中一个改变就是使得MobiGlass的界面占据更大的屏幕面积以提升可读性，还有就是提升3D渲染质量，玩家们将会在例如装备管理APP中看到非常明显的视觉提升。

-技术美工小组为玩家角色自定义系统添加了一套新的循环动作，更多的随机面部表情，所有的选项都有了一个WIP(Work-In-Progress)图标，还有BUG修复、镜头调整、光效调整等诸多润色细节。


-3.1将推出服务信标，这将允许玩家之间通过服务（比如运输、战斗协助）获得金钱，当合同被接受，你就可以看到合同发布者的信标，这时你就可以QT过去。目前BUG还有不少，细节还需要润色。


-小组还解决了不少BUG，例如头盔灯光无法正确显示和允许玩家同时戴头盔和帽子等。


----优化----

-目前优化最大最严峻的问题是，像星际公民这样的游戏，其中的实体（entity）实在是太多了。

-游戏的模拟主要依靠输入、游戏世界的状态和世界渲染的这样一种循环来持续。其中对于性能影响最大的是世界更新和渲染阶段，每一个步骤都有固定需要完成的操作数量。如果这一整套流程可以在1/60秒内完成，那么世界一秒就会更新60次，即60FPS。


-如果对CPU、GPU采用如下方式分工，可以看出这非常没有效率，因为同一时间只有一个芯片在运算。


-我们可以用如下的流水线方式提升工作效率，即让GPU渲染一帧的同时，让CPU进行下一帧的模拟。该种方式在计算机各个方面都有所运用。


-但是这种流水线方式依然存在问题，如果CPU处理的速度大于GPU，那么GPU就会不断地被落下，导致额外的延迟。并且，我们需要把CPU所模拟的数据存放在内存中以使GPU处理，但任何设备的容量都是有限的，我们不能让CPU无限地领先下去，因此需要在一定时间停下CPU来让GPU赶上来。

-对于星际公民，我们仅允许GPU落后一帧。同样的情况也会反过来出现，即CPU运算太慢，GPU经常没有内容处理，这被叫做饥饿。因此，优化游戏的第一步就是查明到底是哪个快哪个慢，如果出现饥饿，那你再怎么优化GPU都没有用。


-同样复杂的情况也会出现在多核的CPU中，现在每个CPU都有着多个处理单元，我们叫他HardwareTread（硬件线程）。显然使用与CPU、GPU相同的流水线方式会更有效率。但其有一些难以克服的问题比如工作量平衡性，我们知道整个CPU将会受到运行最慢的那个单元的制约，就需要平均分配任务量，但这意味着需要找出一块一块的逻辑相同的需要处理的工作，这在星际公民中几乎是不可能实现的，更别提不同的CPU核心数量还不一样的问题。因此我们选择的方法是借助了电子游戏平衡性的批量更新。举个例子，在星际公民中很少会出现只需要更新一个角色的情况，因此我们可以把每个角色放到不同的CPU核心上，同样的方法应用于所有游戏中的实体。

-这种方法允许我们依据核心数量更加灵活地倍增处理速度。我们目前正在将所有游戏逻辑都应用于此种方法中，这将允许更高的核心使用率并优化整体性能。

-星际公民的服务器端以30FPS每秒的速率发送数据给客户端，而客户端以60FPS的速率运行，这中间缺少的30FPS将由客户端自己进行补偿，因为客户端自己也在模拟整个世界，服务端的两帧之间的那一帧则由先前那一帧预测得到（已知飞船速度、方向，则可以大致预测下一1/60秒后飞船的位置而不会出现太大偏差），再经由服务器后一帧的纠正，这就允许了服务器端和客户端以不同的帧数运行。

-优化可以不仅仅从增加算力来考虑，还可以从减少需要计算的物体来考虑，比如减少实体可视化的距离来减少需要追踪的物体的数量。这主要是通过多种方法结合来通过良好的资源管理提高优化水平，任何小的细节都不能放过。

-技术美工和技术内容小组主要通过使用LOD技术来降低draw call（绘制调用，就是把物体渲染完成），LOD都是手动制作，通过远近来调整多边形数量以优化图形性能。另外需要注意，你需要对每一个独立的mesh（网格模型）来调用绘制调用。因此对于飞船上的活动部件，艺术师们都采用skinning技术，将其与整个飞船融合为一个大的网格模型，这样，本来10个物体每个需要10次的绘制调用，现在则只需要调用1x10次绘制调用就能完成。

-飞船爆炸特效正在重新制作，减少四散的碎片以减少需要的draw call。另外还有一个小技巧就是可视区域筛选和传送门筛选，比如说毛虫之前遇到的BUG，就是因为传送门筛选没有做好导致。主要的意思就是，你在飞船外的时候不需要看到飞船内部，你在门外时也不需要看到门内的东西，你往前看的时候也不一定需要看到背后所有的东西，通过特殊的筛选方法来决定哪些需要渲染哪些不需要渲染，这样就能进一步减少系统开销。

-还有一方面的改进则是从使用体素(Voxel)来划分本地物理网格到Signed Distance Fields技术的转换。SDF更加精确，并且其划定的形状更加高清，允许飞船的护盾更加贴合飞船的外形。同时SDF也是使得残骸可探索化的第一步，通过使用SDF技术，飞船断成几截的残骸将保留原有的物理网格，允许了EVA探索残骸的行为。

-网络代码曾经是一个非常大的性能瓶颈，因为当时的主线程会受到网络线程的牵制（不停地发送所有数据给所有人）而延迟，导致超低的FPS。但是在过去的ATV中提到的Serialized Variables（序列化变量）技术和Remote Methods（远程方法）的应用使得3.0的网络代码部分不再是瓶颈。网络指令在单个网络线程上的过载现在已经被平行分配到多个线程上了。

-需要注意的是，网络代码在客户端从来都不是一个问题，因为客户端只需要接受并运算即可，而其发送给服务端的数据相比之下要小得多，并不会造成性能问题。
-而预计在3.2加入的Bind Culling（绑定筛选）旨在解决这种客户端-服务端不匹配现象。该特性的意思是，服务器将不会发送任何你不需要看到的物体的数据给你，例如你无法看到离你几百公里外的一艘飞船，则服务器就根本不会发送这艘飞船的数据客户端，即那艘飞船在客户端并不存在。CIG的网络工程师们都非常想把该特性加入游戏中，但这并不是什么容易的事。

-现在还有一些问题，假设现在已经加入了Network Bind Culling，你看不到的飞船都并不在本地世界中存在，则当你飞往另一个区域并遭遇其他飞船时会发生什么？服务器自然需要向你发送那些飞船的数据，而客户端则必须生成这些飞船（之前不存在）。一直到现在，所有物体的生成都是同步的，这意味着主线程会停下所有工作，进行生成飞船的所有操作（加载飞船模型、数据、进行物理计算等）然后继续之前的工作，而这将造成严重的顿卡。
-因此，星际公民现在需要一种非同步的物体生成机制--Object Container Streaming（对象容器流式传输），即利用后台线程执行生成动作，当所有的加载工作结束后，调用主线程完成收尾工作即可，这样就能避免加载卡顿的现象。可以说对象容器流式传输是完成网络绑定筛选的前提条件。

-不过，开发者们需要先把Netcode bind culling完成以便排查致命错误（在Roadmap里对象流式传输是在3.3而网络绑定筛选是在3.2），毕竟同步数据这种事一点BUG也不能有（比如如何解决让任务指向一个在本地世界不存在的玩家位置的）。

-预期的绑定筛选所带来的性能提升其实大部分都经由Serialized Variable Culling（序列化变量筛选）实现了，其主要功能实际上就是告诉服务器不要为玩家一定范围外的物体向客户端发送更新信息，现版本已经加入该特性。


-当你设计像星际公民这样规模的游戏的时候，由于复杂度的不断提升，越到后面优化就变得越难。
-另外开发人员偶尔还会遇到人手不够的问题，无法向服务器施加足够的压力进行压力测试。

-随着3.1的推出，他们将会启动两种新工具来大量收集数据，来决定还有哪些方面需要继续优化，还有哪些方面仍然影响性能。需要知道，指挥五十个人来进行测试是十分困难的，QA人手不够，大部分工程师都很忙。因此开发人员搞了一种机器人，他们随机进行各种操作来模拟玩家行为，他们可以跑下床，开飞船到处飞等等。这使得开发人员能快速填满服务器并得到较为精确的服务器负载信息。

-其次，他们设计了一种能更精确捕捉数据的工具，该工具可以精确地提供关于玩家正在做的事的详细信息，而不是获取以前需要梳理数据日志才能获得的内容。

-当新的功能上线时，通常都会带来性能上的下降，但有了这些新工具开发人员们就可以快速地定位问题并将性能重新拉回玩家们能接受的水平并进一步优化。

-如果CIG像一家普通游戏公司一样，好几个月不做一个可以测试的build埋头开发，然后几个月优化一次游戏，那么制作过程必然会有很大不同。但因为CIG已经选择了这条路，那么为了让每一个build都可玩，开发人员不得不面临一些更复杂的挑战。

-并没有一个解决所有问题的方案，有的只是成千上万种可能可以小幅增加性能和稳定性的方法。