本周ATV_攻破网络优化瓶颈

发条钢笔

Around the Verse _ Serialized Variables

-
本期主持 Erin Roberts和Chris Roberts兄弟组合



--------LA Studio Update---------
-
从上个月到现在，LA工作室一直在为3.0和42中队（？）的诸多内容做收尾工作

-----Lore小组(背景/剧情/历史写手小组)
-
随着Item 2.0系统上线，他们已经为3.0编写出大量急需的物件描述
从冷却器、护盾生成器到量子引擎

-
他们还负责NPC语音内容的制作，现在已经为NPC编写并录制了2800条对话

说到大量的对话和文本，追踪并记录这所有的内容就成了一大难题
小组为此已经完成了第一版的PU角色跟踪表单
该表单提供了所有素材/内容的文件名、位置、对应的语音/面部捕捉等
完成之后将对以后新NPC和新任务的添加起到非常棒的推进作用


-
另外小组还在对所有的场景进行审视
撰写文档，整理所有可以增加环境沉浸感的小细节，包括小道具、标示、品牌等


-----货物系统
-
为了保证飞船技术上已经准备好使用货物系统
工程师们已经完成为飞船添加可视货物网格，提供更好的视觉反馈


你拥有的货物将会以“箱”的形式放置，能放多少箱则由你飞船的网格大小决定
*你可以把载具/其他零散的物品放入货仓，但这将减少你的可用货物网格容量


-
关于货物系统的代码，已经几乎完成
所以很快我们就可以开始随心所欲收垃圾了

-----工程小组
-
小组完成了将恒星系内容（对象容器）改为层级系统的工作

意思是卫星上的前哨基地、星球包括太空站都处在正确的天体网格之中
举个例子Grim Hex现在将处在卫星Yela的网格范围之内


-
说到万能的对象容器
小组刚刚完成添加急需的对象容器编辑功能

当设计者制作游戏关卡/地图的时候，都会使用素材+对象容器的形式
一开始的时候，对象容器只能在一个特定的对象容器编辑场所进行编辑
然后还要保存并导出才能在其他地方使用

现在小组允许了设计者在当前地图内对对象容器直接进行编辑
这就大大减少了设计者制作内容的时间

-
作为游戏开发者，目标自然是所有内容只制作一遍并且一遍就做到完美
但是现实总是残酷的，BUG总是会有的
所以小组总是致力于减少BUG的发现阶段的耗时
解决代码问题最难的步骤就是找到具体是什么/在哪里触发了BUG

于是随着新的系统的上线，小组重新制作了载具内部损伤状态的处理过程
因此载具内部损伤状态将极易切换/除虫


-
小组将IFCS(Intelligent Flight Control System)的更新过程转换成了批次更新
因为IFCS与物理引擎并没有什么太大关系
[IFCS仅仅从物理引擎读取一些必要信息（如速度、质量）并输出一系列输入]
所以其并没有必要与物理引擎同步更新步调

这突破了了物理线程的主要瓶颈，也许可以增加同时在线人数也说不定哦？

-
小组完成了量子航行 2.0
移除了大部分特效代码，并将其转移到飞船本身上
量子航行的代码现在只负责控制飞行过程，仅关注航行终点

这降低了代码的复杂程度，理论上将使整个过程更加流畅

目前在做除虫，同时添加一些其他功能
比如在量子旅行中关闭所有门窗（哈哈）

UI小组也可以开始他们关于如何正确表现该过程的细节讨论和具体UI的制作了
还有其他一些小功能比如--星图(Star Map)


------飞船小组
-
RSI Aurora（极光）通过了最终艺术审视过程
小组制作了多达14种涂装供设计者们使用


-
Anvil Terrapin(水龟)即将完成其灰盒阶段，即将进入最终艺术阶段
内部，目前正在完善驾驶舱的几何细节和生活间


-
另外，飞船的部件正在经历一次大更新--Item 2.0
正直这个时间点，RSI官网将进行一次全面的飞船数据重制
将更好地反映飞船的各个技术特点

该过程在你读本文的时候也在继续之中


------技术技术小组
-
小组目前的主要任务就是性能优化
他们努力寻找并确认需要优化的内容并提供优化修正，竭尽全力提升性能

其中他们使用一项叫Statoscope的软件
它可以根据数据，以逐帧绘图
它可以记录FPS、资源调用、每帧使用了多少次draw call(绘制调用)等等

这对寻找优化方案来说是非常有效且高效的


-
小组优化了动画动作保存格式
使用Maya读取场景的时候，使用以前的格式最多可能一次读取就需要15分钟
但是使用了优化的格式，这个数值被缩减了82%
节省了大量无用时间

