最近实现了一个天天领钱 H5 游戏，一期基础场景如下
在开发果园前，我们与其他部门负责游戏开发的同学沟通过实现经验： 框架层面：了解到他们使用的是 cocos creator 框架，他们提到 Cocos 框架由 C++ 迁移到 JavaScript，存在一些问题，因此新游戏使用并推荐 Laya。 通讯层面：后端交互使用的是 websocket 实现的，后端是有状态服务，前端需要关联 request event 和 response event，因此建议使用短连接。
调研 Laya 框架并体验同类游戏后，我们认为这类项目主要是运营活动，游戏交互较少，因此不一定需要引入 Laya 框架。原因还有：
- 团队技术储备都是偏向小程序/H5 游戏类的都没什么经验，产品侧给的时间比较短风险也大
- 游戏本身很简单(交互性很低)，判断不需要太复杂的游戏框架
架构分析
基于这些限制，实现方式如下：
- 美术同学做好果园需要的骨骼动画，
- 前端通过某种方式当用户点击的时候播放对应动画即可 剩下所有功能都使用前端技术(React)去做。
骨骼动画包括以下部分：
- 树的点击，成长，升级；
- 水壶的浇水；
- 奖励的弹窗
- 领水滴动画 这四个动画文件在对应时机播放。最终使用 pixi.js V5 绘制游戏画布，并封装 pixi-dragonbones 播放龙骨动画。
所以我们的整个架构就变成了下面这样三层的结构，底层就是主场景的绘制，主要动画的执行，中间层就是各种业务弹层，上层是动画弹层
游戏引擎篇
最初将三层架构封装在一个 Game 类中，游戏精灵仍以类似 jQuery 的方式创建。所以一旦有数据层面的变动，必须直接找到对应的精灵实例进行操作，比如坐标变化。数据变化时需要直接找到对应精灵实例进行操作，因此考虑使用响应式方案：
- 基于 RXJS+对象
- 类似 react 的方式声明对象，数据变化导致精灵属性的变化由框架维护
团队缺少 RxJS 及其配套运行时的开发经验，因此当时没有采用该方案。为复用已有 React 资产，开始尝试以 React 方式开发游戏，并实现了一个对应 ReactDOM 的 ReactPiXi 原型验证可行性。
继续完善的过程中，查资料偶然发现一个开源的方案 @inlet/react-pixi ，大部分都实现了，但是遇到点小问题，提了 pr 也很快合入了，最后就选定了这个库，至此游戏精灵对象和 dom 对象两层就在逻辑上合并为一层了。
游戏精灵的 react 写法
游戏对象和数据流可以通过声明方式关联。后续工作是以 React 组件封装原生精灵对象，方式与 React Native 中封装原生组件类似。
数据流篇
数据流使用了 MobX；复盘时发现它不适合该场景。mobx 的优势最大的就是响应式编程，当时使用 mobx 是想的当数据变化的时候，直接响应的回调操作游戏精灵，类似下面的代码
autorun(()=>{
const sprite = new Sprite();
sprite.y = store.tree.x;
sprite.x = store.tree.y;
})该回调只在 tree 的 x 或 y 属性变化时执行，用于关联数据和对象。改用 React 架构后，绑定关系已在 render 函数中完成，因此不再需要这种写法。考虑到 MobX 可以与 React 集成，当时没有更换数据源，仍沿用了 MobX。
MobX 可用于普通业务开发，但多个动画对象联动时，流程难以表达。比如浇水动画播放到2s的时候播放进度条动画，等服务端返回的时候播放数升级动画同时更新主场景，然后升级2s的时候出弹层动画。整个流程使用mobx就比较难以描述，还是要在业务层代码写很多离散的逻辑。RxJS 可以把同步、异步、推送和拉取操作放入同一条数据流，因此更适合这种场景。
MobX 开发者工具只支持简单的数据流变化。为监听这些变化，需要将每次 state 操作都放入 action，开发方式接近 Redux。MobX 的 store 是离散的，难以统一镜像上报，也增加了问题排查难度。
MobX 不要求显式关注更新位置，只有读取了变更数据的组件会更新，因此通常不需要编写 memo 一类的处理。
资源管理篇
资源管理的诉求
- 支持换肤，动态换肤/静态换肤
- 支持自动图集(雪碧图)
- 支持自动有损压缩
- 支持webp
- 最好能做到设计自行传图片，应用后线上自动生效，不需要研发介入
资源管理最初计划通过托管网站减少设计与研发之间的依赖，但流程和版本控制较复杂，因此暂时搁置，后续仍需探索。
新的方案暂时不满足第五点，满足前四点就只需要提供一个本地的构建工具即可，我们按照目录进行了约定，将游戏内使用的资源分为三类：
- 文案资源
- 颜色资源
- 静态文件资源(json动画文件，图片文件等)
目录结构：
所有主题默认继承base，如果存在同名的就覆盖base里面的配置，其中比较特殊的是files下有sprites目录，这个目录下面每个文件夹都会被自动打包成一张图片，最后处理完所有资源后会生成d.ts和json两个文件。项目中实现了一个资源替换的模块统一处理了游戏内皮肤替换和H5皮肤替换
这套方案支持团队在缺少游戏开发经验时开发游戏，复用已有前端资产，并为后续业务迭代提供基础。
文档
https://juejin.im/post/5c563a4ef265da2ddb293ba3#heading-2 https://github.com/Zainking/LearningPixi#takingitfurther https://reactpixi.org/components/container#props
