zoukankan      html  css  js  c++  java
  • 回顾创业三年多来公司客户端技术发展

       
       三年前智能机游戏爆发,我跟几个朋友也一起加入这个时代的创业大军!所幸现在我们还活着,后面都不知倒闭了多少像我们这种小公司,深刻体会到市场竞争的惨烈!背景简单说一下,下面直入主题。
     
    第一年 :
         三年前的手机游戏引擎选择真的太少了,基本就是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
  • 相关阅读:
    JID 2.0 RC4 发布,高性能的 Java 序列化库
    FBReaderJ 1.6.3 发布,Android 电子书阅读器
    Arquillian 1.0.3.Final 发布,单元测试框架
    JavaScript 的宏扩展 Sweet.js
    Hypertable 0.9.6.5 发布,分布式数据库
    JRuby 1.7.0 发布,默认使用 Ruby 1.9 模式
    httppp 1.4.0 发布,HTTP响应时间监控
    Redis 2.6.0 正式版发布,高性能K/V服务器
    OfficeFloor 2.5.0 发布,IoC 框架
    XWiki 4.3 首个里程碑发布
  • 原文地址:https://www.cnblogs.com/cloudffx/p/5024871.html
Copyright © 2011-2022 走看看