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

   
   三年前智能机游戏爆发,我跟几个朋友也一起加入这个时代的创业大军!所幸现在我们还活着,后面都不知倒闭了多少像我们这种小公司,深刻体会到市场竞争的惨烈!背景简单说一下,下面直入主题。
 
第一年 :
     三年前的手机游戏引擎选择真的太少了,基本就是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
原文地址:https://www.cnblogs.com/cloudffx/p/5024871.html