第一个cocos creator项目经验

ps：第一次写，不太会，简单做一些分享，不太对的望各位大佬加以指正

一、项目准备

1、项目结构

1、层级管理器

GameMgr类：用于管理整个游戏的流程进行，可放入全局使用例如角色对象池等等资源；

PlayerData类：用于记录管理用户数据；

resourcesMgr类：用于资源预加载等等管理

plugIn类：用以调用个人开发过程中编写的插件，以及在工作过程中收集到的插件；

SDKMgr类：用于对接各个渠道，获取服务器上数据；

UI管理节点：存放所有游戏中的UI节点；

2、script文件夹

1、对应管理类脚本与最外层；

2、GameObiect文件夹：用以存放所有游戏对象对应脚本；

3、SDK文件夹：用以存放SDKMgr，以及其他开发所提供的脚本；

4、UI文件夹：用以存放所有UI脚本；

5、暂时script中未有其他需要添加部分，后续需要添加可根据其用途确认层级或新建类别文件夹

2、游戏制作思路

1、依据个人所作项目架构做好开发准备；

2、依据游戏特性，写出对应对象基本逻辑（例：本次开发为弹珠游戏，首先构思即为使用碰撞系统，以及刚体来完成弹珠与球桌，场中怪物之间的碰撞以及碰撞后运动轨迹）；

3、完成基本逻辑即所谓游戏基本的DEMO后，开始对游戏细节进行优化，对应扣分得分，判定胜利，展示效果，结果展示等等；

4、通过对游戏基本开发完成后对其进行对应性能优化（游戏中的重点，影响游戏体验，游戏运行效果）。

3、项目收获

经过本次项目，基本了解了整体游戏开发的思路，了解了Cocos 大部分组件的使用，学习到了性能优化的很多方面的知识。

1、了解游戏开发性能消耗占比：Cocos creator 2D小游戏运行过程中，性能消耗占比最高为DC值，其次就是物理引擎所带来的消耗，开发过程中能尽量不适用使用物理的情况下尽量不使用物理；

2、完善使用对应插件、等等工具，简化开发步骤；

3、学会使用对象池、shader、合图等方式对游戏性能进行优化；

4、学会使用火山图来针对性解决消耗比较大的问题，由于游戏中弹珠数量过多（测试时达到上万），对其采用合批处理的方式降低处理事件数目；

5、在本次开发的过程中，让我收获最大的就是这一点，因为对于弹珠需求数量较多，物理系统承载不了，在后续的优化过程之中，去除掉物理系统进行开发，预计是两种解决方案：a、采用空间细分形式，将地图上分为若干块，分块来进行碰撞判断，而后手写弹珠运动轨迹；b、保留碰撞检测，去除刚体，手写运动轨迹。两种方案进行选择，首先进行测试，去除刚体，保留碰撞检测后，弹珠数量能够从有刚体时只能容纳两三百个，到现在能容纳八九千，性能已经大大提升，a方案消耗一天时间实现不了暂时取消使用，最终使用b方案进行优化，球的碰撞运动轨迹则根据数学中的方程等等形式算出其各个方向上的分速度来完成其运动轨迹。

4、性能优化（性能优化的方式有很多，本人第一个项目，以后继续收集，本次为记录过程中使用到的方式）

（1）使用合图资源

   利用合图资源构建场景以及游戏角色，静态资源均可采用合图方式加载，可有效降低drawcall数值，推荐合图软件[texturePacker可根据](https://www.codeandweb.com/texturepacker)使用的引擎生成不同的合图文件，也可使用Cocos Creator提供的合图功能。

（2）使用对象池

    使用对象池可以有效的避免因重复创建销毁导致的一些不必要的性能损耗，当在小游戏开发的过程中某个节点需要大量重复创建使用时，不妨尝试使用；当节点出现较少，且上面挂载有延时或者持续运行的方法时，不建议使用对象池，节点进入对象池，节点方法停止运行，当再次从池中取出时，方法会持续运行，当节点有类似情况时，务必先重置节点，再入池，或者从池中拿出节点，立即重置。（个人正在编写SDKMgr，想将这些开发同类型的全部封装进去，目前还不完善，完善后分享出来忘各位大佬指正）

（3）能避免使用物理的就尽量避免使用物理

   物理系统相对应来说太耗性能了，两款DC值，帧速率均差不多的情况下，物理系统相对应的就会更耗性能。

（4）分帧加载

同时需要多个添加的资源建议对其使用分帧加载的形式

（5） 学会利用浏览器反馈的信息

例如：浏览器反馈的火山图，可以精确的了解到项目每一帧执行的方法，以及其对应的时间等等信息，从而更好的编写项目代码

小结：

推荐软件：

合图软件：texturePacker

简便工具网址

转化配置表