评论

【大赛文章征集】微信小游戏 《时空异闻录》(技术篇)

在这篇文章中,我希望与你们分享一下我在小游戏开发过程中所思考到的一些事情,以及我们冗长的技术框架。 游戏开发并没有想象中的那么容易,望与君共勉!

技术闲聊

整个游戏开发中涉及的技术十分繁琐,在此我从游戏的整个大框架入手,主要介绍一些开发中前后端以及管理端我们涉及的技术问题。当然,由于篇幅原因,只是简单介绍,并不描述具体样例。

整体架构

  • 后端
    • 持久层——Mysql 数据库
      • 剧情、玩家、卡牌、资源的数据结构设计
      • 数据存储安全
    • 缓存层——socket.io-redis与session
      • 玩家状态:登录、逗留、对战、退出
      • 对战与重连:网络波动环境下的访问
    • 服务层——ThinkJS(based on Koa2)
      • 数据埋点与分析:Middleware
      • RPC接口功能稳定性:mockData与单元测试
      • RPC接口性能可用性:并发压测
      • 开发环境、预发环境、线上环境的数据隔离
  • 游戏客户端
    • 跨平台开发框架——Egret与TypeScript
    • 资源管理与打包
      • 资源下载
      • 资源缓存
      • 资源迭代热更新
    • 页面管理
      • 页面注册
      • 生命周期与事件监听
      • 页面注销与异常处理
      • 内存泄露
    • 组件化开发与单一数据源
      • 组件开发与复用(卡牌组件、弹窗组件等复用)
      • 组件埋点(记录所有玩家操作、点击)
      • 视图单向绑定数据(单一数据源渲染)
      • 组件防抖与限流
    • 数据请求:Https Request与SocketIO
    • Egret 动画与逻辑
      • 为什么tween.js很垃圾
      • 如何克服异步动画问题
      • 动画与逻辑同步:事件队列的执行与阻塞
    • 流程交互体验
      • 按钮反馈动画的重要性
      • 交互提示,消息红点与任务提醒
      • 加载提示
      • 游戏新手引导
    • 反作弊
  • 全栈管理平台
    • 项目开发管理——GitLab
    • 代码部署与迭代——pm2
      • 热更新迭代
      • 服务节点崩溃重启
      • 日志记录与分析
    • CDN资源管理——七牛云
    • 自主开发管理平台
      • 数据管理
        • 玩家数据监控
        • 卡牌数据可视化管理
        • 剧本、关卡数据可视化管理
        • 资源数据管理
        • RPC接口的开放与关闭管理
        • 预发与线上隔离环境的数据同步
      • 客户端组件埋点管理、应急管理(一键关闭组件入口)
      • 资源管理(七牛云API)资源更新与CDN同步
      • 线上版本控制(后端版本控制,前端需要微信审核,无法快速迭代/回滚)

