技术讲座启动时间1分到8秒 源代码讲解《白猫计划》优化技术

编辑:小蜂 发布时间:

深入到源代码级别讲解了《白猫计划》开发过程中所面临的问题及解决方法

  COLOPL是一家技术实力很优秀的公司,其《白猫计划》在安装包体积、分步载入的时间控制、动作操控的流畅上都给人留下了深刻的印象。在国内一般技术好的公司都会把自己的技术力量深藏不露,但日本企业并非如此。在先于UNITE 2015 BEIJING之前举行的UNITE 2015 TOKYO上,COLOPL派出自家的技术人员,深入到源代码级别讲解了《白猫计划》开发过程中所面临的问题及解决方法。龙虎豹感觉这会对国内的开发者有用,故整理编译如下,图上日本媒体电击ONLINE的水印还请无视。

▲演讲题目是“白猫计划的内情!~性能调整与即时通信的详情~”

 

启动时间从1分钟到8秒的优化能力

▲最初登台的是COLOPL的Kuma the Bear开发本部·技术开发团队经理池田洋一

  《白猫计划》最大支持4人联机,在2014年7月推出时是挑战当时智能手机游戏界限的产品。但这样一款产品在在原型创作时,开发人员数量和其他计划一样只有2、3人;1个月后增加到10-13人来做α版,持续了4个月;最后β版增加到15-18人,又持续了4个月,总计开发时间约9-10个月。

  令人感兴趣的是,本作的β版向全公司员工发布并征集意见,这个征集意见不光是员工之间,包括员工的家人、朋友,甚至他们读小学高年级的孩子们都参与进来,收到了“不知道该怎么玩”的反馈,于是重新审视并重做了新手教程,这被称为作品的“孩子评测”。《白猫计划》的崩溃修复、Fragment Shader的修正、加快启动时间、缩短载入时间等后来成品中比较彰显技术实力的优化,就是在这样的玩家测试过程中不断发现并着手解决的。

  其中被提到最多的就是缓存的使用,缓存是为了实现快速读取而临时保存的数据。比如在战斗中,攻击命中敌人时弹出伤害的数字,这里如果没有对缓存做优化,数字叠得多了就有可能发生处理跟不上的问题。

 

 

  ▲如上面二图所示,处理负担最高的地方在于伤害数字的生成,下图是COLOPL的解决方法,通过“CachedObjectManager”(龙虎豹不清楚这是一个函数、类还是命令)预定义好缓存的对象和数量,在发生打击命中时,直接调用缓存来放出伤害数字。

 

 

  ▲游戏中的效果音会反复调用一些音频片段,比如打击时的“啪啪啪啪”(龙虎豹是在很正经的说技术问题,想歪了的都自己面壁去)就会重复连续读取,所以也使用了缓存。但是为了避免那些播出可能性较低,甚至是只是用一次就不再用到的音频片段占据缓存,COLOPL使用了一个if判断式,用“cachedClips.Add(audio, clip);”这样一个函数让音频片段在首次被用到时才会被存入缓存里。

  COLOPL倒也不回避自己做不到的地方,战斗效果就没能做到缓存中。而且比较奇怪的是,视终端不同,有时候地图处理比战斗还费事,曾经有过地图画面处理失败的问题,因此减轻GPU负担而做的优化直到发布后也一直在持续着。

 

