淘米手套游戏CTO潘辉《如何提高手游开发的效率》

    大家好，我叫潘辉，混迹游戏行业十多年了，从单机游戏一直到手游。我挺庆幸在这个行业的，对于我自己就不做过多介绍了。我想大家可能还不大了解我们公司手套游戏，我做一下简单介绍。

 

    我先介绍一下手套游戏的历史，2001年的9月份淘米的移动游戏事业部正式成立，同时2月份推出了第一款游戏，2013年紧接着就收到各界的好评，2014年的淘米拆分整合移动游戏事业部，正式成立了手套游戏这家公司。

 

    那个时候我们的两款游戏《摩尔庄园》和《摩尔卡丁车》都取得一些不错的成绩。当然这些只是历史了，都成为了过去。虽然我们没有做到千万级别，按照现在主流的游戏公司的衡量来讲，我们做的不算大，但是这些产品给了我们很多鼓舞。同时也让我们比较坚定做这个路线，对我们开发来说做了一些技术的积累。

    手套游戏的诞生其实是面对主流的游戏市场为智能手机用户提供高质量的娱乐产品，创造完美的游戏体验，我想这应该不只是手套游戏的使命，它是所有游戏开发的共同的使命。毕竟用户体验和产品体验都围绕着这些词。这是手套的历史。我们现在做什么事情呢？这是2013年到2014年市场的预估，现在14年过半了，看来也差不太多。我们是做主流游戏开发的，我们公司内部更加细分了一下，主要是针对众多的RTG游戏开发的，同时针对我们的预测布局各条线。

    这是我们现在已经推出和马上要推出市场的几款产品，第一款产品《疾风勇者传》现在在安卓，iOS都可以下载到。按照我们的使命来讲，就是制造一款标杆级的游戏，我们团队正在努力。第二个游戏是《暴风》，第三款游戏是我们的淘米集团拥有的一款产品《忍者神龟》。第三个游戏是卡牌3.0的。这些游戏都可以马上和大家见面。这只是我们一部分产品，大家知道在开发者在这么抢手的年代，为什么有这么多人在开发呢？我们有公司的奖金制度，我们有内部晋升，更主要的是我们公司也在吸纳人才。这个奖金数在业内也是比较高的。

    我们之前开发了那么多款产品其实并不是顺风顺水的，比如说摩尔庄园，我们当时主要是针对iOS市场。等到iOS市场有了不错的成绩时，公司又要求我们是不是可以去的看一下安卓市场的情况，我们又针对安卓市场进行布局。这个时候我们程序就比较火了，我们又重新做解码。我们不断的重复代码，还要花时间维护两套代码。这个模式我们以后不在用同一个模式开发了，同时《摩尔卡丁车》立项比《摩尔庄园》更早，这个游戏大概做了一年半的时间，虽然也取得了一些成绩，而且从技术角度讲达到了很好的效果，上升到了一个很不错的水平，但是用了长达两年到三年的时间。

 

    也发表一些对Unity3D的看法。它有很多优点，它可以快速的建立图形，充分展现美术效果，工具链完整，可一键部署各个平台。但是我不会用它做的，为什么呢？第一是兼容性，第二是资源包很难做到50兆以下。大家也知道资源包大小对推广来说是很一个很重要的影响因素。还有Unity3D需要大量的投入，如果一个团队人手不是很充分的很情况下就不要去投。如果你不是很熟悉Unity3D的话，你可能在后面要不断的优化做减法。在之后，我们当时的想法也十分简单，因为Cocos 2d是轻量级，可以很容易做一些修改和改动。兼容性和运行效果都比较符合我们的要求，我们对比下来来看，Cocos 2d比Unity3D的运行好一些，同时资源包也更加可控。第三个方面说到基础工具，虽然Cocos 2d和Unity3D整个工具链来比还是不能比的，但是它也有一些相关的工具给我们做。因为它是开源的方式，可以写一些自己的项目编辑器。第四点是比较看中的是Cocos 2d的不断优化，我们要的就是这样的优质服务。比如前面看到的新推出的3.2版本加了一系列功能，对于我们脚本调试来说有很大的帮助。

 

    这三年过程中我们对比下来，整体来说Cocos 2d还是比较符合我们的要求，从运行效率、项目品质以及整个资源包来说都能达到我们的要求。为什么我一直讲资源包？因为我们公司对资源包的要求是很高的，这个对程序来说是很头疼的事情。我们不同的项目中用到了Cocos 2d不同的版本，我们发现Cocos 2d也在不停的优化不停的更新。

 

    先讲一下我们用到2.0版本，2.0版本有非常多的坑，当时我们对2.0版本做了相当大的改动。比如说我们参加了一些载入速度的优化，加了内层管理，多线程载入等等。我们当时有一段时间蛮沾沾自喜的，我们对引擎的把握能力还不错，但是随着Cocos引擎的不断升级，我们发现做过的事情好像Cocos也都把它补上来的，同时它还增加了很多新功能，我们又没有去做。这个时候就很纠结了，我们要花很大的时候做升级。我们后面做了一些反思，也跟很多开发商做了交流。我们很大程度是开发商在网站上给予回馈，并且会注明我们的解决方案，还是很积极的帮助大家解决一些问题和修正一些bug，让引擎更加完善的。

 

    我接收到这次沙龙的要求以后，我想了很多主题，我回顾了一下我们以往遇到的种种问题，又花很多时间需要解决的问题。比如说内层管理和优化等等，想了很多。后来反过来一看这些又不是问题了，因为Cocos已经很好地解决了这些问题，比如说Cocos 2d 2.3版本也解决了重要问题，剩下的一些小问题按照目前这么大的用户使用量，我们可以很轻松的在百度和谷歌上面找到解决方案。

    我在这里想分享的是效率两个字，提到效率，大家脑海里出现运行效率和渲染效率这些，这个对程序员来说，简直是挥之不去的词语。我今天讲的是产品开发的效率，为什么讲这个呢？今天来了这么多人，可能有几百个项目了。我们生活在这个年代，我们如何让我们的产品能更早的推出，这样收入或许就是另一番光景了。如何提高效率呢？游戏是一个高压行业，我们要尽可能多的放松自己，尽可能多参与一些娱乐活动，做到劳逸结合。这样也对工作状态是一种调整，我们可能会有更好的产出。我们公司会定期组织一些娱乐活动和游玩，甚至我们在公司办公室也摆放游戏机，供大家在休息时间可以娱乐一下。

 

    当然了，我们光吃喝玩乐还是不够的，那如何提高产品的开发效率呢？我们除了需要一套规范的管理制度紧密结合程序策划、美术、测试之间的工作衔接，我们还需要更多的自动化半自动化的工具来辅助我们完成日常非常琐碎的一些事情。这些工具来自哪里呢？来自互联网，可能来自大家工作中总结和收集到的。涉及的这样东西要拜托各位程序大牛们，对美术来说，花一点点时间发一些东西对可能要节省大笔的开销。

 

    我在面试过程中碰到一些程序员很自豪的讲，我们UI不是我自己写的，完全没有借助编辑器。我碰到一些人在QQ群里面问，我用Cocos Studio，会不会变傻掉呢？怎么会有这样的想法呢？它只能让我们有很多的启发，更好地工作，这款比较便捷的工具是我们的标杆和参照。

 

    结合我们的项目讲一下，我们对UI编辑器的选择也是经过很长时间的磨合，最早的时候我们也是尝试过手写UI的情况，接下来我们用GT+TXWUI的工具，最后用下来还是很繁琐。最后我们为什么放弃这些工具呢？第一点，我们公司希望所有的美术参与到工作中来。第二点，突然之间没有维护了，当时就敲响了警钟，我们就果断的转到了Cocos Studio，当时内部也是做了小小的组合。第三点，Cocos Studio用下来效率是比较高的。后面我们也用了LUA，但是也有一些负面的问题，我也希望能帮助我们解决这些问题。

 

    除了在编辑器的选择之外，在日常工作中有一个非常繁琐的事情一直伴随项目的开发，那就是资源整合，我们都知道美术同学使用的是所谓的小图散图。我们没有使用Studio的导出，我们是通过脚本来转化。第一步将所谓的小图按照文件夹策略，我们用转化工具转化完这些图片之后，打包成大图片，只有我们的josn会进行分析，看使用了哪些文件夹资源，然后就把它们加入进来。第二步把这些图片路径进行修改，替换成相应的图片名。第三步是资源压缩和优化，刚才讲过，我们对资源包的要求是非常高的。资源压缩和优化我们也是依赖压缩来压缩的。优化做了几个小的方面，我分享一下，我们会对图片像素点进行分析，如果它的阿尔法值小于3，我们可能会擦掉它RPG的值，这样可能对于我们压缩有一点帮助，但是微乎其微了。最后一点是目录整理。这些东西我们只需要双击一个脚本就可以了。

    这些事情好象很简单是不是？分分种都能做到，但是给美术带来非常大便利，你可以双击一下出来的效果，这对策划和测试调试UI节省了大把时间和开销，不需要美术来优化。我们的工作是很繁忙的，我们要抽出一些时间来看一下哪些事情是可以优化掉的。我们经常用的工具就是这些，比如说文本转化工具，我们如何让策划很方便的转化成表格这些格式。刚才我们讲的工具一定是为策划服务的。当前有一个小朋友写一个转化工具，小朋友写完以后策划们不太用，我拿了工具一看，它需要策划输入5个参数，还需要输入输出的路径。我当时问他，你是有多恨策划呢。

 

    我们的骨骼动画也是策划来做的，比如我们的BMFONT的资源的产生工具，这个自动化的构建工具大家都在用吧。这个是非常非常值得去用的工具。有了这个工具后，如果测试对于一个危机进行修改，很轻松的自己编一个版本出来就好了，完全就跳过程序这个步骤了。

 

    我们可能会用许许多多工具，我们如何找到这些工具，如何很方便的使用这些工具呢？这是我们公司内部一个平台，我们在日常工作中把一些项目相关的内容，比如说一些脚本格式，代码规范，各种甚至你把点餐的电话放在上面，我们的工作是平台式的，这样有各种好处了，第一不用翻各种文件夹了。第二如果有新同事入职的话，可以很方便的找到了这些，也可以很快的融入工作中来。

 

    我今天讲的东西没有太多的干货，但是我讲的是一种思维，我们如何高效地工作呢？我觉得大家应该有一个懒人的态度，懒人是科技发展的第一推动力。我觉得今天这个机会也很好，大家可以坐在一起进行交流，可以谈一些新的技能，可以认识一些新的朋友。这对于我们程序员来说，是相当好的一件事情。为什么呢？因为我们其实相对是比较闭塞的，我们应该打开更多窗口，我们公司也会定期的进行一些技术交流会。我们甚至当时请了Cocos引擎的人来进行技术答疑，这个对于我们公司来说是相当不错的。

 

    说到效率，有一个很重要，就是需要优秀的团员。在这里做一个小小的广告，如果你希望和一帮非常不错的成员一起合作，如果你希望做精品游戏的话，十分欢迎大家加入到我们。

