【游戏世界】海量怪物、单局15分钟,《弹壳特攻队》开发技术分享( 二 )


最开始我们是非常忐忑的 , 从OOP的思想转换到DOP思想 , 对于我们技术人员来说是一个新挑战 , 再加上当时我们找到DOTS相关的资料也不多 , 所以只能一步一步尝试 。 我们当时找到的比较完善的DOTS版本是0.17 , 按照最初的想法摸索搭建了一个非常小的demo 。 没想到DOTS给了我们一个惊喜 , 新demo做性能测试时 , 我们把数量参数调整到几千只 , 都很顺畅得跑下来了 。 为了验证我们还特意尝试了一些15-16年的老机型 , 虽然开始有轻微掉帧的表现 , 但是也没压力跑完了 。 虽然demo的逻辑没正式版本那么复杂 , 但是实现了远超需求数量的怪物在低端机型上顺利体验 , 这是我们意想不到的 。
其实 , 我们首次上线测试开始的时候 , 才赶上最新的0.50的发布 , 但是需要做的东西太多 , 已经来不及升级了 , 索性就一直在用0.17 。 关于自动更新方面 , 我们项目暂时还没加入 。 是有后续的打算 。 现在还没有具体的确定方案 。
【游戏世界】海量怪物、单局15分钟,《弹壳特攻队》开发技术分享
文章图片
我们的核心需求是实现大量目标在同一场景出现 。 在设计上我们把游戏内需要展示出的内容拆分为4部分:单位实体(如玩家和怪物);子弹实体;特效;文字 。
在开发的时候我们也询问了很多同行朋友的建议 , 所以根据以上4部分的设计思路我们当时尝试了两个方向:
Burst+Job+自带渲染管线
Entities+HybridRenderer
这两个组合各有利弊 , 最开始的时候我们想用纯Entities实现全部内容 , 但是后来发现 , 有很多游戏内较复杂的逻辑用OOP的思路开发和维护起来更容易 , 再加上时间仓促 , 渲染方面想转URP有点来不及 。 所以我们最后把这两个方向结合了起来 , 一部分逻辑内容依然放在依然使用原有的GameObject+Monobehaviour 。 另一部分耗性能高的运算逻辑则放在DOTS层 , 充分利用Entities的多线程 。 这种设计方式加上我们TA的渲染优化 , 就实现了现在的游戏逻辑 。 现在来看 , 已经有了不错的性能表现 , 但是其实我们仍然不觉得满意 , 后续我们仍然会保持对游戏性能的进一步优化 。
伤害飘字部分主要基于两个方面来考虑 , 一是以后可能需要图片+文字或者其他多变的艺术化文字来丰富和迎合整个游戏的卡通化风格 , 所以需要一定的美术扩展性 。 二是希望能很少批次就能渲染所有文字 , 因为伤害飘字的特征是单个文字顶点少 , 但量特别大 。 综合考虑我们确定了图片+GPUInstance的方案 , 这样不仅满足性能和效果的需求 , 还更方便我们当时项目结构的管理 。
【游戏世界】海量怪物、单局15分钟,《弹壳特攻队》开发技术分享
文章图片
DOTS架构上 , 你们目前还有什么想要提升的方向吗?在《弹壳特攻队》后续的发布上有什么新的惊喜给到玩家吗?
首先还是先要赞一下DOTS架构的巧妙设计和便捷 , 这套架构极大的降低了使用成本 。 由于C#作为高级编程语言封装得太好 , 所以大多开发者对unsafe并不是特别熟悉 , 想要写出高效且安全的指针内存操作无疑增加了很大的难度 。 DOTS架构上手简单 , 而且在学习DOTS框架的同时也会对内存、指针、寻址、数据存储方式等提供更深的理解 , 有利于对计算机基础的学习 。
如果说还有需要提升的方向 , 可能想到的是对ECS部分的优化 。 因为传统GameObject使用的是面向对象编程的方式 , 而ECS使用的是面向数据编程方式 , 从而增加了上手难度 。 同时ECS本身存在很多独有的写法和命令 , 比如WithoutBurst+Run操作等 , 这些也会在学习初期造成一定的困扰 。 所以我个人觉得如果能够使用面向对象编程的思维来写面向数据的逻辑 , 才真真是极好的 。
【游戏世界】海量怪物、单局15分钟,《弹壳特攻队》开发技术分享
文章图片
比如在MonoBehaviour中开放一个类似于SystemBase的功能 , 虽然没有可以移除和添加的功能和便捷的扩展性 , 但是也可以满足一部分的开发需求 , 并且可以更好的引导开发者将ECS和GameObject系统看做一个整体而不是两个独立的架构 , 从而引导学习和了解的兴趣 。
对于后续版本发布 , 惊喜肯定是有的 , 不过相应的制作难度也非常大 , 可能还需要玩家们耐心地等待一段时间 。 可以稍微透露一下 , 未来的版本中我们会加入实时组队的相关玩法 , 并且会强调团队配合和策略性 。