Made with Unity |《碧蓝航线》联合开发商最新力作，《深空之眼》在技术上如何更进一步

由勇仕网络开发的二次元动作手游《深空之眼》，今日已经正式公测啦！

说起勇仕网络大家一定都不陌生，作为曾火遍海内外《碧蓝航线》的开发商之一，他们对二次元游戏有着丰富的经验。作为《碧蓝航线》后的又一二次元力作，《深空之眼》也不负众望地拿下了App Store Today推荐。

今日，Unity就邀请到了《深空之眼》的主创团队，跟大家聊聊这款游戏的创作幕后吧。

《深空之眼》是一款小队同屏3D动作手游，我们的特点，在于战斗时能同时有三名队员在场，彼此搭配与配合，在复杂多变的战斗中形成多样的玩法与战斗节奏。玩家将在游戏中化身“深空之眼”组织的管理员，与修正者小队并肩作战，清除视骸，守护文明秩序。

我们这些人都有自己热爱的游戏类型，其中大半都是ARPG的爱好者。自入行起，大家始终期待着有朝一日可以拥有制作自己动作游戏的机会。所以制作《深空之眼》的想法也就顺理成章的在我们当中萌芽。亲手制作一款好玩的ARPG，算是给我们的游戏制作生涯圆一次梦。

作为玩家，一直以来我们都认为ARPG这个品类，好看，好玩，打起来酣畅淋漓。但同时它也有比较高的精进门槛。较高的操作要求使得许多操作苦手玩家望而却步，如何能让更多的，喜欢ARPG酷炫爽快的战斗却被操作门槛卡住的玩家，能够尽可能多的体验到ARPG游戏的乐趣。

有了以上这些想法，结合“伙伴”这一出发点，就有了《深空之眼》主打的三人小队这个概念。

其实，小队同屏的玩法从底层战斗逻辑上就跟单人战斗动作不一样，在研发期的几次测试当中，这个方向给我们带来了不少挑战。同时载入三个存在主角级的定制特效，材质，动作，骨骼，现有的手机设备本身还无法和怪物一样采用低成本的性能开销去支持，这意味着小队同屏的方向不但对程序的性能优化提出了更高的要求，同时也带来了玩法设计上前所未有的问题。

既然选择了这条道路，就意味着我们需要在后续的角色设计、战斗机制中需要做更多的功课，让小队同屏的玩法更加有趣和丰富。

Untiy已经为开发团队提供非常成熟的工艺流程以及强大的自定义接口，所以技术上我们基本上采用了业界比较常用的制作工艺流程，例如3dxmax的morpher，bip骨骼动画，Unity的状态机，blendshape，和timeline等。在此基础上，团队技术同学结合Unity引擎强大的拓展性和深空之眼独特的游戏特性，对相关工具进行了拓展和定制。例如动画融合，骨骼优化，以及timeline编辑和配置等技术支持，及相关工艺流程，以保证角色演出动画，表情动画能够满足项目的品质要求。以timeline为例，我们根据项目的需要，在timeline中加入了许多功能模块，将各环节的资源做一定的编辑整合，最后呈现在玩家面前，例如配置隐藏物件，挂点信息，符合项目需求的动作融合，角色状态改变时的shader参数转换，特效配置、特效效果、打击感调试等等。

同时我们能够产出高品质效果的核心是设计，合作流程，以及团队默契度．可以说每个角色的诞生，其背后都离不开项目组每位同学的激情和努力.例如在设计角色之初，策划与美术都会进行长时间的激情碰撞，对角色的背景，性格，动作和表情的演出效果，特效元素，战斗方式等进行头脑风暴．过程中会不断优化内容，产出大量的概念图，最终达成共识，进行正式美术流程制作．在原画阶段会根据角色的背景，性格，制作不同的表情参考和分镜．在模型阶段精致化还原原画设定的脸部及表情模型．动作同学根据实际战斗，和已经确定的战斗方式和演出方式，进行定制化动画制作和导入引擎．交由特效同学进行特效制作，完成后将同步到最后打击相关负责人员处做最后内容的整合配置调试．在这所有环节结束以后，策划和美术同学会进行一轮验收，验收实机效果和预期效果的差异性，进行调优，最终形成一个完美的角色。