【提问】：我们开发微信上面的游戏，有什么好的解决方案？

 

【潘辉】：首先是微信它跑在安卓浏览器上面，因为它优化的并不是非常好，所以它在上面非常关键的一点就是让你游戏填充率控制的非常灵活，就是很多控制图层要做图层合并。第二个就是很多流程计算，微信上面显示没有压力，你希望在微信上面做一个比较复杂的游戏，这方面的注意事项比较多。您的疑问是性能上面的优化是吧？性能主要是填充率和JAVA脚本计算，这两个都跟做其它游戏不太一样。因为脚本跑起来比较慢，第二个就是填充率。现在如果要做这种小型的游戏没有压力，但是如果做更重的，不好意思搞不定。

【提问2】：用Cocos 2d有一个很大的问题，我们现在想就是要打一个包看一下，这个问题很困扰。

 

【潘辉】：这是两个问题，第一个就是API所对的行为的一致性。第二个就是我写这个流程跑的代价有多大。第一个问题你用的是哪个版本？

 

【提问2】：3.0。

 

【潘辉】：我们在2.X的时候，中间的API做的还不是非常优秀，但是很多公司帮我们把这些问题修复了。能不能跟你说所有的API是百分之百的，这个没办法承诺。但是开发者遇到的问题不一样，就是3.0的版本比原来好用太多了，我们会做多平台测试。因为我们现在把JS上面的项目归纳到3.0版本，因为所有的项目是要测试，质量比原来好太多了。第二，就是进行效果调试，你可以非常简单的，不用打包。所以这个会从工具上讲更高效。

 

