国产slg游戏,畅销榜前三,流水过亿,从美术、策划到技术支持

《乱世王者》是由腾讯天美工作室出品的一款战争策略手游,2017 年 8 月开启测试,数天之内便取得了 App Store 中国区畅销榜前三的成绩,充分体现了市场、玩家对于这款游戏的认可。


在尊重和传承经典 SLG 玩法的前提下,游戏做出了不少突破:游戏构建了一个大世界,为玩家呈现更加真实、热点的游戏环境和生态;游戏融入了极具乐趣的养成模式,使得游戏策略性更强;游戏内加入了如 AR 寻宝玩法、 自定义头像等酷炫新玩法。


6 月 22 日,来自腾讯的游戏高级工程师 肖程祺 受邀出席了 Cocos 上海沙龙,向开发者分享了《乱世王者》的深度优化方案,包括《乱世王者》项目中 地形 处理和优化思路,深入讲解了游戏针对 纹理内存 优化的解决方案,并分享了项目对 引擎渲染层 所做的一些优化。


肖程祺

在获得程祺同意后,Cocos 将其优化方案整理成文,同更多开发者进行分享,具体内容如下:

《乱世王者》深度优化方案分享

腾讯 肖程祺

《乱世王者》是基于 Cocos2d-x 开发的一款战争策略类游戏,需要在游戏玩法创新的同时,在美术品质和性能方面也做出突破。

一、SLG 地图 的微创新和优 化

美术上想要增加细节表现力,让地形的细节更加丰富,同时需要增加 3D 透视的感觉。

实现成果:


1、丰富的细节

地形细节丰富的代价:

  • 资源量膨胀,地形纹理是原来的5倍。
  • 地形类型新增:沙漠,雪地,每个地形的变化增加。

tile 数量从 100 块左右提升到 500 多块。


渲染压力提升,渲染层数从 2 层变 5 层,拖动地图的时候重新组织数据的开销增加。


面临的问题有:

  • 内存增长:纹理扩大了 5 倍
  • 地图层数增加后,加载和拖动地图更新的效率成倍降低
  • 贴图数量增加后,需要自己去实现 batch

我们的优化方案:

(1)提升贴图的利用率,减少地图纹理的内存


重新排列 tile, 贴图利用率从 50%提升到 85%

效果:


5 张贴图最终变成 3 张

(2)建立更高效的数据组织,提升加载效率

地图数据离线处理后,以 protobuff 的数据格式存储,并使用 zstd 无损压缩进行处理,加载速度和大小都得到保证。


(3)合并 地图批次,减少不必要的顶点数据

每一层地图的都根据 TextureID 排序后绘制,由于顶点和 UV 数据已经存储在 VBO 里面,只需要根据裁剪结果修改 indexbuffer 即可。 5 层一共 3 张贴图,意味着 drawcall 数量不会超过 15 个。


2、3D 透视关系效果

(1)处理3D透视关系

  • 场景用 3D 相机绘制
  • 地图上的物体“站”起来



所有物件绕x轴旋转

至垂直于摄像机的fov中线的角度

(2)解决大物件的视角偏差

边缘位移:


对于皇城和虎牢关这种比较“宽大”建筑单位,在拖动大地图的过程中会出现边缘位移的现象,这个效果也是非常影响美术表现的。

我想到的解决方案是,将大的建筑单位拆分为多个部件,并对每个部件分别作 billboard 处理。

以皇城为例,考虑到部件之间的关联性,使用了如下的拆分方案,可以看到边缘位移问题得到了很好的解决。


(3)解决 3D 物体的透视带来的偏差

为了表现更加丰富的怪物细节以及更流畅的动画,美术希望直接在现有的场景中加入 3D 模型。

由于我们改用了 3D 摄像机,同时大地图场景单位都是 2D 资源,加入 3D 模型后两者的透视效果不一致。


在透视相机下,左右移动相机透视问题严重