▲这就是地图画面,谁能想到它给GPU造成的负担却比3D战斗场景还大。

 

  ▲调查之后,发现问题是背景中海面阴影的波浪与闪烁效果造成了处理能力不足。这张画面面积很大,而且需要最先描绘,于是早早就形成了处理瓶颈。

 

 

 

  ▲原本波浪的表现使用Fragment Shader计算完成的,但其实并没有非得用这种方法的理由,于是改用了Vertex Shader,改成了第三张图中的算法。

 

  ▲进一步指定条件,将计算程序不必要色彩的Shader全都换掉。COLOPL的变换分4部,1是找出有色彩属性的Shader;2是找出将色彩与Fragment Shader做乘法计算的地方;3将颜色值保持在初期不变;4是不做动画。从Unity的素材下载服务“Asset Store”中买到的Shader中,有不少是为了PC的动作预设的、不符合手机需求的东西,对这些东西进行调整是很有必要的。

  在启动时间这一块,iOS版玩了一定时间之后启动就会变得缓慢。比如Android版要25秒、iOS则达到2倍以上的1分钟之多。其原因在于,为了应对服务器需求、减少安装包大小而使用的“AssetBundle”(素材捆绑)技术。

  在日本的智能手机应用商店中,Android不把包做到50MB以下不许发布、iOS不做到100MB以下不允许使用3G/LTE(4G)下载。为了超越这些限制实现丰富的表现力,日本的游戏总是得做成先下一个小包,初次进入游戏后再追加下载的方式,此时使用的就是“AssetBundle”技术。

  调查这个问题时《白猫计划》中的AssetBundle约有3万个种类。随着游戏进行,使用的AssetBundle越来越多,进行缓存所需的时间(“Caching.ready”项目到达准备状态)也变得非常缓慢。标题画面也使用了AssetBundle,也得等待这个流程,所以显得启动很慢。

 

  ▲COLOPL改进的目标是,1是不再等待Caching.ready;2是不使用www.LoadFromCacheOrDownload;3是对AssetBundle进行版本管理。

 

  ▲具体手段是,1启动时下载AssetVersion中的列表;2将其与PlayerPrefs中保存的Version进行比较;3只下载更新了的内容;4写入存储器;5更新PlayerPrefs中的版本,用了这样一个独立的缓存建立系统之后,启动时间被一下缩短到了8秒钟。

 

  ▲具体实现如上图,导入以“Path, VersionNumber”的形式对各AssetBundle进行管理的“AssetVersionList”,图中文件名右侧标出的.1.2等数字就是版本名。

 

  ▲AssetBundle和AssetVersionList二者一体,从原数据构建AssetBundle时,通过AssetVersionList搜索路径,并将AssetVersionList中的版本数字也一并更新,然后将两者一齐上传到服务器上。

  问题到这里还没有完,在iOS的AssetBundle中,文件的读取数量受到限制也造成了麻烦。《白猫计划》的过场中需要下载大量的AssetBundle,比如开场动画看似是在一张画卷上文字流过,但实际上是下载了大量的AssetBundle。

 

  ▲但此时iOS同时打开的文件上限只有256个,就造成大量AssetBundle无法读取而丢失。COLOPL通过在代码中添加List<string>和Dictionary<string>的命令进行试验,确定了256这个上限值,但这一问题只在iPhone上出现,具体原因很难找出,于是读取时采取了单个文件顺序处理,随时关闭的方式。

 

杂兵动作不同步的多人联机游戏

▲后半部进行演讲的是Kuma the Bear开发本部服务器工程师广本洋一。

  《白猫计划》是日本手机游戏中同时多人游戏的先行者,广本解说了其服务器如何同步附属台手机的数据。

 

  ▲《白猫计划》的系统构成,使用了Amazon WebServices(AWS)搭建服务器。玩家手机请求的数据通过LoadBalancer(负载分散装置),送到AWS上,从缓存服务器和数据库服务器中取出。多人同时游戏时,则使用了WebSocketServer。

 

  ▲白猫的联机是房间式,主机玩家建房间,客座玩家进入房间游戏。主机玩家持有练级必需的主数据,客座玩家除自身的位置和动作、动作结果以外,其他数据都从主机玩家那里获取。至于杂兵的动作则不同步,不同玩家可能看到他们跑到不同地方,但伤害是各终端各自计算后再经同步,所以就有可能出现追一个没人追的怪但它的血越来越少最后还没打到就自己死了的情况。

 

  ▲具体的步骤是主机A向客座B发送数据,1送数据到WebSocketServer中;2服务器将数据送给B;3玩家B向服务器返回已收到确认;4服务器将确认转给主机A,其后保持这样的循环。服务器会定期向玩家发送ping命令,ping不通的玩家会被认为已断线。


  第一部分分享《白猫计划》在程序优化上的思路和方法是希望对于国内引进日本游戏时必不可少的代码优化有借鉴和参考意义,毕竟其技术上水平玩过的人都感同身受。

  至于其联机方法在国内看上去或许有点简陋,市场规模和行业发展轨迹决定了日本开发者在即时联网的能力上确实并不如国内。但正所谓理不偏笑不来,白猫联机打杂兵时队友乱跑怪物自动掉血的事反而成了玩家间津津乐道的话题。国内当前尚没有太多自研的同时联机手游产品,白猫的先行尝试或许是一个提醒——手机上的联机就算不那么精准也可以被玩家接受。

《魔灵召唤》十周年:结缘游戏,共创美好人生

2024年,迎来了《魔灵召唤》10周年纪念,这款游戏自2014年首次上线以来,在无数玩家心中留下了深刻的印记。然而,这款游戏不仅仅是一款娱乐产品,它还成为了许多玩家建立深厚感情的见证者。在这个特别的十周年里,让我们一起来倾听那些因《魔灵召唤》而结缘的夫妻们的美好回忆。.