【提问3】：Cocos 2d上一个版本它好像是有一些问题，因为那个版本之前是1.0.3，又变成了0.0。

 

【潘辉】：这是小伙子不守规矩，应该是1.0之后，就是一般小版本升的时候不能升大版本，因为它们不可能花两三个月时间把发一个新版本把功能退回去的，这是不符合自然规律的。

 

【提问3】：还有一个小bug。

 

【潘辉】：最好是在英文站上面去看，你提交的所有问题我们都会解决，都在那个地方，那个是最高效的。如果你不愿意写中文怎么办，你可以发到CocoaChina所有有框架的板块，写完以后直接把链结写上去。

 

【提问4】：它的架构就是把代码封装起来上成JAVA，我们可不可以把Cocos 2d也做这样一层涂装呢？

 

【潘辉】：选择一条被安卓打死的路线。这条路线的危险就是JAVA跑在iOS上面，是做苹果所不喜欢的事情。

 

【提问4】：因为今天到120的时候，已经有好几款游戏在跑。

 

【潘辉】：这个方法可行，但是危险，刚开始试过一种方案它是成功的，但是不这样做，你编译过去以后，我个人不喜欢这个事情；第二个是苹果也不喜欢这个事情，因为我做一样东西是苹果专属。当时用C++做这个事情，在安卓上面写的，因为这是比较安全的。后来这条路线有其它公司做的，但是它们做的非常辛苦，苹果也不喜欢它们，谷歌也不喜欢它们，得不到两边的支持。

 

