回顾创业三年多来公司客户端技术发展

   

　　 三年前智能机游戏爆发，我跟几个朋友也一起加入这个时代的创业大军！所幸现在我们还活着，后面都不知倒闭了多少像我们这种小公司，深刻体会到市场竞争的惨烈！背景简单说一下，下面直入主题。

 

第一年 ：

     三年前的手机游戏引擎选择真的太少了，基本就是cocos2d-x跟unity，但对于当时的硬件条件来说，unity还是有点慢，而且我们当初第一款想做2D游戏（第一款产品不敢乱来），所以就只剩下cocos了。但看了cocos的代码之后，还是觉得不是太合心意，主要是因为：

1、渲染写得不够好，连最基本的材质系统都没有，渲染流程也写得很死

2、跨平台代码不统一，WP平台竟然是独立一份，维护底层不是要搞死

3、没配套工具

4、风格等各种不喜欢 -_-

（PS：这里也不是说cocos坏话，当初还不够成熟，或许是不适合我们吧，现在发展成怎么样就不太清楚，3.2之后就没有关注了）

     正好我之前参与过引擎的开发，也经常关注一些开源的引擎（顺便推荐下：Urho3D很不错），虽然当时开发的引擎没有成功，但写个2D跨平台引擎应该也不是什么问题。最后也很快就把核心写完了（这里还得感谢cocos和黑莓的gameplay，帮忙解决了很多平台相关的问题），底层用C++，上层用lua，也搞了简单的材质系统，参考unity把hlsl通过工具转成glsl。这也是我们第一次做lua绑定（按游戏编程精粹7那篇文章改装过来的），感觉还是挺大胆的>-<，用lua的目的主要有两个：

1、动态更新，在运营阶段发挥了很大的作用，动态添加功能、fix bug

2、降低开发成本，不是每个人都能很好掌握c++，搞不好会失控

     工具方面就取了一点巧，场景跟动画就直接解析flash文件然后转化成引擎内部格式，UI编辑器用了SONY PSM的开发套件，跟flash一样的处理思路，虽然没有集成环境那么好用，但也还凑合。其他还做了一些周边的功能，比如用breakpad来收集用户的崩溃报告等。

     有些地方也没有做好，比如战斗设计，有些地方过于依赖填表；比如AI也没有做好，当初是很想用行为树的，但由于没能想清楚整体怎么弄最终还是用了状态机。整体来说对于第一个产品，技术方面还算基本达标吧！

 

     show一下我们整个工程的目录结构，工程量还是不小，回想当初没日没夜地干，还是蛮拼的，自己都差点被感动到了 : )

 　　

第二年 ：

     由于时空猎人、格斗江湖等格斗产品的成功，我们也跟风搞了一款！

     由于要做格斗类型，技术要求比以前的横版rpg上高了一些，感觉如果没有个像样的编辑器配合开发会比较难搞。那就面临是继续开发以前的引擎还是找别的工具的问题。自己开发的话，想要搞得好用估计要花很多时间，也没有找到合适的第三方工具，而且第三方工具太多了也麻烦，他们之间无法配合编辑；再者就是手机硬件发展特别快，按我们的预计很快3D就会成为主流，那自己再深化开发引擎必然会拖公司的后腿。各种权衡之后选择了unity，这款产品就当做为以后的产品打技术基础（虽然还是保守选择了2D项目）。

     unity编辑器确实很强大，做得好可以很好改进整个开发流程，这也是坚定了以后我们一直会用unity的决心！不过虽然上手容易，但就是坑很多，或者说有些东西不熟悉会比较花时间。

     由于有了第一个项目的lua经验，也尝到了lua在运营过程中能灵活对应需求变化所带来的好处，所以决定在unity中嵌入lua。很长一段时间都没有找到合适的解决方案，直到ulua的出现才得以缓和，主要是性能问题。AI方面也终于对行为树做了尝试，但可能是理解问题，运用起来还是遇到很多问题，主要是跟动画相关这块处理得不太好，更傻B的是unity这么多行为树插件不用，非要自己搞个外部的开源工具。总之可能是一开始接触这种组件化的引擎，思维还没完全转过来，设计上走了一些弯路！所以也就没啥可说的了！万幸的是，游戏终归还是做了出来，成功上线了。^_^

 

第三年：

     虽然第二个项目开发周期不长，但运营维护占据了将近半年时间，新项目又迟迟不能开始。虽然新项目没有开始，当时的市场3D游戏已经满地开花了，所以没有意外我们下一个项目也是3D，还好当初英明的决定，哈哈。

     刚好这时候有部分同事的时间空余了出来，我们决定对unity和以前的技术重新梳理一遍，改进开发流程。最终我们得出了一个重要的结论：要像开发单机一样开发网游！为什么这么说呢，总结一下我们在项目过程中遇到的麻烦：

     1、由于技术、美术、策划完全分开（目的是为了方便美术、策划开发、工程保密），导致全部东西的整合必须靠技术，就算是策划把人物属性从10调到100，或者美术修改了一张贴图，最终都靠技术把东西导进去才能生效。这就导致了迭代慢、周期长，而且也没有调动策划的主动性等各种诟病。

     2、毕竟lua还是有些性能问题（一般写UI逻辑都OK，但写核心战斗还是得好好规划下），但又希望能动态更新逻辑，两者相互矛盾。

     问题最大的还是第一个，主要是很大影响了开发进度。最后我们的解决方案是：所有专业用同一工程，技术不再担任功能的最终实现者，由策划来做，技术提供策划想实现其想法的各种工具，然后让策划来弄，充分发挥策划的创造力！ 以前的流程是：策划提需求->技术实现策划需求->策划验收；现在的流程是：策划提需求->技术提供工具->策划借助工具实现其需求。这个最明显的体现就在于：关卡、技能、AI、任务等系统，工具实现好之后策划基本想做什么就能做什么，不用再问技术，减少了沟通成本的同时也提高了产品的创新力。凡事都有两面性，首先需要策划有一定的逻辑能力（实践下来，只要策划是有心想做的，这根本不是问题，反而他们会很高兴）；其次要划分好哪些是策划做的、哪些是技术做的；再者就是要在技术层面上控制好策划犯错，不然会乱。

     总体实践下来还是令人满意的，这里也介绍下我们最底层的工具。其实就是借鉴了虚幻kismet、playermaker、uscript、cryengine3 flowgraph等工具，制作一个在unity平台上适合于我们自己的可视化脚步工具。那为什么要重新制作一个呢，第一个就是像uscript太复杂，playermaker不够强大，数据驱动不够方便（希望能动态更新，代替部分lua的功能）。有图有真相，以下是我们AI编辑的截图

有机会再详细介绍一下，就到这里吧。

 

欢迎大家共同探讨游戏开发问题，QQ：277911234