一、后端

  • 持久层——Mysql 数据库

    • 剧情、玩家、卡牌、资源的数据结构设计

      在数据结构设计方面,最大程度上使得所有属性可以自由组合,这样设计大大提高了属性的复用性,卡牌数据的设计仿照《炉石传说》设计,为实现各种卡牌效果,我们为卡牌添加了元数据,使卡片可以执行特殊的命令。

    • 数据存储安全

      用户关键数据无明文存储,全部加密存储。

  • 缓存层——socket.io-redis与session

    • 玩家状态:登录、逗留、对战、退出

      用户在登录、逗留状态时,client与server使用https进行数据传输,后端创建session记录用户登录状态。当玩家进入对战状态时,client与server使用socektIO进行数据传输,后端使用socket.io-redis记录用户状态,维护房间对战内容。

    • 对战与重连:网络波动环境下的访问

      当玩家因网络波动与后端断开socket链接时,client会尝试重连,重连之后会获取socket.io-redis缓存内容,加入之前仍在进行的对战。

  • 服务层——ThinkJS(based on Koa2)

    • 数据埋点与分析:Middleware

      在C-like游戏中,通过数据解读玩家对游戏运营有着十分重要的意义,所以数据埋点是必要的。我们在中间层开发了部分数据埋点插件,所有前后端交互数据将先通过中间层的插件,这可以记录下我们分析所需的数据。前端组件也会绑定一些用户行为记录的事件,发送这些数据到后端,以便我们在管理端分析用户的数据。

    • RPC接口功能稳定性:mockData与单元测试

      在游戏的开发中,后端接口的可用性检测消耗了我们的很大一部分时间。由于在卡牌游戏中,卡牌结算逻辑复杂,接口将整个逻辑内含,只暴露出输入和输出,最大程度简化客户端交互逻辑,但这也带来一个问题:单个接口的单元测试涉及的功能十分庞大。我们为了保证接口功能的稳定性和可用性,创建了很多为测试专用的虚拟对战接口,来让前端加载准备好的mockData在游戏客户端测试对应的卡牌或特殊的组合情况。

    • RPC接口性能可用性:并发压测

      后端使用pm2部署,通过pm2,后端可以一键部署、迭代,还可以通过监控平台实时查看服务器性能。为保证我们接口的性能可用性,我们对每一个接口都进行了压力测试,使用Siege等工具对不同接口的性能进行了评估,针对有性能问题的接口进行分析和重构。

    • 开发环境、预发环境、线上环境的数据隔离

      后端将开发环境、预发环境(测试)、线上环境进行了数据隔离,目前这部分的管理端页面仍在开发中,我们只能手动切换环境。我们搭建了三个不同的环境,在新的接口上线时,将通过开发、预发环境的测试才能推送到线上环境。

