Unity国内技术分享专场椰岛游戏.docx
- 文档编号:23503654
- 上传时间:2023-05-17
- 格式:DOCX
- 页数:14
- 大小:1.22MB
Unity国内技术分享专场椰岛游戏.docx
《Unity国内技术分享专场椰岛游戏.docx》由会员分享,可在线阅读,更多相关《Unity国内技术分享专场椰岛游戏.docx(14页珍藏版)》请在冰豆网上搜索。
Unity国内技术分享专场椰岛游戏
大家好,很高兴今天来到这里给大家做分享,椰岛游戏是成立于2009年,在上海是一个很小的Studio,我们致力于研发小体量的独立游戏,获得国IGF和Unity的奖项,我们每年都有组织GameJam,最早的时候是在公司里面做头脑风暴,然后我们要搞一个GameJam就搞了上海的GameJam,后来发展越来越大,就跟国际上的GlobalGameJam就发展起来,后面还有一个独立开发者社区就是IndieAce,这个独立社区规模也在扩大,方便做IndieGame的人方便交流。
从2009年到现在,已经有八年,经过八年的发展,我们还是一个小公司,现在人也不多,但是其实公司的氛围很好。
我这次会说两个方面,一个是说我们作为IndieGame,椰岛和Unity是怎么发展,去做游戏这件事情。
后面第二个阶段,我会分享两个简单,从我们自己项目的事例上面做一个简单的技术分享。
一、为什么选择Unity?
一开始我先多罗嗦一下,为什么选择Unity,有这么几点:
一、上手容易,这一点应该大家都会比较有体会。
我最大的感觉是说Unity其实不是为了技术人员准备,其实是给策划或者美术这些人准备的,它的界面非常友好,所以一个人可以开发出一个原形哪怕不懂得写代码,在我们工作室头脑风暴的时候,基本一个人或者两个人,花一个星期就会出一个模型,我们会不停地迭代。
、
二、跨平台支持,Unity5.6支持28个平台,非常了不起,所以我们其实在Xbox和PS4在国内首发的时候,也是把我们的平台植入到这个平台上,相对来说也是容易很多。
三、开发和运行高效率,其实是这样子,他们是一对矛盾,在我的理解,如果要讲求开发效率,那你的运行效率不一定很高,反过来也是一样的,但是Unity找到了一个比较好的平衡点。
Unity开发效果很高,运行效率也不错,Unity还推出了一个IL2CPP技术,这个技术非常棒,可以把大部分的代码进行原生编译,保证了运行的效率;开发和运行效率是一个矛盾体,但是Unity找到了一个平衡点,这个特别好。
四、人才储备丰富,对我们小公司而言,希望进来的人,马上可以为我所用,就发挥你的能力;招Unity的人也好,或者招C#的人,都相对更广一点。
五、Editor易扩展,这是Unity的最大好处;如果针对IDE进行二次开发,需要有一个很好的平台,Unity支持IDE扩展,扩展插件可以在IDE上面跑;Unity还有一个好处,就是你的游戏在IDE里面可以编辑,可以在某种程度上做到所见即所得。
我再说一下椰岛的这个特色,其实我们椰岛基本上是专注在2D方面的,有这几个理由,还有其他的就不细说了。
相对来说我们团队比较小,其实我们一个项目,大概是在人员配置一开始只有两到三个人,非常非常精简。
做2D游戏相对比较适合我们的团队,因为不需要大量的美术,或者说模型之类的,我们只要2D图片就好了,这是一个。
六、快速开发出原形,游戏开发的铁三角:
策划、美术、程序,理论上来说缺一不可,但是实际上,我们做头脑风暴也好,或者说参加Gamejam也好,经常看到一个人单挑。
我们希望大家组队,但是一个人单挑,这也是可以的。
其实相比用其他的游戏引擎,用Unity更方便支持对游戏原形进行验证和迭代。
我们其实在公司里边,出原形基本上就是一个人,完了之后,原形其实是24小时到48小时就出来了,对原形进行迭代。
迭代的时间确定这个原形的玩法基本上在一周两周左右,剩下的时间其实都是在打磨,所以你可以看出Unity在这个方面,其实是很高效,非常高效的使用工具。
七、3D开发有比较优势,相对来说是一个比较,因为现在游戏都是在往3D化发展,我们这边专注在2D方面。
其实做2D,有做2D的好处。
因为你不需要考虑那么多的特效,那么炫的表达,你要吸引住玩家,其实很大一部分程度就靠可玩性,所谓的Gameplay,反过来就让我们更加注重游戏性,或者游戏的表达,怎么才能做出好玩的游戏,来吸引玩家,在2D的世界里面,这也是一个挺难做到的事情。
这个是我罗列了一下我们产品和Unity之间的时间线,实际上之前,在2013年之前,我们也采用过其他的引擎,我们通过反复比较还是决定用Unity来做。
2013年,你们现在可以看到,叫Unity,这个对3D是支持很好,相对来说2D会弱一些。
所以他们是在2013年引进这个4.3版本,不知道大家对这个版本有没有印象,我觉得这个版本还是很重要,在他们社区里面推出来一个2D的例子,那个例子应该是英国伦敦,那个大本钟那边,有大作战,有几个人在那边打来打去,那个时候看了觉得不错,Unity做2D做到这样了,就是在那个版本里面,引入了所谓叫2Dsprite的东西,我们《决战喵星》也是在2013年发布,但是很可惜,Unity在2013年底,我们用的技术并没有2Dsprite,我们是用AssetStore里面的Ex2D。
然后到了2014年的时候,Unity发布了4.6,这个最重要的更新是引用了自己的一个界面系统,我们在2014年最重要的事情就是移植,我们就把这个切,切完之后立刻,应该说可以在XboxOne上跑了,但是上面有一些小的坑要去踩,这个不细了说,但是总体来说还是很方便。
我们自己还有一款拼字游戏,2014年的时候用Spel1master,我们就用在项目当中,这个项目几乎完成,但是最后没有上线,没有上线的原因很简单,我们觉得不好玩,是一个弱联网的游戏,所以服务器全部都好了,但是最后还是撤下来,没有上去。
因为这是一个拼字游戏,对国人来说,不是很擅长,做起来以后,老外的反馈不是很好玩,所以就放弃了。
时间到了2015年的话,Unity5.3有一个最重要的功能就是2Djoint,这个东西功能非常好,对于我们自己来讲,我们有《决战喵星》,因为《决战喵星》成功,我们很自然想到,这件事情最后在我们的团队里面也是处于暂停状态,因为我们也觉得不好玩。
《决战喵星》完全使用UnitySprite,还有一款是《超脱力医院》,我们从发布到现在已经累积一千万个下载,已经完成使用Sprite加NGUI,这个UI比较重,里面有很多UI的元素,当时UGUI,我们觉得不够成熟,因为刚刚推出不久,我们就选控件相对比较多的UGUI来做。
到了今年的话,5.6是一个大的更新,非常大,相对2D而言,功能也很多。
我们5月5号在Steam上面推出《汐》的游戏,这个《汐》的UI不是特别重,这个游戏在后面案例分享会详细讲到。
还有一款现在正在开发的超脱力的系列,也是完全用NGUI和sprite,这个我待会儿也说一下。
我现在就说,我后面有两块,一块是《汐》,我先说《汐》的技术分享,简单说一下。
我们先看一下视频。
就是从视频可以看到是一个平台跳跃类的游戏,内部开玩笑,这个新的正确打开方式,你在旁边备一个手柄和备一个键盘,因为这个游戏非常难,会难到令你抓狂,可能会把手柄和键盘砸到。
其实《汐》是一个2D卷轴游戏,就使用了大家非常熟悉的Parallaxscroller,有好多层,每一层都做卷轴运动,一般来讲,层会分几大部分,不一定是这三大部分,就是近景、背景、远景这样,但是在游戏里面分的层是比较多。
实际上最早FC上面的超级玛丽也是用这种方式来表达的,超级玛丽大致关卡的样子是这个样子,这个关卡有很大的特点,特点是里面的物件几乎都是可以重用的,随着卷轴的滚动,我可以把一些重复的,像管道,或者是后面的云什么的重复地把它做出来,把它放上去就可以了。
相对来说比较有规律,程序也可以很方便地来实现。
这是我们《汐》的场景,在Unity编辑器里面的场景,这还只是部分,没有完全截得下来。
其实大家可以看到这个《汐》的场景是完全没有规律,不是很简单,横向的卷轴就完事了,上面有高度,还有关卡的设计。
我们在制作上面,基本上有一个原则,我不限制你怎么样拼,你可以随便在游戏里面拼出你想要的游戏,这是layout,给我们拼出的样子,很复杂。
基于美术这种要求,或者说基于layout的要求,不可能做到重复性,不可能做到循环每件事情。
然后里面的场景会非常多,大家看到这边没有一个小白框,小白框,比如在右下角有一个小白框,那个代表一个屏幕,能够显示的内容,大家可以大概估计一下,这里面有多少内容要显示。
这就带来一个最直接的问题,场景我要怎么样去动态地管理。
因为我不可能一加载就把这么多产品全部加载进来。
虽然说显示Unity可以自动裁掉,但是场景加这么多是不可以接受,内存也接受不了。
我们就简单说一下场景的管理方式,在随便某一个关卡里面,我们基本上所有的这个子物体八千多个,八千多个不是所有,只是一部分,这个图大家可以看到,在左下角有一个白框,那个白框就是一开始玩家的出现点,就是你们能看到的一个屏幕的大小。
这还只是游戏的第一部分,后面会讲到把游戏切成好多scene,就是刚才所说的第一个方面就是切scene,我们把游戏分成几个章节,这样切一次可以把八千多个物体切成一千多个左右。
完了之后,你都去显示,同时都去加载的话,也不行,有没有什么好的办法,我们想到跟Cam做一个AABB,所有物件在场景里面都有自己的包围,都有自己的碰撞,我们camera也有自己的,很容易算出来,就很简单做一个AABB的测试,跟AABB相交,那就说明应该出现在屏幕上面,那就显示出来,否则的话我们就把它Detach,Detach不光是不显示,应该是被摘掉了。
还有一个办法进一步优化,其实是有的,你如果在场景里面对一千个物体跟cam之间做一个AABB做一个测试,这个消耗量也是非常大,是什么办法,其实有一个很现成的办法可以用,就是按照空间的关系,把它加到四叉树进行管理,这个时候跟AABB做测试,不是跟某一个特定的物体做AABB做测试,是用四叉树的节点做AABB的测试就可以了,只要跟这个节点命中、相交,下面所有子物体都显示,否则的话都不显示,这是一个以空间换时间的方法。
怎么样把物体加到四叉树里面,这个四叉树本身并不是均分的,因为场景是任意的,就是根据策划或者说需求,有些地方摆的物件比较少,有些地方摆的物件比较多,所以我们在划分四叉树本身的时候,并不是在整个空间里面均分四叉树,而是根据关卡的特性,物件多的地方我们四叉树分的密一些。
物件少的地方,四叉树分的细一点,放入四叉树很简单,就是把这个物件的AABB跟四叉树本身做一个比较,如果命中的话就放进去。
但是这里面有两点要注意,一点是说,静态的物件是没有问题,但是动态的物件不行,还要做进一步的处理。
第二点是说,有可能一个物件,会凸显在两个四叉树节点中,这个时候怎么办,跟两个四叉树节点都相交怎么办,我们的办法是两边都放,这样其实以空间换时间效率,也没有太多的问题。
还有一点我们物件并不是在逻辑上仅仅简单的是一个概念,也可能在场景里面有很多,会组成一个大的机械装置,齿轮或者是其他的东西,我们会把这一个大的所有的东西包成一个碰撞盒,然后把它跟AABB,四差数的AABB做测试,放到某一个节点里面去,相对来说比较灵活,并没有强制一定在这个层面上,可以组合起来。
在这个优化之后,使用的四叉树优化之后,我们一个场景的数量基本上降到了260左右,从八千左右降到260个,所以卷轴的性能提升的是非常明显的。
这里有一段视频,麻烦播放一下,我们看一下四差数的命中情况。
可以看到那个数页是动态的创建出来,是根据Cam的运动情况,动态地创建出来。
总结一下就是说,怎么样去减少这个场景里面的物件的挂载,你要减少Children的Transform数,用四叉树来管理,用AABB来进行碰撞的检测,通过这种比较简单的方法可以很好的提升整个游戏的性能。
说完《汐》,我来说一下《超脱力医院》,《超脱力医院》是一个Isometric维的游戏,这个特点就是说,有人称它为2.5D,最大的特点你以45度的角去看上去,游戏的场景就是很3D化,但是实际上用的2D的面片来表达出来,地图上分成N×N的格子,每个物体都在一定的格子,就这样的。
也是最简单的排序方式就是以Y轴来进行排序,所以说你玩这个大小,就决定了里面格子的描绘的先后顺序,这是最简单的方法。
但是这是有问题,因为我们《超脱力医院》里面用这个方法,但是后面发现有很多的问题,有很多坑。
先来看一段视频,这个视频被压缩过了。
每一间诊室都是用这个做的,玩家到里面可以扩展一下。
Isometric有不足的地方,我们在做《超脱力医院》的时候发现有很多不足的地方。
主要来说有两点,第一点就是地图编辑器,我们原来用的是第三方开源的地图编辑器,他基于windowsframe,就只能在windows,最终显示出来和导到Unity里面有很大不同。
这个排序是Y轴排序,我旁边有一张图,如果按照Y轴排序的话,其实这个彩色的方块应该在绿的后面,现在反而在前面,这就是引出来的问题,我们其实想要表达的是在后面,但实际上是在前面。
就是基于各种各样原因,但是在《超脱力医院》后续的,我们想解决自己的问题。
这是续作的改进,右边这张图是后来续作目前的样子,当然这不是最终的。
我们提了几个要求,第一个编辑器肯定要所见即所得,不希望两个编辑器之间来回倒腾,这是一个要求。
第二个我们支持层高,所谓层高,就是要有楼梯,要有第二层楼,整个房间,有一层两层,第三个有地图光照,有白天有晚上。
这是原来用的地图编辑器,我写了一个旧,你可以看到是用windowsframe做的,首先只能在windows平台,第二个有一个限制,这个地图大小不能有很大,如果做很大,我们就做四个,把四个在游戏里面拼出来,这个制作来说,效率是下降的。
第三个独立游戏之外,所以你经常发生说,这个做到后面,这个设备的很好,放在Unity里面一看,完全不是这么回事,又不是拼的很好,这也是一个很大的问题。
所以我们现在把它改进了一下,改进的方法实际针对上面几点,一个是把它直接再在UnityEditor里面上面这张图,看我们自己做的界面,最右边是物品的列表,有一些预览图,可以放到游戏当中。
好处就是跨平台,刚才也说了,做在Unity里面,就不担心在其他平台上不能运行了。
这边也没有区域限制,基本上就是内存限制了,内存有多少,我们就可以用到多少,在Unity里面有施展。
最重要就是做到所见即所得,也就是现在的地图编辑器是这样,在游戏里看到的就是这样。
你可以很方便在里面进行编辑,然后也不需要把这个数据导出来,导到原品里面进行检查,可以直接编辑,就很方便。
另外一个问题就是所谓的排序算法,我刚才说了,排序算法最最方便的,就是根据Grid的Y值来进行排序,根据Y的大小然后来决定这个是在之前还是在之后。
有几个问题,最主要的是我们遇到最主要是这样一个问题,首先两个物件蓝的和绿的,按照Y轴来说,相安无事。
虽然说它们都是在同一个Y值上,我们会以一个默认的方法来决定谁先画谁后画。
比如决定从屏幕的左边到右边,左边的物体先画,右边的物体后画,这样就很简单,蓝色的先画绿色的后画,互相之间没有遮挡关系所以很OK,没有关系。
第二张图,我在中间加了一个红色的物体,当然只有Grid,Y轴也是向,按照刚才的描绘顺序也是没有问题,实际上先画蓝色的,再画绿色的再画红色的,所以也是相安无事。
现在问题出现了,我们画一个长长的物体,就是红色的,我把它拉长,在这种情况下,你可以看到,他们的Y轴,先说红色的物体这个中心,这个中心跟上一张红色物体的中心是一样的。
按照这个描绘顺序来说,因为Y值是相同的,所以描绘的顺序也是先是蓝色,然后再是红色,然后再是绿色。
这种情况下,显示的很好,也没有问题。
如果把红色的这个长条换一个角度,其实对于排序来说,它没有发现任何的变化,为什么?
因为红色的中心还是在那个点,蓝色的中心也还在那个点,绿色的中心也还在那个点,所以它们的值Y轴是相同,按照相同的描绘顺序来看,我先画红的,再画蓝的,再画绿的,这不是我们想要的,我们想要的是这个红色被绿色的挡住,我们想要的是最后这个图的样子。
这是传统的排序最要命的问题,就是说如果所有的物件都是在一个Grid的里面,老老实实本本分分没有问题,游戏当中不可能是这样,肯定有大大小小的物体,肯定会显示的时候占用多个Grid但是中心却只再一个grid上进行计算,这样的话就会带来显示上的问题。
我们聊一下,我们怎么改进,想办法去改进,我们自己也讨论过很多的解决方案,其中的一个解决方案,把红色的物体切成小块,按照Grid。
因为切成好多细分的小块,每块都有自己的Y,就很简单,就按照这个东西来进行排序了。
这里面其实会有一些问题,就是说这个给美术造成一定的工作量。
为什么这么讲,因为美术在画的时候,是一个思维的整体,把它从程序上硬切,切完之后再去做这件事情,有可能一时半会儿没办法理解,或者设计的时候造成困惑,这是一个。
第二个很简单,你也增加程序的工作量,本来一个grid计算,现在分成十个,就多了十倍,这是一个。
我们还想用第二种方式,我们确定周围的Grid,这个红色的物体,长的物体,确定周围跟它相关的Grid,然后针对这些Grid做特殊的处理,或者做特殊的排序操作,这样也是可以的。
但是这引来另外一个问题是说,你要对这些相互有影响的Grid做一个标识,或者做一个特定的偏移或者什么。
这个其实对程序后面的编辑产生一定的影响。
还有一个就是说,你就算用了这种方法,也没有办法去实现我们要求的这个层高,就是刚才说有楼层,一层两层这样的一个要求,所以我们最后定下来的这个方案是所谓的建立3D的包围盒,可以理解为3D的碰撞盒,用来计算最终的排序。
到了这一点上,其实Grid对于我们排序来说已经不重要了,一个物体到底是不是在grid上,我们不关心。
完全按照这个3D的模型,进行3D空间的碰撞计算,然后再做前后的关系,这样就算是有层高,也没有关系,因为我们可以很容易地,层高有自己的3D碰撞盒,楼梯,包括第二层楼,如果是这样的话,跟第一层的做3D碰撞,也可以很容易计算出先后关系。
这个就是我们编辑器里面的,可以让策划,可以方便去,或者程序可以方便去定制三维包裹盒,就是属于地图编辑器的一部分,可以看到,黄色的那个框其实就是三维的包裹盒,下面说的值,红色的框里面,框出来的三个值,其实是真正进行3D计算。
但是有一点要说明,就算3D,我们用的也是一个整形,就为了方便计算,还有效率上的考虑。
这样玩了之后,其实很好对3D物体里面,3D空间里物体做一个排序,实际上排序还是分两种方式,一种叫全排序,一种叫做局部排序,这也是为了效率的考虑,因为物件太多,如果所有物件都做3D,所谓全局排序很简单,就是场景里面所有东西都排一次,就这样。
全局排序,是有特定的时间才会做这样的事情,一个是游戏载入。
因为游戏载入的时候把场景全部载出来,这个时候做一次全局排序。
还有访问其他玩家的地图,因为我们是一个弱社交的游戏,可以看到其他的玩家他们自己的地图是什么样的,还会有一些互动,当你看别人地图的时候,我们也会进行一个全排序,相当于也是一个关卡的加载。
解锁大块区的时候,我们游戏是分大的区域,大区域解锁的时候,这个区域里面本身会有一些很大的物体,有一些很重的物体,在这些物体的描绘上面,我们也采取全排序的方式。
相对来说有了全排序就会有局部排序,局部排序的概念,我只排其中很小很小的一部分。
在这里我们引入了一个叫做基座的概念,所谓基座是这样,所有玩家可以修改的部分,因为我们这个游戏允许玩家可以装饰自己的办公室,装饰自己的街道这样子,摆一个路灯,摆一个花盆这样。
在这里可以自定义的地方就引入一个叫做基座的概念,在这个基座上面,我们留出大概50到100个空间,这是排序的值,最后排序的值留出来。
在基座进行物件摆放的时候,就直接在基座的偏移上面加上,那基座只需要排一次就完了。
最重要的东西就是移动的物件,所有东西都是静态,只要排一次就完事了,就很完美,但实际上里面有人走来走去,人会跟静态的物件之间发生排序关系顺序的一个变化,这件事情怎么解决呢?
我们的做法是说,所有在游戏里面移动的物体,都是用路点控制,实际上不可以随便乱走。
路点本身是一个3D的点,其实是跟刚才的物件的包围盒在一个坐标空间里,我们只需要对路点和包围盒进行排序,能确定前后关系。
另外一个问题我走在两个路点之间怎么办,就走一个线性差值设置就行了,也可以比较好的解决这个问题。
最后可以看一下,麻烦放一下视频。
我们楼梯其实已经做了,但是移动的那个人,动态的物件我们还没有加进去,我们现在一个空的场景。
然后这个是白天到晚上的切换,我今天分享就到这里,谢谢大家。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Unity 国内 技术 分享 专场 游戏
![提示](https://static.bdocx.com/images/bang_tan.gif)