漫谈手游商业游戏前端框架

今天想聊一聊手游商业游戏前端框架. 既然是前端框架,就先从选哪个引擎开始聊起吧.

技术选型

这其中有两个关键字,一是"手游", 二是"商业" .

说到"手游", 基本上引擎就定位在了 Unity. 在手游开发行业, 除了个别技术实力非常雄厚的公司,和个别另辟蹊径的公司, 绝大部分用的引擎都是 Unity ; 还有一些公司因为旧项目依旧能盈利,拖着商业包袱,坚守着 Cocos2DX ; UE4现在用的越来越多, 但总的来说还是偏少,我不熟悉,因此在这不多加评论.就绝大部分情况来说,Unity还是绝对的主流.

说到"商业" , 在需求上"热更新" 几乎是必须要做的.不仅要做,而且要做到几乎所有游戏内容都可以热更新.这就限制了开发时的技术策略. 资源能热更新肯定是必须的, 代码能热更新几乎就限制了主要逻辑的开发语言必须是 Lua . 当然也可以用其他脚本语言, 我这里就只聊主流. 目前 Lua 绝对是手游开发里面的霸主, 去招聘 App 上搜一搜工作机会一目了然.

引擎定了, 开发语言定了,就要构思一下代码框架了. 咱们这里以 Unity 引擎 + XLua 举例.

在游戏项目中, C# 和 Lua 谁是主力,谁是辅助,必须得在开发最开始就定清楚.有的游戏是 C# 开发业务逻辑, Lua 做一些辅助. 我早年参与过的项目 “雷神2 暗黑世界” 就是这样. 底层提供了足够多的接口, 因为涉及的逻辑比较少, Lua 很多时候甚至是给策划写的. 程序员写一些逻辑经常变化的 lua 脚本, 而这部分 Lua 脚本也仅仅是处理一些 C# / C++ 关键的回调. 这种开发模式统称为 C#为主, Lua 为辅.

另一种情况目前更流行. 开局一个 DoString() , 引擎的原生语言 C# 直接创建好 Lua 虚拟机, DoString() 一个 Lua 文件, 然后就大撒把了. 这样之后, 所有的游戏主框架, 都需要在 Lua 里做. 原生语言 C# 只提供少量的桥接调用,把引擎的 Update() 之类的关键函数调用到 Lua 里. 其他时候, Lua 只有在需要图形声音的地方 , 调用一下引擎 C# 导出到 Lua 的 API . 这种模式更加灵活, 可以达到 “整个游戏内容全部热更新” 的效果. 我们称之为 Lua 为主, C# 为辅.

第二种情况在目前的商业游戏里明显更流行,也更加灵活. 因此,商业手游前端最稳健的技术选型就定下来了: 引擎选Unity , 开发语言选 Lua, Lua库选择目前最流行的 XLua, 并且要明确 Lua 为主, C# 为辅.

流程框架

接下来说一下写这样一个商业手游, 客户端代码都要经历哪些流程.

launcher

进游戏, 需要一个最小化的 “launcher” .这个 launcher 一定是很少的 C# 代码和 Lua 代码完成的.并且也只拥有最少量的美术资源. 比如只在游戏开头有一个非常简单的公司 LOGO 之类的图片做占位. 这样做是因为这部分将会是游戏唯一一块无法被热更新的部分. 这部分的美术资源要少, 因为你将来没有办法替换这一部分的内容. 这部分即使是 Lua 文件逻辑也不要依赖于游戏逻辑框架, 因为将来游戏逻辑框架是要被热更新的, 可以理解为游戏流程跑到这里, 其他的功能代码还不存在. 因此这里越简单越好.

对应到 Unity 引擎里, 这部分的 Lua 代码和美术资源可以放在 Resources 目录.

热更新

从 launcher 出来,紧接着就要进入到热更新阶段.可能有些游戏会先登录,再进入热更新. 这样做的劣势很明显: 登录界面是无法被热更新的. 将来更换主题, 添加版号等内容时,这样做都是麻烦. 因此, 从 launcher 出来,第一步一定要进入热更新阶段.

这部分的 Lua 代码就可以放到常规开发路径了,因为这部分代码将来是有可能发生改变的.热更新的流程也有一套模板化规律可循:

检查版本号. 已经最新则进入下一阶段.否则准备热更新
请求即将更新到的版本的资源列表. 比较待更新资源和本地资源的 md5 值, 确定一个更新 list
把需要更新的文件下载到本地. 这个目录在 Unity 里通常可以是 Application.persistentPath.因为这个目录是可读写的目录.
在更新下来的目录里,写入新的版本号.

至此,完成了一套热更新的流程.

对应到 Unity 引擎里面. Resources 目录存放 launcher 步骤相关的最小化的游戏内容. 这一步之前已经提到过. Application.persistentPath 用于存储所有的游戏资源. 同时,这里还要负责维护当前更新到的资源的版本号,以及各个资源文件的md5值.