二、游戏客户端

  • Egret与TypeScript

    为了较快完成整个项目以及跨平台移植,我们选择了H5开发框架Egret。Egret Engine是全球领先的HTML5移动技术平台,它是遵循HTML5标准的2D、3D引擎,解决了HTML5性能问题及碎片化问题,灵活地满足开发者开发2D或3D游戏的需求,并有着较强的跨平台运行能力。它具有较高的开发效率,完整的游戏开发工作流,针对不同平台的性能优化以及简洁易用的组件化UI系统。通过Egret引擎开发的游戏,可以较为方便得移植到微信、QQ、OPPO、百度、Facebook等小游戏平台,为我们对此项目的进一步扩展提供了较好的帮助。

    Egret Engine也同时支持TypeScript,JavaScript(ES6语法) 语言开发。TypeScript是由微软开发的开源编程语言。它被称为JavaScript的超集,在扩展了JavaScript的同时也兼容JavaScript。它从核心语言方面和类概念的模塑方面对 JavaScript 对象模型进行扩展,支持静态输入、更便捷的重构以 及协作。

    • 踩过的坑!
      • API不足:一些项目需要的功能并没有被实现,我们用JavaScript实现封装了这些功能,也有一些API不能满足使用需求或者已被废弃需要更新,我们在引擎中找到对应代码并进行了一定的扩充。
      • 屏幕适配:鉴于当前异形屏花样繁多,而Egret的适配为拉伸、裁剪等较为粗糙的方式。我们的游戏仍为非异形屏按比例铺满,异形屏按比例居中,导致左右有一定程度的黑边,略影响游戏体验。
      • 微信小游戏适配不足:在微信更新某一版本后,Egret发布到微信的游戏会有卡顿。这部分需要引擎开发者对微信做更多的适配。
  • 资源管理

    对于微信小游戏,设计C-like游戏的一大难点就是资源管理,如何利用有限的缓存空间保存足够多的游戏资源,是提升游戏流畅性的关键。即使是Wifi状态下,下载数十上百M的资源也足以让游戏的用户体验直接死亡。为了更便捷得控制游戏内容,我们使用了第三种加载方式,实现资源缓存、版本控制、热更新。

    • 资源缓存

      Egret为我们提供了较为方便的接口,通过微信小游戏的API,资源可以直接缓存到本地,当下次游戏时会从本地加载,没有版本更新的时候用户只需要在第一次打开游戏的时候下载资源。

    • 版本控制

      使用版本控制,资源被加上版本号信息,同时通过对应的版本,控制文件资源进行更新。我们在管理端实现了资源版本管理、名称规范化模块来实现便捷的版本控制。

    • 热更新

      后台管理端可以管理资源文件的版本信息,每次用户打开游戏前拉去资源信息进行比对,得到更新下载的资源列表,根据列表下载并更新缓存资源文件到本地,实现热更新。

  • 页面管理

    在Typescript中自动GC十分容易造成内存泄露,为防止创建大量的重复页面造成内存占用过多,我们对不同量级的场景页面做了不同的处理。对于包含对象、监听、动画较多的页面,我们使用了单例模式以及对象池,对每个大型页面创建单一的对象并且不断复用,以此在切换游戏页面中,避免了频繁创建和删除操作,从而优化游戏性能。对于较小的页面或者弹窗提示,我们采用了卡片组件、弹窗组件来创造对象并且严格控制其销毁。我们对每个页面进行了大量的错误处理,保证其监听事件在任何情况下都可以正常运行,使玩家在页面切换中不会因为其他逻辑、数据错误而卡在一个页面。

  • 组件化开发与数据渲染

    组件化开发是前端工程中常用的一种开发模式,通过这种模式,我们的代码能够得到极大程度的复用,整个工程的可维护性也会大大提升。在我们的开发中,页面是最上层组件,页面内各个元素也是组件,组件的生命周期与父组件直接关联,我们只需要进行完善地页面管理就可以有效管理所有组件。组件大多使用不同的数据源,与常见的组件化开发不同的是,我们使用的是单一数据源,数据加载导致的组件更新并不会造成其父元素或子元素的更新。选择这个模式的原因主要是因为我们的游戏要避免频繁的组件更新,只在需要动画的区域进行更新,数据加载的更新影响较小,在游戏中一般也不会影响其他组件的更新,所以我们去除了这种组件更新依赖的关系,而是使用Sub/Pub模式让组件监听单一数据源并更新自身。

  • 数据请求

    作为一款功能模块复杂,兼具购买、聊天、任务、关卡、PVE对战、PVP对战的TCG C-like游戏,不同的游戏页面对前后端交互的时效性、数据量、安全性的需求不同。为此,我们使用混合型请求Https Request + SocketIO来进行前后端交互,保证了在不同需求下使用最合适的请求方式,无论是开发流程还是产品体验,都因此得到了提升。

    在进入游戏到开始对战前,使用短连接由前端单向对后端进行数据请求,在这个过程中,交互不密集,客户端单向请求,Https Request足够胜任并且对后台有较小的压力。对战时,前后端交互使用时效性更强、双向通讯的SocketIO,在满足实时交互的同时,能更好的向客户端反馈数据交互状态,可以处理在各种网络情况下的极端情况。

  • Egret 动画与逻辑

    在动画制作上,我们使用了tween.js来实现动画。相比unity动画,tween动画的开发更为繁琐,想要保证流畅的动画就对工程的需求量大大提高,但其好处是可以运行在多个平台上,兼容性更强。

    tween的异步执行机制,使动画进行的顺序、时机难以准确控制,我们将动画封装在事件队列中,动画播放会阻塞该队列,当有动画执行完毕时,检查队列是否有未执行动画,接着执行下一条动画。当队列为空后,终止动画的执行。如此即可保证不同的动画可以按要求顺序进行。

    逻辑代码只能向事件队列中添加需要播放的动画,而动画的播放只由事件队列控制,单一播放会阻塞队列,不会造成逻辑代码导致动画播放混乱的情况。逻辑代码执行结束后会监听动画事件播放完成的事件,直到动画播放完成才执行下一阶段逻辑代码。

  • 流程交互体验

    • 按钮反馈

      按钮反馈是保证流畅的重要元素之一。在早期版本时,按钮点击之后便会执行下一步操作。但是我们发现,当按钮点击与下一步操作之间有较短间隔时,会导致玩家无法知道按钮是否已被触发,从而多次点击,带来较为糟糕的游戏体验。为此我们给按钮加上了统一的动画来展示点击反馈,动画阻塞了按钮的点击逻辑,提供了有效的防抖和限流,并且玩家也可以明确知道按钮是否被触发,从而给出一个我们期待的预期反应。

    • 交互提示、吸引性标识

      交互提示是对玩家行为的一种限制和提醒,为防止非预期操作的出现,我们在玩家所有操作后都添加了交互提示,但执行较快的操作会取消交互提示的显示,这样再玩家网络不稳定的情况下,玩家会对操作的响应时间给予更宽容的态度。加载提示是交互提示中数量最多的一种,在每次页面跳转时,页面内数据渲染完成前都会显示加载提示。

      吸引性标识(消息红点)能够有效的增加玩家对自己数据的掌控能力,给玩家一个容易接受的时效性信息,并且能够显著增加用户活跃度和用户粘性。我们在邮件、任务、新解锁的物品上都添加了吸引性标识。

    • 新手指引

      这部分是一次性指引,用于玩家第一次进入时,通过文字和点击指引教会玩家游戏的基础玩法和游戏物品的使用,同时介绍游戏的背景、主题、世界观和价值观,帮助玩家快速上手游戏。

  • 反作弊

    • 为防止脚本或软件对客户端的修改,所有数据都在服务端严格控制,对战时客户端会计算部分数据来实现零等待响应时间,但所有的对战数据都会被服务端计算的数据直接替代,客户端计算数据只用于显示。
    • 玩家资源数据在传输时加密,无法直接看到数据结构与数据内容。