【提问4】：我能知道类似的资源，这样的方案很多。

 

【潘辉】：我个人的情感上面我一定会选择通用技术，别用某一家控制的这种东西。

 

【提问4】：通用技术的难度就是刚才说的C++，在大的工程上，我以前做过核心网络通信，这种大的工程它用C++内程线路，如果我们上层是LUA或者是JS的终端的话，它只是脚本语言。如果我们能用JAVA来做的话，这就是一个更广大的群体。

 

【潘辉】：开发对于我的信仰来讲，我一定会选择C、C++然后在上面绑脚本，其实我不太喜欢JAVA和微软使用的这两种语言。

 

【提问4】：我不是争论语言的好坏。

 

【潘辉】：很明确的说我对JAVA不是太感兴趣，这条路线可以做。实际上我们也研究过其它的东西，比如说Swift写完可以到安卓上面跑，但是这个没有意义，你今天发布了这个东西苹果不喜欢，它这条路堵死了。苹果不喜欢，安卓也不喜欢。中国今天最赚钱的游戏就《刀塔传奇》。

 

【提问5】：Cocos Studio如果界面非常复杂的话，我导入这个界面的文件的时候就比较慢，有什么建议吗？我们现在把所有的重要的文件在在上面，但是这样内存的压力比较大？

 

【潘辉】：你UI可以分成或者分模块，做一个很大的文件夹。

 

【提问5】：我必须一开始把所有文件都这么做吗？

 

