回到这个论坛的时候，我带来了一种说法，可能当时没有人很在意，那就是——cocos2dx并不适合游戏研发。可能当时大家只当笑话一看，可是时至今日（其实也没几个月），物是人非，cocos2dx的用户已经大幅度减少，无数人转投了unity的怀抱，不论原先是用air的、还是starling的或者本身就用cocos2d(x)的，都选择了unity。那就竟是什么导致了这样的格局呢？其实深入思考的话，其中有很多问题，我们可以将他们举一反三、反思到游戏项目研发和设计思想中去。
1，好的内核与好的产品间有着巨大的鸿沟
无可否认，cocos2d和unity都有很不错的内核，不论是渲染还是内存管理（这点说的有点心虚……）上都是很不错的，我甚至敢说这两者旗鼓相当。但是为什么大家更多的愿意选择unity，核心原因之一是，unity在开发上有一个非常友善的环境。我个人没有使用过unity是真的，但是我知道unity在开发游戏ui，和一些动画机制上，其便捷性远高于cocos2d。我们要知道当你用cocos2d去写一个界面的时候，那种痛苦简直是无法承受的，虽然他们提供了一些编辑器，但毕竟编辑器能适应的只是做一个网页，而作为一个追求高品质的ios游戏，你的界面必须是“动起来”的，而不能象也有一样，要么开启要么关闭，都是一瞬间，连个动画过程都没有。因此在实际开发过程中，unity占据了绝对的上风，虽然他们开发出来的东西，效率上几乎是相当的。
由此，我们必须反思——游戏研发和设计中也有类似的问题，很多时候我们的游戏有了一个良好的内核，在玩法规则上可能非常棒，但是游戏产品成绩却很糟糕，其实问题的关键在于那些非内核的工作上。你要明白，一个好的游戏想法实现出来成为游戏内核后，那只是游戏的10%，可能都还不到，也许外行或者玩家会觉得一个游戏产品，只要“好玩”就够了，大道理没错，可是好玩不能排除的因素太多了，除了规则好玩，你还要注意很多用户友好度，所谓用户友好度，不是说让你顺着玩家心里去设计规则，而是顺着玩家习惯去设计用法，比如Ios游戏中，竖屏相对横屏会有巨大的优势，竖屏中你还要考虑如何兼容或者解决左右手使用习惯的人群等等等等，你的界面是否能在最少的点击次数、最短的时间、最顺畅的流程下达到用户期望的结果？你的游戏体验是否第一时间能够通过操作等传达给用户？这些问题都是决定胜败的！正如cocos2d最后败给（好吧，没人承认也没人宣布，我们只看大潮风向）了unity的关键所在。
好的游戏产品，内核（核心玩法）很重要，没错，但是内核以外的东西更加重要，所以做游戏研发工作，千万不要抱有“想法至上——我能设计的好玩就是一定是个好游戏”的玩家思想，做产品，有太多的东西值得去探索去品味。“台上一分钟、台下十年功”很多时候你看到的一个表现还不错的界面，短短几秒钟你都没有在意但确实觉得至少没什么不好的地方，这几秒钟背后可能是策划、程序、美术几个小时的共同努力换来的。
2，只有聪明人才能玩的游戏也许是好游戏，但不会是普及的游戏
cocos2dx的研发思路是传统的oop，而unity则使用了一种component驱动的逻辑，我的老大也自创了一套entity system结合了2者的优点，尤其是Component驱动的思路，设计了一套entity system，因此虽然我没有使用过unity，但是大概还是了解了Unity的思路和我们现在的做法是非常相似的。
对于游戏策划来说，如果你有一点基础的程序知识，深入的想一下，你就明白，oop对于程序的要求其实是非常高的，如果在初期没有想清楚结构，或者遭到策划的一再变更开始无尽的修改，整个项目的代码立即就失控了，最后你可以看到很多“WriteDie”（这个词我们用来描述一些为了特殊需求而写死的代码）的垃圾，而这些垃圾又往往会引申处无数的magic number（一些带有极其特殊含义的数字，当你改变他们值的时候，你的程序也许突然就崩溃了），最后整个游戏程序一发不可收拾，成了包装精良的大便。而unity（或者说我们正在用的entity system）的思路很清晰（我就用我们的entity system来说，unity我真没深入的了解过），system就是指挥中心，指挥所有士兵(entity)运行，而每个士兵有很多的标签(component)，记录了他的属性和成为他归属于哪个司令部管理的象征，在你编写程序的时候会非常容易的添加和维护一些东西，你不用过于担心新追加的需求，也不用过于在意初期没有想好的东西（但是你必须还是要先有个大概的框架，这个必须是由策划一起组建的逻辑框架，不然项目到后来是会越做问题越多的，任何项目都是）。
这样一来你不难看出，其实cocos2d对于程序的要求是“更聪明”，因此他遭到了弃用。在游戏设计中，我们也应该反思，我们的很多设计是否过于要求玩家“太聪明”，这与要求玩家skillful（我不知道用中文表达这个词汇是多么麻烦的事情，所以直接用了这个英文单词）是截然不同的，skillful的出发点是玩家具备一定的熟练度和技巧性，然后合理的运用、尽量避免失误；而要求玩家“更聪明”，则是从概念上出发，需要玩家具有太高的抽象能力、空间想象能力。Eve受到冷落的原因有很多，很多人归纳是题材（星球大战）、很多人归纳是规则残酷（事实上比起金庸OL死一次掉1级最高武功、甚至因此成了残废，有学点的打不过，打得过的没学点，几十级的账号彻底玩不下去了，练1级可能几天，死一次1秒，所以当时开始有了“秒杀”这个词汇，来说要“仁慈”多了），但事实上Eve的很多地方过于要求玩家的抽象能力，过得了这个层面的玩家很好理解这个游戏，过不了的就是玩不了，包括EQ也是，并不是系统复杂这么简单，更多的是因为一些概念需要玩家的空间想象力。而要求玩家“更聪明”的另外一个直接表现就是我曾经在写一个SLG的AI时候犯过的错误，一些AI的行为聪明到玩家无法直接理解，需要经过好几个回合才能发现妙处，不够直观的聪明、超过人类太多的聪明、超越人类普遍的思维能力等都是要求玩家“更聪明”的表现，请不要在你的游戏中去挑战玩家的智商，这是自寻死路。降低这些难度也是降低游戏门槛，做到“上手容易”的关键所在。
3，传承性或者可复用性是楼梯边的扶手
有一个有趣的说法——现实生活中，你在爬楼梯的时候，你对于楼梯边的扶手熟视无睹，你甚至不会去使用它，但当把扶手拆除的时候，你在楼梯上的心情就大不一样了，虽然还是不会有任何危险。虽然这个说法更多讲述的是心理方面的问题，更多的是人在不同环境下不同的心态之类的，但是你也可以看到，一些熟视无睹的东西会多么重要，就像楼梯的扶手，你不能不造它，虽然从逻辑出发他根本没有什么意义（就像1中所说的，核心功能就是能上下楼，没错，功能完美，但他不是好的产品，因为它需要扶手来确保他看起来更安全，虽然安全性并没有本质地得到提高）。
事实上我们换一个思考角度去看这个扶手问题，在游戏开发中，包括编写程序时，我们都会忽视一个问题——那就是项目的传承性和可复用性。cocos2dx用的是oop思路，虽然你从书本知识上可以得到很多关于oop的好处，包括他的精髓是继承之类看似很有可复用性的地方，可是现实是残酷的，没有一个oop的项目到了“2代”不是从头写过的，哪怕设计上完全一致的东西。最初我们认为这是程序员缺乏项目经验，可是长久以来并不是程序员没有长进，而是游戏的变化太多太快，如果你不在开始就像可复用的东西，oop下就很难再沿用了。但事Unity（或者说我们的entity system）则不一样，当项目完了之后，我们可以回头再拆分component和system（这里是要求策划加入Coding的），分析出一些可服用的环节产生出template，来大幅度降低一个游戏开发的时间。最初我们用cocos2dx写一个塔防游戏，纯研发阶段逻辑用4小时完全完成，界面我们要用上20天左右完成，毕竟我们做的是产品，不是做个看起来能玩的东西就完事儿了；几个项目之后，我们做一个植物大战僵尸类似的游戏，逻辑还是用4小时，界面还是用了20多天。但是转战entity system之后，最初一个横板动作游戏（忍者龙剑传3FC版）类似的游戏，逻辑用了3天，其他方面包括界面用了1个半月；而现在我们做一个类似的游戏，逻辑只需要3小时，界面什么的制作如果从我们的“库”里能够找到，那基本上也是几天就能搞定。
可见，游戏研发中的可复用性是会带来巨大经济效应的。那么反思到游戏设计当中，我们也必须思考好很多可以复用的设计，这样才会造福团队（这也是策划的核心价值之一，不然你一个策划没有程序员工资高那是理所当然的），最典型的可复用的甚至可以提高到可传承（不仅你自己可以复用，全行业都可以沿用）的就是一些数学公式，但是可惜的是，整个行业内现在传承的是神仙道、是打孔、镶钻、升星、附魔（这个几乎没有，因为存在“技术难度”）。
总结
游戏研发没有这么学科，因为他至今才短短数十载，且得不到人们的认同，在影视等其他娱乐手段的“威胁”下生存是很艰难的，因此我们没有太多可以直接阅读后学习的心法，我们只能去其他领域寻找经验，生活中有很多范例暗示着我们如何搞好游戏，一个策划要学会观察和分析事物，用于研发工作中，为团队创造价值，这是策划相比设计师要担起的更高的责任。