容易想到的解决方案:先将 3D 模型按照指定角度渲染到 RT 上,再将 RT 上的纹理和其他 2D 元素一样渲染到场景中。但是 Cocos2d-x 对多照相机和多渲染路径的支持不够友好,这种方案需要对引擎作比较大的改造,而且会增加更多的显存占用。

我们采用的是第二个方案:在每帧绘制 3D 模型前,计算出其缩放和位移,然后再使用正投影照相机参数绘制 3D 模型到屏幕。整个过程只需要一次绘制,没有额外的纹理占用,而且对引擎的改造也是最小的。


渲染 3D 物体前自己计算正交投影矩阵

上述这些效果提高了《乱世王者》大地图的美术品质,与同类 SLG 游戏对比,我们游戏获得了更多的关注。

二、纹理内存的深度优化

《乱世王者》内存中资源的大致占比为:


用 4 步搞定内存大户: 纹理

  • SmashTexture
  • FontTexture
  • 压缩纹理的优化
  • Texture Pool

1、Smash Texture

Smash Texture 解决的问题:

  • UI 制作过程中需要使用 atlas 来尽可能合并渲染批次
  • 因为使用 atlas 需要一套规范避免一个界面加载过多的 atlas(维护成本很高)
  • 一旦出现一个元素多次重复出现且用到多张不同的纹理,需要额外的机制去避免 drawcall 爆炸般增加
  • png 使用的 deflate 压缩率不算很高,安装包体积压力山大。有些人选择使用 jpg 等有损压缩来牺牲美术品质



(1)Smash Texture Pipeline

  • 通过 tinypng 减色,增加压缩率(如果减色效果不好,则不做减色处理)



  • 打包成合图后,供在编辑器中使用



  • 转换成 smash



drawcall的降低


未作任何其他改造的情况下,批量使用 smash texture 后,当前界面的 drawcall 从 64 降低到了35。

(2)减少 IO:Block Cache

  • 加入 Cache 机制, 达到上限时使用 LRU 算法清理,每次清理固定数量
  • 特定时机,清理 Cache,分帧清理,不卡顿
  • 回收操作只需要回收分配信息,不需要对贴图显存操作,速度快



现网版本用户行为上报的 cache 命中率

(75%左右)

(3)提升Smash Texture的使用率

原本 smash texture 里面的每一行是 32 像素统一高度,利用率比较低(比如说 36 像素高的图片,最后还会留下 6 像素左右的空间。填充到 32 像素高的 smash texture 行里会存在浪费),因此我们按照下图,重新划分了高度行,容纳更多的 UI 图元。


经过优化,smash texture 的使用率可以从 80%提升到 90%。


(4)总结 Smash Texture 的优缺点

优点:

  • 内存峰值可控:所有使用 smash texture 的贴图共享一张纹理
  • 增加了 UI 利用 dynamic batching 自动合批的概率
  • 最大程度还原 UI 的品质
  • 相对 PNG,他有着更小的文件尺寸(zstd 压缩)



缺点:

  • 对于大型背景图不太适合,容易填满。背景图需要额外拆分。
  • smash texture 目前只支持离线预处理,动态下载的图片还不支持。

2.文字系统的内存优化

  • 用一张 2048x2048 大的 A8 格式纹理解决所有字体需求,当贴图不够用的时候尝试清理整张贴图。
  • 不同的字号,字形,格式生成唯一的 key 在这张统一贴图中进行索引。



提升贴图利用率:改良装箱算法

基于 maxrect 做优化,将纹理利用率提升到 95%+。


提升贴图利用率:减少字号数量

统计了文字的字号使用频率,根据字号分布,我们取了 5 个字号,其他字号向下取到最接近的预定义字号上,缩放后渲染,大于最大字号的时候则用最大字号放大后渲染。


3.压缩纹理

压缩纹理的一些痛点:


压缩纹理优化:

  • 对于 1/2 方图的 atlas,分离 pvrtc 的 rgb 和 a 通道,合并成方图后,再压缩。



  • 对于不符合 2 的 n 次幂的不规则的单图(背景图为主),通过计算出最小的 2 的 n 次幂包围尺寸,切分成多块来优化文件大小,解决 pvrtc 必须方图的不友好设定。



