天天飞车六大研发经验.docx

天天飞车六大研发经验

序言：转型手游，问题比想象要复杂。一些问题是研发阶段就能预见的，但是有些问题上线后才发现远超出我们的想象。

从端游转型做手游变化远没有想象简单

可能和公司内很多手游研发团队一样，我们也是从传统PC端游转型做手游的。我们一度认为手游研发会比较轻松，技术上跟端游比起来相对容易，人力上也不需要太多投入。

但真正开始做之后才发现无论技术还是产品各方面远没有我们想象的简单，好在我们的核心成员都有多年的端游开发经历，不光有相应的技术和经验积累，还养成了一些好的工作习惯及方法，在遇到问题时能够及时调整和灵活应对，我想这也是我们项目研发从总体上看还比较顺利的重要原因之一吧。

最开始遇到的问题主要还是技术上的，我们没有Unity3D引擎的实际项目经验，心里面没底，不知道研发过程中会遇到哪些坑，对于iOS/Android平台编程更是一窍不通，项目进度又紧，不可能有充裕的时间自己去学习和摸索，万幸得到兄弟工作室团队的无私支持让团队少走了很多弯路，我也从他们身上学到很多移动端游戏开发的一线实战经验。

我们的研发团队规模一直都比较小，直到项目上线也只有十来个人，不少美术同学还是兼职的。正式运营后才深刻认识到我们的人力规模完全没法适应玩家对于游戏内容的消耗速度。在工作室和产品中心的支持下，队伍得到不小的扩充，目前是30人出头的规模，

也算是一个中等规模的团队了吧，然而团队规模扩大了又会凸显出很多新的问题，比方说工作任务间的偶合，多线开发的版本管理等。

对于小团队来说，解决问题可以很直接，只要有可行的方案，可能一句话就搞定了，尤

其是我们有几个人做天天飞车之前就已经磨合两三年了，配合起来非常默契。但团队规模大了之后，可能就会涉及到一些团队管理问题了，如何让大家拧成一股绳去做事情，并不是简简单单把问题指出来就可以了，这时候制度和流程就显得尤为重要了。

早作规范早验证，避免返工。

寻找表现与性能的平衡点很重要

我们的一个习惯就是一开始一定要把游戏最核心的东西、最可能遇到的技术难点，不管是玩法方面的还是表现方面的，彻底捋顺想清楚了做出Demo来验证，然后才是制定标准和量产，这能提高开发效率降低走弯路的机率。

天天飞车的Demo做的非常快大概两三周就基本完成了，包括了无限赛道的动态拼接，碰撞检测，车辆的碰撞响应，车辆和道具动态生成等等这些最基础的功能，而且也已经具备了最基本的玩法逻辑比如说惊险超车。虽然以现在的眼光看起来它很原始也有很多问题，但如果撇开画面表现和细节手感之类的不谈，天天飞车最最核心的东西其实就是这些。

对于客户端来说可能最首要的问题就是设备适配问题，Unity3D有很好的封装性，系统和设备的特殊性大多被隐藏起来了，所以兼容适配基本不用操心，就算后期测试时发现一些兼容问题针对性的处理下也就好了。分辨率适配也没有太大问题，业内广泛采用的NGUI界面中间件提供了一套基于锚点和等比缩放的很成熟的方案，我们只需要按照它的规范去做就行了。所以，最需要投入精力的还是性能适配问题。

按照以往做端游的经验，如果有成熟的引擎和技术方案作为基础，性能适配问题的核心其实就是订立合适的资源规范并严格执行。资源规范主要分为两类，一是数量上的，包括单帧渲染的面数及顶点数，DrawCall数，同时载入的贴图和音频容量等等。另一类是技术规格上的，如光照模式，贴图格式，音频格式等。在制定规范前，我们首先依据微信和手Q的用户设备统计数据确定了游戏的最低配置要求，因为我们的用户就是他们中的一部份，而且很显然，游戏的配置要求越低，将来的用户量也就可能越大。另外因为没有经验不能一上来就埋头自己干，所以我们还参考了怪物大作战的一些规范，他们可以说是公司Unity3D手游的先驱，向他们致敬。

当然了，光有资源规范是不够的，程序上的基础性能优化工作还是必须得做好做足的，对于Unity3D手游来说主要有托管堆内存的合理使用，对象池，资源加载卸载管理等。

作为一款3D游戏，我们也一直在寻找游戏表现和性能的最佳平衡点。一个基本的取舍原则可能就是性价比，看性能的损耗带来的效果提升到底大不大，是不是用户比较关注的。另外在这点上程序和美术之间也经常会出现一些意见分歧，这很正常。对于程序同学来说希望客户端特别省，轻巧而快速。对于美术同学来说希望画面足够精细，能够最大程度的保留设计初衷可能是非常重要的。这个问题目前看来我们处理的还是比较好的，站在客户端程序的角度，一方面有些原则我们必须要坚持，比方说不能使用复杂的实时动态光影，后处理效果等确实与当前大多数移动设备硬件性能不相匹配的技术，另一方面我们也应该和美术同学一起为游戏的表现品质努力，比方说我