-
女性角色转移网格模型完成，男性的也被更新
这些网格模型与皮肤制作工具一起，自动为新角色进行基础皮肤绘制


-
小组还解决了一个关于眼睑顶点造成的贴图问题
现在角色可以安心睡觉了


------角色小组
-
小组制作了数不清的新服饰

-
一个女性角色完成了游戏内素材制作，接下来需要上贴图


-
OMC内衬衣完成了游戏可用模型制作，同样需要上贴图


-
小组还负责制作一些特殊的Levski NPC服饰，例如平民和矿工
这些目前正在制作对应的贴图


-
小组重制了一些老素材--UEE和海盗盔甲，将其应用于新的模块化盔甲系统


-
3.0将开放一批发型供选


-
男性海军BDU(Battle Dress Uniform)
男性甲板EVA盔甲
女性轻甲和女性探索者飞行装

都已实装完成


-----------END-----------

-----Behind the Scene : Serialized Variables-----
本次由Clive Johnson（首席网络程序员）给大家详细介绍


-
序列化变量并不是那些你能在游戏里看到的东西
但需要知道它到底是怎么工作的，我们就必须先谈谈如何架构公民的网络连接

-
第一次我问我自己这个问题的时候是我刚加入CIG不久
我想我当时的第一反应就是单纯的恐惧
流泪、惊慌失措

当面对不可能解决的问题的时候，你还是得像一个工程师那样
把不可能解决的问题分解成更小的不可能解决的问题

-
当考虑如何制作/架构公民的整个网络的时候，第一个问题就是谁来做
星际公民本身由成千上万的元素构成
有些是可见的，比如行星、飞船、咖啡杯等
其他那些是你看不见的，比如逻辑、任务等

每个这些元素都是一个不同的实体(Entity)

每一种可能在一次游戏中要用到上千次
每一个实体都由特定的代码实现对应的功能，并且单人和多人下都要能使用

意思就是，大部分都需要在多人联网的情况下可用，也就是需要netcode
-
那么问题来了，谁来做？
CIG一共大概有60个工程师，其中只有6个是网络程序员

其中一半（3个）在Austin做后端维护，这包括许多核心功能如
匹配、好友、玩家认证等

另外一半则在UK，(我们)主要负责客户端和服务器之间的通讯
所以这个任务就落在了我们身上

-
有大概60个在狂写新元素，然后我们只有3个人在把它们netcoded
我们可能必须要以20倍的速度写代码才能赶得上制作的速度

这显然是不可能的，我们很棒，但没到那种地步（代码之神）

-
我们需要做的，就是要使其他工程师每个人制作的东西，都能工作在多人下

问题是网络编程真的真的很难
可能需要好几年的时间来学习所有的细枝末节

因此我们需要一个方法来简化这个过程
一个方法，使得所有非专业人士在几个小时内就可以知道需要做什么

为了实现这个，我们需要API(Application Programmer Interface)
它可以降低编程者所需的知识水平，同时还能完成任务


它让编程者表达想达到的目标的同时还不需要编程者具体说明如何完成这些动作

你可以把它想象成开车
你有方向盘、踏板、小控制按钮和换档杆，你控制这些来开车
但这不是车如何运作的，你只是告诉车应该做什么

同时车还会有一些警报装置，用于提醒司机是否做错了一些操作

我们制作的API也会有这些，它将会主动地提醒编程者一些已知错误
-
另外，无人驾驶系统也在研发之中，这代表着以后开车所需要的水平进一步降低
你只需要说：我想去XXX 就行了

这也是我们API的终极目标，但现在显然不可能

-
序列化变量是API重要的一环
通过给予程序员一个简单的模型
他们可以快速并安全地把他们目前制作的元素“网络化”

同时我们这些网络程序员就有时间去测试并确保该API不仅快速且正确地网络化
它还能尽可能多地解决网络化时会出现的问题

-
在我们继续这个话题的之前，我想我需要阐述一下多人网络游戏究竟如何运作

如果你按程序员的眼光看游戏的话
你会看到所有的东西实际上都是一大堆的表和一大堆的值


游戏内的每一个实体都有其自己的表
表中的每一个值都对应一个属性
因为我们需要知道每个值对应什么，我们需要给这些值起名字

所以表就有两列 左边是变量名而右边是值
每一行都是一个变量，因为它可以改变

比如飞船就可能有护盾值、燃油量等

-
大部分的实体都有一个变量叫Position
它告诉我们这个实体到底在宇宙的哪