4.Texture Pool

  • 把所有贴图统一管理生命周期
  • 根据设备内存大小,分别设置贴图 GC 的阈值
  • 当贴图使用量超过 GC 阈值的时候,根据引用计数释放没用到的纹理
  • 添加运行时查看工具,运行时也可以查看不正确的贴图格式设定



内存管理的小结:

  • 所有模块必须有上限,避免随着迭代内容不断增加而持续上升
  • 避免浪费

三、解决 UI batch 的痛点

即便 Smash Texture,即便 Font 在一张纹理上,我们还是面临着一些 darwcall 明显可以优化的地方。


期望的渲染顺序:

通过 TriangleCommand 底层的 dynamic batching,自动合并批次。


Cocos2d-x的默认渲染顺序:


充分利用 TriangleCommand:

  • 将所有 Cocos2d-x 默认的控件以及自定义控件都尽可能改造成 TriangleCommand 实现,使得支持 Dynamic Batching。
  • CCProgressTimer
  • LayerColor

利用 GlobalZ 来解决合批的问题:

  • 对于 2D 元素,GlobalZ 的排序可以很好的让相同材质的物件进行 batch
  • 所以我们可以离线设置好 GlobalZ (存储在csb里面)
  • 根据遮挡关系和纹理自动计算
  • 人工设置
  • 自动递增



新的问题:

当 UI 有多层弹窗的时候,上下两层的控件由于 GlobalZ 都从 1 开始,所以会出问题。


改动最小的解决方案:


改动后的情况:

  • 解决了多层 UI 层级问题
  • 解决了同层 UI 利用 GlobalZ 能尽可能 Batch 到一起



四、结语

程祺: Cocos2d-x 使用上手难度比较低,实际使用项目也很多,在开发的过程中也存在一些普遍的性能和优化痛点,希望这次为大家带来的经验分享,能帮大家在优化的道路上走得更加顺利。我们的 腾讯天美上海 T1 工作室 正在 招聘 Cocos2d-x开发 ,对游戏开发感兴趣且有 Cocos2d-x 使用经验的朋友,欢迎加入我们,简历投递邮箱: cloudxiao@tencent.com。

C 姐:非常感谢 程祺带来的分享!并祝项目更加顺利!

C 姐: Cocos 引擎一路走来,收到了很多来自用户的宝贵建议, 通过不断的优化和改进,在 Cocos Creator 中,上述许多性能问题都已得到解决。 包括:

  • 支持 Texture Packer 的 Polygon outline 裁剪,使用 Polygon outline 裁剪后的图集将对每个小图按透明区域精确裁剪为不规则的多边形,将达到类似 Smash Texture 节省图片空间的效果,对渲染性能也有一定提升。 该功能无需在 Creator 中进行额外操作,导入图集后即可自动开启。
  • 从 Cocos Creator 2.0.9 开始,支持将 Label 设为 CHAR 模式,即可实现类似的优化方案。能够以“字”为单位将文本缓存到全局共享的位图中,相同字体样式和字号的每个字符将在全局共享一份缓存。提升纹理利用率的同时,也大大提升了文本刷新时的性能。详见文档 [文本缓存类型]
  • 从 Cocos Creator 2.1 开始,集成了压缩纹理支持,编辑器可设置不同平台所需格式,构建时将会自动进行压缩,支持 etc/pvr 的 alpha 通道分离。详见文档 [压缩纹理]
  • 从 Cocos Creator 2.0 开始,默认会在原生和 Web 平台上启用动态合图,该功能支持运行时根据渲染的先后顺序动态对纹理进行合并,降低 drawcall,用户无需对 z 进行手动指定。当 Label 启用了 BITMAP 模式后,会同时进入合批。 详见文档 [动态合图] ——摘自cocos[仅共学习交流]
发表评论
留言与评论(共有 0 条评论)
   
验证码:

相关文章

推荐文章

'); })();