目的：
- 顺应金主爸爸的希望，要山寨COC（部落冲突）
细节：
- 使用javascript作为UI的语言。
- cocos2d-x作为游戏引擎。
- 服务端是完全重写的，毕竟手游的服务端基本就是用来纯点数据。
- 渲染采用的基于swf的架构，也是完全重写的。
- 客户端逻辑重新架构。所以当时还專門学了设计模式。客户端非UI部分主要分为三层结构：
- 渲染层：怎么播放swf文件，包含两个实现类
- 直接播放COC原始资源的渲染层实现
- 播放我从新设计的基于swf的实现
- 渲染逻辑层：怎么播放不同角色的不同动作，跑步，攻击什么的。也包含两个实现类。
- 正常渲染
- 用于给服务端调试用的模拟器，用MFC实现，只有简单的符号显示。
- 逻辑层：逻辑层只用给渲染逻辑层发送各种动作的指令，比如从a点跑到b点。
- 渲染层：怎么播放swf文件，包含两个实现类
- 后面准备移植winphone手机，但里面支持javascript的模块没有winphone的版本。所有有两个选择：
- 把javascript全部变为c++。我当时拼死带病弄了一个周末，把基础代码写出来了，然后证明我2天可以完成一个界面。但是大家觉得还是不现实。
- 自己把支持javascript的模块在winphone中编译出来。因为当时我的程序眼自我修养还不太高，所以研究了一下就放弃了。现在看了应该问题不大，我都移植了那么多程序到ios上面。编译和链接的原理也就那么一些。
- 还做了有实时互动的玩法，另外一个老程序员强烈要做的。他一个人做完后，还上线测试了下。我倒是感觉还不错，不过后面还是其他人找个总借口关闭的这个功能，什么手游越来越亲度化呀。但是发展到今天，手游去走向了极度重度化。当时那个实时功能如果一直做下去，真的还是个卖点。
- 后面我还加入了塔防的玩法，但是其他人也没兴趣，我一个人肯定职能做个demo。所以demo出来后也没下文了。
- 美术资源采用的外包，整个和外包的对接：需求提出，质量检查，数据倒入等都是我做的
- 从外包拿到3dmax文件
- 自己调整每个模型的锚点什么的
- 3dmax中手动隐藏和现实不同模型，实现不同等级的效果。然后渲染出不同针的图片。有的动画还是骨骼动画，所以身体的不同部位还要单独渲染输出。
- 输出的图片全部导入flash中，调整一下后输出成swf文件。调整内容包括加阴影，给不同动作打标签等。
- 使用自制的工具把swf转换为自定义的格式，因为swf的解析比较费时间，所以最后还是使用了一个自定义的格式。
- 整个上述流程只需要普通的美工就能完成，这个应该是我设计的这套流程最大的优势。
- 渲染效率提升。主要方法就是调整渲染批次。我也试图使用GPU和CPU在不同线程。但后面发现这个逻辑实在复杂，而且最好情况下也就提升一倍效率。所以只是做了一个demo就没有继续了。
- 游戏发布后，一些游戏运营和宣传的事情也要我们自己做。但发现毕竟我们不专业。所以后面这个项目就没有继续了。
- 3dmax渲染出来的各种图片
- 在flash中进行拼接。其实这些图片的位置在渲染时都是对其了的。所以flash中不用调整每个图片的位置，只用把不同图片填入对应的时间帧上面。
未来改进：
- 最终我设计的渲染系统的帧率还是比原版COC差一节，即使是使用我逆向出来的原版图像资源。当时真的觉得是找不到什么继续提高效率的方法。不过现在因为对渲染和显卡更加了解了，感觉还是有很多提升空间的，比如材质的存储的缓存的类型等等。这个真要做还需要对游戏做更多测试，明确瓶颈在哪里。
- 当时真的是在游戏策划和运营上面很缺乏。其实那个时候的手游界虽然热钱很多，但的确还是手游的一个初期阶段，和现在的手游的规模以及和当时的手游水平的差异来看。也就是我们当时其实起步还是挺早，还有很多机会。
- 如果还要继续在游戏圈，当时有两条路可以走：
- 做一个全能的制作人，本身我的知识面比较广，程序美术都懂，游戏点子上面自我感觉有很多不错的想法。
- 只专研渲染，作为一个团队的重要成员。
- 当时我们采用了所有人都平等的关系。毕竟我们团队才4个核心的人。但感觉最后失败也是失败在这个上面，因为所有事情，不管是策划，程序，美术，所有人都要来管。最终结果就是好多好的想法实施不下去。因为新的思路总是一开始不被其他人接受。所以一个团队里面一定要有各种专才，自己负责的事情其他人就不要说太多。我们当时4个人都是程序员，其他方面的事情就你一句我一句，最后什么也变化不了。