然后虽然宇宙是三维的，也就是有xyz三个值
但是我们趋向于使用一个Position包含三个值
因为一个发生变化，其他两个也几乎必然发生变化

-
程序员可以写一些代码，这些代码可以调用这些表里的值
然后进行一些计算或是别的操作，得到一些结果

这些改变的结果就可以触发一些别的东西，比如给AI输入信号
或是触发粒子效果等

-
多人游戏下这如何运作？
我们需要一台主机作服务器使用，并使所有变化发生在其内
然后服务器就需要发送这些改变的表，给所有连接到其上的客户端
就像一个群发消息一样


如果这个工作运行正确，那么客户端和服务器都会有相同的表
那么客户端和服务器都将处于完美的同步之中

问题是
实体的表可能有数十个甚至上百个变量在内，其中的大部分都需要同步

-
有几种办法来完成：
首先是最直观的办法，把所有内容每时每刻都发给客户端
这对于小规模实体来说十分可行，效果出色

但是随着实体数量激增，你的带宽就不够了


然后我们发现，很多实体在不被操作的时候是不需要同步的
于是另一个方法，我们不发送实体表，除非它发生了变化
但是这就需要游戏代码持续地追踪哪些发生了改变哪些没有
这也非常难做对，这是非常手工的活
如果出现问题，就会导致有一些实体没有被同步，这将导致一系列问题
然后为了找到这些问题，就需要巨量的测试


另外我们并没有实际上解决带宽问题
随着服务器玩家数量上升，这意味着越来越多的实体表需要更新
越来越多的信息需要发送，带宽可能再一次不够

我们还需要继续缩减
于是我们又发现一个实体表发生变化的时候，并不是所有量都被改变了

这意味着如果可以的话，我们把表中被改变的值提取出来发送
这就进一步节省了带宽

如果我们把极可能改变的变量放在一起，放在同一个区块里
我们就能进一步节省带宽
但同时游戏代码就不仅要检查是否有值改变，还要检查各个区块
这更加难以做对

难上加难的是，不同的实体有不同的变量，上述步骤对于每一个实体都要来一次

随着公民内容的指数增长，这个计划实在是无法实现，我们只能放弃这个办法

-
然后就想到了无人驾驶汽车
我们希望制作一个工具，对于游戏程序员来说就像开无人汽车一样
但对我们（网络程序员）来说就像开宇宙穿梭机一样复杂的东西
接着我们想到了“序列化变量”这个点子

游戏程序员就可以按照他们以往那样写代码，添加变量
他们唯一需要额外做的就是用特殊方法标记那些他们想“网络化”的变量

这样他们甚至可以大量缩减代码量，节省大笔时间


之前他们需要为每个类编写特别的函数来实现这些功能
现在，这些所有的变量都受Serialized Variable系统控制，无需编写特别的函数

-
当这些变量被标记之后，就没有必要再设置区块
API可以自动检测变量的改变并告知netcode
它甚至可以为其自动编写处理序列化的代码

这不仅节省时间，还免去了人为错误的可能
-
目前我们仅仅发送所有改变了的值，所以网络"信息传输"优化已经几乎到达极限
以后如果还能优化，可能就是信息传输流的优化了


-
这就像我之前说的，通过API，成功分离了游戏代码和网络代码
我们可以做出改变而不影响游戏代码

-
当我们测试这个新技术的时候，我们发现一个实体类型传输信息的量减少了80%
一开始我们甚至都不敢相信，我们回头检查了所有内容
最后发现是这项新技术带来的成果

-
序列化变量不仅仅可以用于服务器-客户端传输
它还可以把这些数据存储到数据库中，或者文件里
这意味着，游戏程序员可以毫不费力地
使用相同的技术来做PU持续性，甚至用于42中队的存档

-
个人而言，我认为序列化变量最棒的地方在于这是我们的一个里程碑

就算现在，我们都需要多个服务器分担压力，服务器之间都需要进行通讯同步
如果多个服务器同时负责一个事物，那又会出很多很多问题

比如AI系统，你不可能允许几个服务器都向AI发送指令

为了解决这个问题，我们使用了Token来标记一台电脑
只有这台可以向客户端发送更新信息
当这台电脑完成了操作，Token就会移动到下一台需要它的电脑上

把序列化变量和token连接在一起，我们就可以把权限在各个服务器间快速传输

-
序列化变量不仅是当前科技的主要组成部分之一，它还是未来科技的基石
你能在游戏里看到的东西永远只是冰山一角
是由庞大的系统和先进科技一同支撑起来的

-------END--------