作为公司的游戏主程，当我们要使用Cocos Creator主导开发某个商业项目时，我们必须要注意哪些事情？我总结一下，抛砖引玉,来引发大家的一些深度思考。
思考1: 为什么项目要采用Cocos Creator游戏引擎来开发你的游戏项目?
关于此问题主程应要做一些深度的思考,为什么你的项目中要采用Cocos Creator来开发，看中了它的什么？目标平台主打市面上主流H5平台方案成熟, 包体小,引擎免费,团队一直积累Cocos技术等。项目中有哪些点使用Cocos Creator有技术风险？
渲染方案: 3D渲染效果,光照效果,Shader算法能否达到项目要求;
性能方案: 游戏中的极限情况下，算法性能等是否达到设计要求,
第三方方案: 项目中可能需要使用开源的一些方案，是否有针对Cocos Creator的实现等。
…
针对有风险的技术点，在项目确定使用CocosCreator之前，要快速的做好技术验证。各方面验证通过了，再正式确定使用Cocos Creator来开发项目,而不是一拍脑袋就决定。
思考2: 采用哪个版本的Cocos Creator来开发新项目?
新项目采用哪个版本的Cocos Creator? 这个也需要主程做一个深度的思考。比如,基于项目成本的考虑，之前是2.x所以还是采用之前的版本? 2.x不再维护了，尽快切换到3.x,切换到3.x以后我们用哪个版本呢？这时我们可以花一天左右的时间做个预研，预研包括了: 前面核心性能的demo验证,各平台打包工具链验证等。一般我们尽量选取比较新的出来时间超过1个月的版本，同时我们内部选定版本以后，可以和Cocos官方沟通一下，综合一下专家的意见。
思考3：项目主要的技术难点与方案选择?
确定好项目使用的版本以后，把接下来整个项目中要用到的技术库与插件等整理好，把最终的一些技术方案的选择确定下来,整理这些方案到我们的项目中。进一步验证项目可能要使用的方案的成熟度，比如寻路导航，RVO，物理引擎等。
思考4: 项目使用Cocos Creator团队该如何协作？
游戏项目所设计到的角色：程序，美术，策划，测试。他们之间如何协作，主程要根据项目来把协作的协同方式制定出来。美术如何分工，美术资源导出后如何交付，美术资源如何做好版本管理，策划案，数值表如何交付，如果数值要修改调整改如何处理，如何协同。测试如何编译最新的测试版本，如何编写测试case,如何做好bug提交,如何迭代版本。程序如何修正bug,如何做好bug记录方便回溯,程序如何分工，如何协同。对外demo版本发布规则，客户正式版本该发布与管理等。这些协同方式与规范我们要思考清楚。
思考5：制定开发原则与Cocos Creator的框架搭建?
把之前做的一些技术验证与第三方代码库等整理到项目中，并调整好目录结构，使得项目的目录结构清晰。思考项目的目录结构如何划分能尽量减少大家的相互干涉与影响。
制定开发原则与规范，哪些方法是可以用，哪些方法不能用。如:
命名规范: 成员变量采用驼峰命名法，函数的命名首字母大写区别系统API函数;
美术规范：设计分辨率，九宫格图片等。
GUI制作规范: 图集基于功能来打包，尽可能地节约drawcall;
禁止：在预制体，场景节点中直接挂逻辑脚本;
在动画中添加一个脚本事件;
在UI代码里面直接调用策略接口;
…
这个就根据每个公司的组织项目的哲学和设计来制定一些规范。
思考6：如何做好项目的质量把控与性能检测?
代码的质量主要还是团队的水平参差不齐导致的，所以要把控好代码质量，还是要做Code Review。了解整个项目的每个模块的大体的实现思路和细节，调整那些明显实现有问题的代码，这样人员有变动等主程始终知道整个代码的实现和相关特点。
从项目的第1个测试版本开始我们就要做好性能检测，看看是什么时候出现的性能问题，看每个版本的一些参数，不要到上线的那天再做性能测试，发现内存爆了，还不知道整个项目的内存分布等。所以项目应该一直做好性能检测，如每个礼拜做一次性能测试与分析。
思考7: 如何做好团队的技术培训与完善文档?
时间总是挤出来的，可能很多开发者不注重新人培训，团队氛围的建设。作为负责人，新人培训，技术交流这块还是很重要的，老带新，让团队更有战斗力。同时让新人更有激情活力。文档的完善很多开发者可能不注意，或者误解为是注释，其实不全是，抓主要的一些文档如项目如何跑起来，有哪些流程规范，项目使用了哪些技术等。并不是没有意义的注释。完善文档的目的就是让新招的人进来，1个礼拜就能上手改代码，很快能运行公司的项目。
思考8：哪些可以考虑重用，哪些可以不用考虑重用？
属于提供机制的代码可以考虑重用，比如游戏框架，热更新，项目组织方式等。属于独立的工具模块可以考虑重用，比如寻路导航，SDK等。游戏逻辑代码不用太多的考虑可扩展性和重用性，真实的解决游戏策划的需求即可。
思考9：项目测试case与Bug记录?
对于大型复杂的项目还是要做好测试Case与Bug记录，这个过程中反复出现的bug,哪些难以重现的bug,这些我们都做好详细的记录，方便我们快速的定位疑难杂症，同时主程要把这些都记录起来，遇到的时候能想起来，同时bug记录要对应好解决手段，产生bug的原因。
思考10：问题点快速定位?
如何定位到问题，是快速解决问题的关键。也是项目后期排查难bug的关键，所以我们要从一开始就要带入这个问题来思考。比如我要测试性能问题，如何方便地能屏蔽掉业务逻辑代码，物理引擎代码等。
可以考虑做游戏的”录像”机制，遇到比较难以复现的bug时可以做好录像采集，然后回访录像来重现bug解决错误。
最后的彩蛋：Cocos Creator常见的性能优化方向:
1: 包体优化方向:
代码体积优化：不用的代码包做裁剪
图片体积优化: 使用压缩工具压缩图片;
字体体积优化: 使用字体裁剪工具裁剪不用的字模;
帧动画体积优化：换成骨骼动画,减少帧数，减少体积大小;
声音文件体积优化：改变采样率，声道等;
打空包;
…
2: 性能优化方向:
文本drawcall优化：改变文本的模式为Bitmap,让多个Label可能合批;
图集drawcall优化：将同一个功能同时使用的图片放一个图集，尽量减少drawcall;
BitmapFont代替适量字库优化: BitmapFont的性能要比矢量字库要好，但是字模有限;
spine骨骼动画: 可以开启预先Cache模式，把骨骼在每帧的结果保存到纹理里面;
3D模型drawcall优化: 让3D模型用同一个材质， Shader,纹理，增加节约drawcall合批可能。
3D动画组件的Baker模式: 把3D动画的纹理采样Baker到纹理中，来替代动画组件的采样计算;
物理引擎优化: 修改物理引擎迭代参数，用性能更好的物理引擎，用其它方案替代物理引擎的使用;
寻路等搜索问题：优化搜索解构，减小搜索规模,基于九宫格AOI区域搜索四叉树场景管理等。
Shader优化: 优化纹理采样，优化Pass通道,优化阴影光照计算等。
UI优化：防止Label打断了精灵Sprite的合批,可以把所有的Label单独做到一个父亲下。
机型适配优化：根据机型的性能，分成中高低档，结合性能来定制游戏效果。
节点池优化：大量创建与销毁的物体可以通过节点池来优化;
渲染管线优化：可以使用延时渲染管线在某些情况下获得更好的性能;
时间换空间，空间换时间的经典优化:很多问题的本质就是靠它;
…
3: 流程标准化方向:
SDK接入流程标准化;
多平台打包发布流程标准化;
热更新流程标准化;
用户登录系统流程标准化;
…
End:
今天的分享就到这里了，希望大家有所收获。