可以更新的资源, 通常只包含两类: AssetBundle 和 Lua . 在游戏开发阶段,采用 AssetDatabase 的方法来读取本地资源,在编辑器下跑游戏. 在非编辑器模式下, 需要把游戏资源目录下的所有资源打成 AssetBundle 到 Application.persistentPath, 并把 Lua 文件拷贝到该目录, 用加载 AssetBundle 的形式测试正常的游戏读取资源的流程.

这两种资源读取方式的区分 , 对上层逻辑必须是透明的,并且保证行为是一致的.否则如果需要上层逻辑根据编辑器和实际环境不同需要写不同的代码, 就大乱套了.

游戏登录 & SDK

完成了热更新之后,可以走正常的登录流程和SDK 登录流程了. SDK的接入有一点我想说的是, 尽量避免修改过多的 iOS 和 Android 的原生代码, 流程控制能让 Lua 控制的地方,一定要托管给 Lua . 因为无论是 iOS 的 ObjC ,Swift 还是 Android 的 Java,Kotlin 都是无法热更新的. 而SDK 流程如果能做到全部交给 Lua 处理, 就可以享受到在热更新之后再进入登录流程这样做的好处了.

进入游戏主页

登录成功之后,就可以准备进入游戏了.

游戏逻辑组成部分

手机游戏通常可以分为以下几个组成部分

面向对象
事件机制
MVC 处理界面业务逻辑
核心战斗 ECS
timer 机制
网络通信
教学
支付

这些部分可以统一用一个全局的 game 对象来做管理.下面我逐一来说.

面向对象

之所以把面向对象放到第一个来说, 是因为 Lua 并没有很多语言天然支持面向对象. 必须自己把 metatable 进行简单的封装,才能支持面向对象编程. 而确认大家风格统一, 使用同样的面向对象机制,编写一个正确的面向对象逻辑就显得格外重要.

否则大家使用 Lua 时全局变量乱飞, 各处都是简单粗暴的 table 将会使得项目无法维护.

事件机制 & MVC

当今的手游随随便便就可以数出来若干个子系统: 主线关卡, 抽卡,英雄养成, 装备养成, 活动, 签到, 工会联盟, 聊天, 各式玩法副本,教学, 红点等等.每个功能少说也要涉及五六个界面, 多了10个20个都很正常. 每个子系统还都要存储数据, 数据结构也五花八门. 如果是 3D 游戏那还涉及很多场景. MVC 这种数据表现分离的代码模式几乎是唯一的解决方案.

事件机制是实现观察者模式的基础.如果一个游戏没有事件机制无法想象逻辑要写的有多么混乱.MVC 更无从谈起.

把这些子系统要想有条不紊的安排好, 只能采用 MVC 的思想: Model 用于存储服务器数据的拷贝, 每次网络通信都要和服务器完全同步; View 负责处理各个界面; 模块和模块之间采用观察者模式, 大家互相抛事件的方式来处理业务逻辑 .

拥有一套完善的 MVC 框架和事件机制 , 才能保证各种各样的子系统能安稳的在游戏里面运行 . Lua 里没有 C# 现成的 delegate , event 的机制, 因此事件机制需要自己手动实现 .

核心战斗 ECS

介绍 ECS 的文章非常多, 我强烈推荐大家都去了解 ECS 的思想和写法,并且在实际项目中尝试运用因为 ECS 真的能把逻辑写的非常清晰有条理. 我经手的项目在使用 ECS 之前逻辑一团乱码, 使用之后逻辑清晰明了, 易于扩展和维护,我对 ECS 的优势体会颇深.
ECS 的 “System 只负责逻辑没有状态, Component 只有状态没有逻辑” 是 ECS 的精髓.并且当一件事发生需要处理时,在 Component 里做标记,等待某个 System 集中处理 ,这种延时处理的方式, 也是 ECS 重要的一大特点 .
并且用 ECS 写逻辑还可以附带这样的好处: 可以把游戏逻辑写成一个单独的 Lua 工程, 这个 Lua 工程靠死循环来驱动逻辑帧步步向前, 做逻辑处理. 与表现相关的都记录在 Component 数据里.但是这个 Lua逻辑工程不写表现相关的 System ,相当于表现相关的数据不做任何处理.
在 Unity 游戏环境下 ,依然调用这段逻辑代码, 唯一不同的是驱动逻辑帧步步向前的是 Unity的 Update() 函数.再给游戏搭配上 grafic system , sfx system ,这样就使得战斗逻辑有了表现和声音.
将来无论是做战斗录像, 还是做服务器战斗演算, 还是模拟战斗, 只需要在裸 Lua 工程里做一些改动,就可以实现了.
由于逻辑帧是脱离于表现单独可以跑的, 因此在将来加入联网和同步机制时, 逻辑也是现成的.
ECS 在实现中需要注意的是, 经常要根据各种各样的 component 条件,来做 entity 的筛选. 这样的筛选非常频繁,必须充分考虑到效率问题.

总结

剩余的 timer 机制, 网络通信, 教学, 支付等等话题我今天先不提了.我还设想要再聊一聊版本管理, 打包等话题 , 但是那又将是非常大的两个话题. 这些内容都留给以后吧.