先分享一个故事:
《爱丽丝镜中世界奇遇记》里讲到,爱丽丝遇见了红桃皇后,红桃皇后牵着她的手往前跑,但是不管她们跑得多快,一直跑到精疲力尽,最后还是停留在原地。爱丽丝说:“要是在我们国家,像这样奔跑,一定会跑到一个新的地方。”红桃皇后不屑地说:“那你们是慢吞吞的国家,在我们这个世界,你要想待在原地,就得使出全身力量拼命跑”。
转眼之间就要到年底了,回首这一年,Shawn使用CocosCreator引擎开发游戏项目已经快一年了。依仗着之前Cocos2d-js经验老本,目前在Creator平台上过渡的还算顺利。
自从10月21日的Cocos沙龙期间,认识了不少Cocos的高手(引擎组的大咔们),了解到更多的Creator发展趋试,探讨了游戏开发中的问题,结合当下自己的工作情况,又有了不少的思考和感悟。
一、Creator 1.7重磅来袭
Creator1.7最大的亮点是JSB2.0,JSB2.0的本质是底层Javascript引擎的更新换代。回想过去,Shawn是在2013年9月开始接触Cocos2d-js,直到现在的Creator1.6版本,SpiderMonkey为Cocos服役超过了4年,现在终于要谢幕了。
1. JSB2.0
JSB2.0迎来的是,两大超级明星级:V8与JavascriptCore
Mac与iOS使用JavascriptCore
Windows与Android使用V8
2. js引擎的变化对Cocos项目的影响
在native上js层的运算性能有翻倍提升
在native上有更丰富的调试方法,更精准定位问题的手段。我觉得这一点对程序员很重要,因为找问题比改正问题花费更多的时间,有了先进的调试手段,有利于加速bug的定位。
native与h5环境的js引擎环境更加的一至了,在开发体验上更加接近。
旧的Cocos项目,如果之前编写了jsb绑定相关的代码,要升级到JSB2.0需要重新编写绑定代码。
在此献上官方出口的JSB2.0绑定教程:
二、AssetBundle隐形的翅膀
在Cocos沙龙上,AssetsBundle虽然只有三行文字的介绍,但了解到这一未来特性的第一瞬间就被它吸引了,随后让我想起一两前年国内各大引擎的runtime运行时。
当年国内三大游戏引擎,纷纷将runtime置入腾讯QQ浏览器,号称超级App的到来,原生游戏也能点开即玩。那时感觉完全是进入了H5的春天,我当时的项目做的都不好,有人转u3d或lua,我转了一圈还是决心留在cocos2d-js的阵营!后来不知道为什么runtime没怎么火的起来,反而是H5势头越来越猛。
把话题扯远了,还是回到AssetsBundle上来,我觉得AssetsBundle会不会更加模糊原生游戏与H5游戏,两者都是将代码和资源放到远程服务器,动态加载运行。而且其中还有一句关键“跨项目联动”,不同项目共享AssetsBundle资源,那不是可以将游戏内容转变成一种云服务呢,大家共享?
如果AssetsBundle真的能将资源粒度控制的非常精确,那原生游戏也具备H5的特性,同时还有H5不具备的流畅体验,那问题又来了?
那Cocos原生游戏是否不再用为热更新烦恼了呢?
目前流行的棋牌合集游戏,是否不用为游戏大厅和子游戏而发愁?
安装包体积问题是不是也可以由此迎刃而解?
想到这些,小心脏有点受不了,赶快写两行代码压压惊!
所有的Cocos游戏都成了超级App,假想一下会不会出现一种“_游戏SDK_”,就是制作一个SDK,里面集成了cocos2dx + CreatorJS +AssetsBundle,当App接入了这个SDK后,这个SDK会从远程获取游戏代码和资源…
AssetBundle会不会像一双隐形的翅膀,带着我们飞翔,带来更多的希望?
三、 2D与3D
在沙龙上Cocos引擎Jare大神在PPT中还分享了一个Cocos的高亮特性,请看下图:
引入材质系统****?Shawn做游戏的时间不长,可在Cocos中只听说过纹理,从来没有过材质的概念,纹理与材质是什么关系?
虽然没吃过猪肉,但还是见过猪跑,家里的游戏机还是有两台,在3D游戏中还是听说过的材质,但是没有清晰的概念,为此,我在知乎上搜索了一翻:
作者:周华
链接:https://www.zhihu.com/question/25745472/answer/31531285
来源:知乎
纹理:即“纹路”,每个物体表面上不同的样子,譬如说木头的木纹状。
贴图:是图,最简单的形式是ps之类的软件做出来的一张图,这些图在3D中用来贴到物体的表面,用来表现物体的“纹理”。
材质:主要是用来表现物体对光的交互(反射、折射等)性质的。譬如金属对光的反射和毛毯对光的反射性质完全不一样,那么对3D程序来说,这样的差别就通过材质这个属性来计算出不同的颜色。
通过上面的解释一下子就明白了,感情是要在2d引擎中引入光照功能,实质是将3D游戏的特性引入2D中,再回过头看看标题“重写渲染层”,这是在为Cocos3D铺路的节奏吗?
四、Javascript与TypeScript
在使用Creator做项目之初,我就一直坚持使用Javascript ES6语法,不仅代码更加简洁,而且这是未来发展的方向。JSB2.0带来了新的JS引擎,对新Javascript新语法的支持更是不言而喻。
1. 新旧Javascript语法混合
但在短期内,新旧js语法将会在项目中混合使用,代码风格的统一上会出现分歧:有些守旧的人看不懂新语法不愿意使用,而有些人喜欢冒险的人则鄙视旧语法。不过目前通过Creator的内置的bable编译器抹平了语法上的问题,输出的代码最终影响不大。
总的说来接受和学习新一代的js语法是大势所趋,就从提高开发效率和代码质量都是值得的,不过习惯不是那么容易被改变的。如果有心想想在项目中使用新的语法,统一代码风格,ESLint是一个极佳的工具,可以尝试用用!
2. TypeScript让人心动
这一年使用js做Creator项目也有不少体验感悟,特别是观察到刚入行的新手,不管是js语言本身,还是IDE对js的支持,都成为新手成长速度较大的障碍。
Creator从1.5.2开始支持TypeScript语言,Shawn之前也学习过一阵,但没有在项目中实战过,自从在Cocos论坛上看到有网友晒出用ts写代码的视频,心里有痒痒的!如果有兴趣可通过下面链接了解,说不定会让你爱上写代程序。
http://forum.cocos.com/t/typescript-creator-github/42200
我认为ts至少可以帮我解决js下面两个问题:
解决在IDE工具中的代码提示问题:js代码在IDE中的提示较弱,这是新手入门时很大一个槛,一个组件有那些属性、方法需要强行记忆,还容易写错字。TS动、静结合在编码时的智能提示相当精确,同时对老手也能提高代码生产速度。
解决数据类型问题:js在数据定义、参数传递时没有类型限制,ts则像java这类静态语言上有强制的数据类型匹配,这可以减少在运行时属性不存在,对象字段写错字的问题。
ts是js的超集而且在Creator中可以js与ts混用,可以尝试在新的底层代码中用ts,上层代码不管是用js还是ts都可以在IDE中提供确精的智能提示,从而提高开发效率,再由星星之火蔓延到整个项目,最好是能让项目、让团队能火起来…
五、团队与项目
我遇到的大多数团队,美术与策划几乎都不愿意去用游戏引擎,会熟练使用引擎去编辑UI的并不多,对于美术人员来说,编辑动画比编辑UI更容易。
1. UI界面的生产问题
我所体验到的项目工作流,还没有达到上图所示中的那样美好境界:
美术拼接UI,程序员完成组件代码的挂接
我理想的情况是将用户界面中的UE和布局部分交由策划做第一轮,将界面的美化、赋图、精确位置等交由美术做第二道加工,最后由程序做节点的层节调整、命名等需要与代码交互相关的操作。
要做到这些,需要整个团队具有极强的协同能力,如果协作的不好可能还不如交由程序员来完成(可怜的程序猿们)!
还是有些不甘心,团队中如果能培养一名会游戏UI编辑的美术或策划,能将UI与程序建立链接,在程序开始一个功能前将场景和预制件提前准备好,这将极大地为程序员们节省时间,也为是项目节省出时间。
很多时候我们是为了完成任务而工作,大多并没有思考过各种资源组合的可能性,有时候慢一点、反思一下说不定会找到更优的解法。
2. 资源管理问题
我一直认为,游戏项目中的资源管理是重中之重,整合策划、美术、程序输出的资源,是游戏团队人员每天要做的事情。如何能高效地整合游戏开发中的这三驾马车,是值得深入研究的课题!
策划:文档、配置
美术:图片、动画
程序:代码、工具
在我的游戏开发体验中,我觉得程序应该主动利用代码和工具为项目流程增加自动化处理,将人工重复劳动从中解放出来。策划产品经理应该站在更高的层次发现流程中的痛点,想办法优化流程、减少部门之间的沟通成本。
六、结语
不论是Cocos的升级与发展,还是js\ts语言上的进化,再到项目和团队,都让我感受到当下世界发展之快,所有的事物都用尽全力去奔跑,正如开篇故事中红桃皇后所说的:
“在我们这个世界,你要想待在原地,就得使出全身力量拼命奔跑”
欢迎关注「奎特尔星球」微信公众号,有代码、有教程、有视频、有故事,一起来玩吧!
本文分享自微信公众号 - Creator星球游戏开发社区(creator-star)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。