三、全栈管理平台

  • 项目开发管理——GitLab

    在项目开发期间,我们使用gitlab管理项目的版本迭代与上线流程,在下一步开发中,我们会搭建私有的代码仓库,将版本迭代与上线流程添加入全栈管理平台,以图形化的方式管理整个项目流程。

  • 代码部署与迭代——pm2

    • 热更新迭代、服务节点崩溃重启、日志记录与分析

      pm2支持nodejs代码一键多核部署,自动重启,版本平滑更新。我们使用pm2启动后端服务,服务器与后端服务的运行状况可以在管理平台实时监控,日志的图标分析也可以在管理上查看。

  • CDN资源管理——七牛云

    为提高资源加载、下载速度,方便管理游戏内资源,我们使用了七牛云平台作为资源管理平台。通过七牛云提供的API,在管理平台上可以管理资源及其版本信息,CDN回源更新资源等。

    目前在管理平台上我们实现的主要有以下功能:

    • 玩家数据可视化分析

    • 卡牌数据可视化管理

    • 剧本、关卡数据可视化管理

    • 资源数据管理

    • RPC接口的开放与关闭管理(迭代流程与应急处理)

    • 客户端组件埋点管理、应急管理

    • 资源管理(七牛云API)资源更新与CDN同步

    • 线上版本控制(后端版本控制,前端需要微信审核,无法快速迭代/回滚)

动画视觉部分

很遗憾我对这部分所知甚少,负责原画与动画的同学最近十分忙碌,所以这部分只好暂时省略了,以后有机会再补上吧。

结尾

目前这款游戏的开发已经完成60%,这次参赛作品姑且算是展出了一个demo吧,剩下的开发很大一部分精力要投入到构建一个好的流程平台上去。在这款游戏的开发期间,我确实学习到了很多东西,自己的技术也成长了很多,希望在今后的时间,我能够完成这款TCG式C-like游戏。如果你有任何疑问或意见,欢迎和我交流。

最后一次编辑于  10-31  
点赞 3
收藏
评论