cocos creator 项目总结一（框架概括）

1、开发背景

        以前一直从cocos2dx+lua开发。creator 一直只是关注和简单测试使用，所以本地项目是第一次正式的用creator 开发游戏，3D类游戏也是第一次尝试开发。所以可能有些地方的设计不一定是最优，如有更好方案欢迎留言角落。

2、项目基础框架设计

        2.1 项目目录结构

                1、word 整个游戏的加载入口，游戏中的代码和资源都以bundle方式管理，world 负责将游戏核心某块加载。

                2、modules （bundle）存放项目中所有的代码，统一做成一个bundle，内部再按功能模块分目录存放模块代码。（一开始设计时我是将代码按模块一个bundle一个bundle的存放的，但是后期发布小游戏平台的时候发现引擎 一个bundle包要是设计成subpackage 就不能把资源设置成remote asset 所以对代码的分包很不方便。另外跨bundle的使用代码对业务代码的编写也存在很多的不便，必须先加载bundle才能使用下面的代码否则发布就出问题，最终调整代码和资源分开管理）。

                3、resources 这个目录时系统内置bundle 所以里面基本只放了很少必须启动就需要的少量资源。

                4、common （bundle）游戏中所有公共资源的管理，再游戏启动时优先加载此模块。

                5、 xxxx (bunle) 各个功能模块按bundle包模式管理资源

        2.2  代码核心模块（MVP）

       1、项目整体结构时mvp的设计结构，这也是我原先cocos lua中一直使用的，当然随着个人一直使用和感悟和标准的mvp会有些个人自己的使用和设计上的调整（主要是个人觉得会更好用）。

        2、 M 数据层，此模块主要是负责，模块数据维护，模块与服务器交互（整个模块中只有M层能和服务器交过，所有模块都需要通过M层 service 才能访问服务器）。

        M 层主要由两个元素组成：

        1. Service 按模块实现的全局单例，根据模块会有不同的各种service，另外service 也是一个事件派发器，M层和其它模块的交互都是通过观察者模式来实现解耦的。按模块每个service 会实现各种业务与服务器通信的接口，并且也会持有模块一些长久需要保存的内存数据（比如玩家信息）。

        2、Model 是数据的一个封装，单独将一些相对复杂的数据结构封装成class 将数据的一些公共操作封装再model class 中。model 最终都归 service 持有和操作。

        V 层，由于creator 本身就支持了代码绑定节点，所以其实 界面prefab 就相当于view 层。

        P 层，绑定在prefab 上的脚本，主要是负责界面逻辑控制，和service 通过事件绑定接收数据层的变化，通过访问service 单例对象主动获取模块的数据和网络接口。

        2.3 核心代码组件

        1、ResLoader 资源管理器，项目中资源加载释放等管理。这里我的设计是单例+实例的管理方式，单例负责归纳总体管理，实例负责模块块化资源管理，这样每个模块的资源可以一个实例resloader 方便的一次性释放。当模块关闭时能够直接释放自己持有的resloader 就能快速释放模块加载的所有资源。对业务管理资源更加的简单方便。

        2、SceneMgr 场景管理器，这个管理器其实只是一个简单的封装系统的切换场景的管理和场景Resloader自动释放工作，方便每次切换场景能自动将资源清理干净。

        3、ServiceMgr 负责将 service 单例对象归纳管理，以方便日后需要service统一控制时使用。

        4、SoundMgr 游戏中的声音模块管理，封装引擎声音模块接口给业务层使用，封装目的也简单方便使用，也针对引擎频频api调整的防备。

        5、 StoreMgr 游戏中数据落地管理模块，给业务层封装方便合适的接口方便使用，也时将业务和引擎隔离的中间模块，目的也是 适应 以后的引擎接口调整和业务瓶颈时需要更换落地方案时方便统一处理

        6、UIMgr 游戏中的界面管理器，游戏中所有的弹窗界面都由UIMgr 弹出和管理。之所以统一管理是为了方便在复杂的弹窗逻辑中能够全局控制界面的层级和弹出规则。提供两中弹窗接口，单例弹窗（有的界面只能弹出一个，如果再谈的时候直接更新界面的内容），和普通弹窗。

        8、BaseUI  ui 组件基类，封装常用ui接口

        9、BaseView 所有弹窗界面的 基类，配合 UIMgr 的一些封装，实现界面的管理，也封装了一些常用公共接口

        10、BaseScene  继承自BaseView,所有scene 的基类，主要封装针对scene的一些公共接口

        11、BaseService 针对service 的一些公共接口封装

        12、platform 平台接口单例，会按不同平台实现不同的子类，在游戏启动时按当前平台实例对应的平台对象。比如Android，IOS, WeiXinMiniGame等平台

        13、Network 网络单例对象，负责网络层数据收发包解包等操作，本身也是一个事件派发器，收到到的网络包以事件派发的方式通知给 关心此包的Service

        14、UpdateManager 热更新模块，主要负责游戏热更新功能，只有原生平台才有效触发流程，其它平台直接跳过。

          2.4 战斗模块，使用 ECS 结构将逻辑层和和界面层拆分解耦。同步方案使用严格帧同步，之所以叫严格帧同步，是因为其实很多人在用帧同步的时候其实是一种结合了帧同步和状态同步的方式在做，会定期将自己的position信息通知给其它客户端，达到同步的作用，但是其实这种方式是不公平的，因为不同机型流程不同，会导致战局上的不平等，另外这种方式也特别消耗流量对网络要求也会更高。我使用的严格帧同步是，同步的只是关键操作帧。

接下来会按模块，将项目中一些比较重要的模块单独一篇一篇详细解析设计思路和实现方案代码