3. 美术渲染上，虽然是二次元风格，但是能看出带有明显的写实效果，是怎能做到的呢？

市面上许多友商的卡渲风格已经非常优秀，也是我们学习和努力的方向，不过我们更想做出符合深空之眼世界的独有风格，走属于自己的一条道路。在多次的demo尝试后，我们找到了我们的方向，就是突出二次元风格的同时，加入更加写实的材质质感表达.因此我们采用了PBR中对于质感优秀表现，同时也使用URP优秀的工作流程和性能.可以看到我们游戏中的角色效果中保留了卡通渲染的描边，阴影呈现方式等，同时也拥有比较真实的材质质感.

我们在角色制作流程中，依靠timeline强大的拓展性，配合maya的友好的动画制作流程，为了更好的呈现精致表现，和兼顾性能问题，最终采用输出视频的方式，在游戏战斗达到高潮时进行播放.

脚本代码：脚本相关的内存占用优化，很多优化建议和注意点在官方优化页面和网络上的文章都已经挺全面了。在编写程序时，更需要自身注意。禁止内存泄漏是放在第一位的，因为泄漏导致的问题往往会关联其他问题，如脚本引用的资源无法释放等，会加剧内存的消耗。gc问题往往会导致cpu“打嗝”，编写高频调用代码是需要注意语法问题，或者辅以对象池之类的方式，提高内存的使用效率。

美术资源：大部分非程序化美术资源，更多是制作规范的问题，需要在效果和效率之间取舍平衡。而程序相关的控制贴图和顶点数据，为了数据精度和避免错误剔除，可能会尽可能保留数据的完整性。程序在资源使用上尽可能的不浪费贴图和顶点通道。

Assetbundle：通过程序化的依赖分析，减少冗余资源，并在打包过程中剔除了一些不必要的shader变体和剔除美术错误依赖的shader，如standard shader等。这样可以较少内存浪费，甚至可以减低一些渲染drawcall ，需要持续关注打包日志，从中可以获得很多资源相关信息和耗时，也是一个优化信息获取途径。

空间换时间：主要靠烘焙，如破碎、粒子计算等。我们将需要大量需要计算的部分，通过预计算存储计算结果或者gpu计算更有优势的部分挪动到gpu上，来缓解cpu的压力。

利用多核，时间上并行：如果无法通过预计算解决的，尝试使用多核来节约一帧的计算时间，如动态骨骼的计算等；

减少计算量，优化算法；除了具体的算法优化外，我们将所有的逻辑集中起来，通过esc的方式组织游戏gameplay的逻辑，统一tick，如60帧的渲染帧率，我们的逻辑帧率并没有按60帧计算，而只有30帧，中间帧全部靠插值，从而节约了一些不必要的计算量。

合理的设置：物理、骨骼动画、粒子等引擎提供的模拟计算模块，更多的只能根据项目需求设置一些合理的阈值，如果骨骼数量、物理设置等；节约drawcall的调用和合理的渲染顺序。

带宽：资源上主要是合并材质、贴图合并通道，合理的贴图设置（如纹理大小、压缩格式、mipmap和纹理过滤方式）和减少不必要的采样次数。渲染顺序上尽可能的一个批次处理，减少gpu的上下文切换。overdraw上，目前只能用工具定期排查，尤其是特效。处理方式上，优化叠加层数、拆大面片、合并层级、合并贴图、mesh扣边等常规处理。更多的还是需要美术制作方法上优化。后处理上的带宽占用比较高，如bloom与镜面反射，将考虑用根据不同机型机型参数适配。

Shader：shader主要是复杂度优化、变体数量控制。使用Mali

Offline Compiler分析shader的复杂度。

可编程渲染管线：可编程管线可以方便定制渲染流程和顺序，并定制和开关不同的特性，根据目标平台调整渲染过程。如根据移动端的TBDR特性，可以很方便的定制并优化带宽消耗。

Timeline强大的工艺和拓展性令我们印象深刻， timeline的工作流程使得开发人员能够由想法，到制作，到落地，最终实机演示成品行程一套完美的闭环，这套流程操作简便，容易理解，所见即所得，对开发人员十分友善。同时timeline的拓展性使得许多战斗和表现的功能新增，优化，以及工作流都变得非常统一