算起来，加入触控已经一年。
回顾过去的一年时间的成绩，自己是相当不满意的。当然，原因都在我这个团队 leader。赶在马年最后几天，对过去一年做一个总结。找到存在的问题，才能在来年做得更好。
<br />
总结过去一年最大的问题，有几点：
- 细节没有做到极致
- 错误的技术选型
- 未能调和内部利益冲突
最初，我设定的目标包括：
- quick-cocos2d-x 继续扩大用户规模
- 场景/UI编辑器
- 游戏服务端
而最终结果是：
- quick-cocos2d-x 的发展遇到瓶颈
- 编辑器项目取消
- 游戏服务端延迟一年才产品化
<br />
为什么 quick-cocos2d-x 的发展会遇到瓶颈
quick-cocos2d-x 是一个基于 cocos2d-lua 开发的定制版游戏引擎。在推出后之所以受到开发者的欢迎，归根结底就是“好用”二字。但在加入触控后，虽然对产品做了很大程度的优化，但在细节上却没有继续提高。
游戏引擎的核心是功能和可靠性。但在开发者每天使用产品的过程中，围绕引擎做的细节工作却决定了开发者对游戏引擎的使用体验。
quick-cocos2d-x 出现时，cocos2d-lua 只能说处于“可用”状态。而 quick-cocos2d-x 借鉴了 Corona SDK 的易用性，封装了更简单易用的开发框架、提供了高效的模拟器，以及全中文的文档。这三点让 quick-cocos2d-x 达到了“好用”的程度。
从“可用”提升到“好用”，quick-cocos2d-x 靠口碑传播获得了大量用户。而要从“好用”继续提升到“很好用”，就需要在细节上继续下功夫了。正是因为没有做到“很好用”，所以 quick-cocos2d-x 的发展遇到了瓶颈。
<br />
举一个最简单的例子：如何让开发者更快的在模拟器中打开项目。
开发者每天开始工作，第一件事就是打开代码编辑器，第二件事就是启动模拟器。在编辑器中打开项目、编写代码；在模拟器中打开项目、查看效果。
现在几乎所有的编辑器在启动时，都会自动打开上次退出时没有关闭的项目，并定位到退出时正在编辑的文件和位置。这其实就是让用户以最精简的步骤进入工作环境。
但是 quick-cocos2d-x 的模拟器却没有做到这个功能。每次启动模拟器后，还需要通过菜单、对话框等步骤，点上好几次鼠标才能打开项目。如果不小心把模拟器关闭了，下次启动模拟器还需要重复上述过程。虽然每一次也就不到30秒，但这种无趣的操作每天重复很多次时，就会让用户觉得难受了。
所以后来我为 Windows 版的 quick-cocos2d-x 模拟器添加了创建快捷方式的功能。开发者用模拟器打开一个项目后，可以通过菜单创建一个快捷方式放到桌面上，下次双击快捷方式就可以启动模拟器并打开指定项目了。后续还增加了最近打开项目列表菜单，进一步简化了打开已有项目的操作。
但这些功能其实都不如增加一个“启动时自动载入项目”选项。这样每天可以为一个开发者节约数十次鼠标点击，用户体验会有明显的提升。
就是这样一个小小的功能，不是做不到，也不是不能做，而是没有想到。那为什么没想到呢？还是“没有用心”。
<br />
创造 quick-cocos2d-x 的初衷，是因为我在用 cocos2d-lua 做游戏时觉得不好用。所以我以改进自己团队的使用体验为出发点，完善了 cocos2d-lua，并推出 quick-cocos2d-x。
而当我加入触控后，没有再开发游戏，想得更多的是如何做一些高大上的产品。结果就忽略了在细节上继续提升产品体验。
经常听到看到说做产品要“走心”，其实自己也犯了同样的错误。
<br />
为什么编辑器项目会取消
在 2013 年年底，我就决定要做一个编辑器。因为当时我的游戏团队已经为一款塔防游戏开发了一个功能很强大的编辑器，可以基于这个塔防编辑器开发出一个通用编辑器。如果按照原本的设计，那么 2014 年肯定能够看到一个出色的编辑器。
可惜在加入触控后，觉得以前那种“土法炼钢”的编辑器太low了，必须做一个高大上的。所以在技术选型时，没有做深入调研就选择了 Qt。
毫无疑问，Qt 简直堪称“天坑”，活埋一堆人都不带痕迹的。不过这真不是 Qt 的错，还是自己的草率决定导致整个团队在 Qt 上浪费了整整 4 个月时间后，发现 Qt 真不行。
而回头再看，当初的“土法炼钢”其实才是真正正确的路子，但此时由于各种原因编辑器已经没有继续开发的必要性了。这完全就是一个盲目追求“高大上”导致错失市场时机的经典案例。
编辑器项目的取消除了导致资源浪费，对团队成员的积极性也有明显影响。因为大家为了一个目标付出几个月的努力后，却发现此路不通，这种挫败感是非常强烈的。虽然后来我们找到了新的产品方向，但也花了一段时间大家才恢复过来。
~
为什么游戏服务端延迟一年才产品化
在加入触控之前，我就已经有了一个开源的游戏服务端项目，可以让开发者使用 Lua 脚本语言来编写游戏服务端逻辑。
这个项目最大的好处就是统一了客户端和服务端的开发语言，在解决接口一致性、共享逻辑代码上具有无可比拟的优势。所以这个项目开源后，马上就有其他开发商也用在自己的游戏里。而在市场上，专用的游戏服务端框架结合第三方云计算平台还是空白，如果借鉴 heroku.com、LeanCloud、APICloud 的模式，是有很大机会的。所以加入触控后，我极力想推动这个项目的立项。
让人郁闷的事情在于各种复杂的人际关系和内部利益冲突，使得这个项目不但无法立项，连基本的开发人员投入都争取不到。所以接下来的一年，游戏服务端项目一直处于一种“沉默”开发状态。
随着年底时，底层的大规模调整完成，以及文档、开发工具、监控运维工具的完善，这个项目才真正接近了产品化的程度。
万幸的是一年后市场上还是没有类似的产品出现，所以机会仍然存在。
<br />
2015羊年
在触控的一年，对我个人来说其实是有很大收获的。熟悉了如何在大公司的环境里争取机会、如何与其他团队协助、如何平衡利益与冲突。所以接下来的一年，我会坚定的推进预定目标。
但要达到目标，还需要做好下面几点：
- 做减法：裁减掉所有非核心目标、将没有技术含量的工作尽可能自动化。
- 注重细节：在产品设计上，更加用心寻找细节优化点。
- 提升管理水平：更完备的前期调研，避免技术选型错误。制订更细致的研发计划，减小有限人力资源的浪费。
- 争取资源：更加积极主动的为团队争取更多资源，不管是人力还是PR支持。
-EOF-