【潘辉】：我觉得不需要，以《刀塔传奇》为例，它只有一个小场景，你不要在游戏进去的时候加载UI窗口，这样肯定量很多。有很多小屋子，里面有各种升级装备，进去的时候要后台异步同步，这个没有必要。接下来一些副本，其它的放一点装备。

 

【提问5】：现在Cocos Studio的可以异步的读取这种内容吗？

 

【提问5】：目前异步读取没有这种UI，你可以借一个方式来读取。

 

【提问6】：你们推荐C++和Lua有没有一个比例是多少？

 

【潘辉】：我觉得好的方式是这样的，如果计算很重，那这个东西就直接线程C++，有什么网络传输，加解密这种线程直接用C++，像其它的部分用Lua去写，UI这个仁者见仁的。把接口出来到Lua，直接的程序员功能的部分都是用Lua去写的。今天中午我遇到数字铁通的程序员过来，雄霸天下它也是用Cocos 2d和Lua写的，他自己是技术负责人，但是到每个游戏项目里面是用Lua。

 

【潘辉】：如果说哪些业务的内容对于你会涉及到更新，那这部分尽量都是放在脚本层，因为我们有一些开发者，原来做的那个项目当时百分之多少在脚本，第一有没有用，第二它高不高。

 

【提问7】：对于脚本语言的加密有没有什么好方法？因为现在Lua编译了很容易脱节？

 

【潘辉】：这个在新的脚本里面加了一个XTEE的加密方式，首先是Lua它可以编译成自解码，大家编成自解码有一个问题，它原来的部分不会被改掉，接下来用XTEE的方法加密掉。

 

【提问6】：这种加密强度有多大？

 

【潘辉】：目前比较流行的，看你加密多大，看你是多强大的高手。

 

【提问6】：加密部分是用C++实现？

 

【潘辉】：对，那个部分是用C++。

 

【提问7】：我最近用Cocos Studio，有没有别的办法？

 

【潘辉】：我对于Cocos Studio不算非常熟，我知道它可以做自定义控件，但是我自己没有去做。

 

【提问8】：我看到Cocos Studio感觉可以做App的感觉，不过是不是功耗会更大？

 

【潘辉】：说对了，用Cocos Studio做APP可不可以？不可以。除非你是插电运行。

 

【提问9】：我现在做iOS应用开发，我现在想开发游戏，不知道从哪块入手？

 

【潘辉】：这就涉及到一个怎么样走这条路了？可能有几个部分的建议，首先你对哪种语言熟悉一点，现在我们也有比较完整的DEMO，这样就更高效一点。

 

【潘辉】：哪个框架对于iOS开发者更容易上手？

 

【潘辉】：C和OC转C++，因为你现在没办法直接用来开发，你只有三个选择，要不是C++，要不是LUA和JS。

 

【提问9】：就是说以后Swift有必要学一下的。

 

【潘辉】：问题是它是苹果控制的语言，我们想把它编到安卓上面也没办法发，因为两边不讨好，我们跟苹果和安卓都要合作。

 

【提问9】：如果在一个应用里面插入一个游戏模块，这个怎么插？

 

【潘辉】：海派科技它们就是这样做的，具体就是讲到代码回答一下刚才QUICK的问题，现在QUICK已经到3.0上面已经可以跑了，它跑在手机上OK的。时间点下周五会发一个版本。QUICK就是有它做的好的地方，但是不要作QUICK2的版本。

 

【提问10】：我们现在做游戏，有哪些方法可以降低它的耗电量？

 

【潘辉】：耗电量跟你的性能是相关的，对我来讲比较简单的方式就是这样，你看一下哪些功能是占比特别高的，占比特别高的要分场景是测，占比高的看一下到底哪里写的有问题，把它干掉。只要有个很小的地方没搞定，改一行代码能直接影响到性能。耗电量还有网络那块儿，按道理网络应该是事件出发的方式，应该是1毫秒，结果它写1微秒，手机一下子发烫。全是这种小的地方。