mayaxiaoan mayaxiaoan
关注数: 6 粉丝数: 1,318 发帖数: 7,440 关注贴吧数: 57
Unity移动游戏优化的小技巧 转自官微~ “你愿意为了性能消耗放弃多少艺术风格?” 相信每个开发者在开发游戏时,都会思考这个问题。我们需要注意性能的消耗,或者找到一个方法来保持在美学方面与原目标尽可能的接近,而不影响玩家体验。 Unity官方技术支持团队为大家分享过《Unity游戏项目常见性能问题》,今天为大家分享《Cubiques立体迷宫》的开发者Dilmer Valecillos为大家带来他在使用Unity进行移动游戏优化中的技巧。 实时阴影(硬阴影与软阴影) 实时阴影在游戏中会产生很棒的效果,但是开启实时阴影会造成巨大的性能消耗。实时阴影可能在编辑器中运行的时候看起来会有很好的效果,但是在某个时刻,当游戏在手机上运行的时候,你可能会发现FPS从大约60帧降到更低的数字,你也可能会发现,实时阴影在最新款的手机中会运行的很好,但是你的游戏将导致电池出现大幅度的损耗。这就是实时阴影导致的,是的没错,实时阴影需要CPU/GPU大量的计算能力。而使用软阴影会带来GPU性能的损耗。 优化游戏的阴影 Dilmer Valecillos决定在《Cubiques立体迷宫》中完全禁用阴影,因为当在iPhone 7 Plus上运行时,实时阴影得到了平均20-50FPS的结果。但即使有iPhone 7 Plus这样性能强大的设备,FPS都过低。所以如果想要保证游戏拥有相同的外观和感觉,则必须使用假阴影。如果你曾经玩过《Cubiques立体迷宫》,可能已经注意到这一切都是由一个立方体组成的。为了伪造一个阴影,只需要在Y轴上投影一个负偏移的平面,将一个简单的浅灰色添加到移动平台着色器的材质上,每个需要阴影的砖块都应拥有自己的假阴影,并具有相同的设置,使它看起来就像是一个真正的阴影。 说明:《Cubiques立体迷宫》是一款与休闲益智闯关游戏,拥有十分清新简约的画风。玩家需要在游戏中合理控制小方块的前进方向,一不小心就会失败重来,反应速度是很重要的,喜欢这类风格的玩家可以试试。 下图展示了实时阴影与假阴影的效果有多么的相似。但是从计算性能上则有了不少的提升。这样的修改,使得游戏从20-40FPS变化到60FPS。此外,移动设备也没有吃掉电池或变得超级热。在禁用实时阴影和使用假阴影之前,一开始我用调整阴影距离的方式提高了实时阴影的性能。只是最终我还是没有使用实时阴影。阴影距离可以帮助确保距离很远的对象没有阴影,使用质量设置中阴影的设置都可以对游戏效果和性能效果起到作用。静态批处理 启用静态批处理将有助于性能的提升。在《Cubiques立体迷宫》中大多数的场景游戏对象都是静态的,这意味着唯一真正运动的物体主要是立方体角色。要启用静态批处理,只需将每个对象都设置为静态的,这是每个游戏对象都具有的属性,并且可以通过检视窗口进行设置。还要确保运行设置中在渲染部分启用静态批处理。 下面展示了几个静态游戏对象:在Unity编辑器中,静态的网格不能被移动,实际这些被标记为静态的物体不应该有任何移动,因此,在运行时也不能通过Unity编辑器移动。 图片压缩 Unity中有很多图像压缩的选择,而UI元素的最佳选择是iOS设备中一个名为“RGB Compressed PVRTC 2 bits”的选项。在《Cubiques立体迷宫》中即便是使用低压缩率,UI看起来也不错。清记住需要根据平台来查看不同的选项。Unity为不同平台提优化供了特殊的选项,它能根据你的平台需要来优化纹理。 下图中展示了解如何根据平台设置压缩。压缩也有助于节省应用程序的大小。你想要确保最终版本尽可能的小,因为程序在安装到手机中,玩家们会表现地非常的挑剔。另外如果应用程序超过了100MB,苹果要求下载就必须连接WiFi,因此需要尽可能的小于100MB。 后期处理堆栈 Unity的后期处理堆栈是很令人震惊的,它使你的游戏看起来更漂亮,当后期处理堆栈出现时,可能我们想要启用其中的每一个选项。运动模糊、环境遮罩、光晕、色彩分级等。这些选项可以给游戏一个美丽的后期效果,但每个选项都有成本上的消耗。正如之前而言,艺术之美带来可能会带来巨大的成本。 小结 除了本文中所提及的方法外,还有更多的方法可以实现游戏优化。例如:音频压缩,在Unity中使用Profiler。尽可能多的尝试每一个优化步骤,并在修改后进行测试,确保每次都将修改的新的内容提交到源代码控制,因为这允许你恢复历史代码,以防止出现不正确的更改。
如何避免自己的动画状态机变成长江大桥~ 最近看到很多搭线诡异的Animator状态机~ 刚好看到一篇讲这个的文章,大家按需自取~ 转自官微 本文中所使用的动画均来自游戏《Firewatch》的角色Henry。图01 《Firewatch》 技巧1 使用混合树封装复杂的行为 混合树很适合用来隐藏复杂的行为。混合树并没有状态,它也不需要代码回调。它仅仅会根据用户定义的参数来混合两个不同的动画剪辑。 使用混合树的优点是在迭代混合树时,完全不用担心会把游戏的其它部分弄得一团糟。你可以封装隐藏好复杂的状态网,同时避免在接下来的开发过程中产生新的问题,因为你不能给混合树中绝大多数的动画绑定行为。干净整洁的混合树 技巧2 把Layer当作脚本类 将Layer大致看做是脚本类,对于理解接下来的内容是很有帮助的。你会把所有相同的逻辑和行为函数都封装在一个层中。这是因为每一个层都会对其重载的其它层的部分进行控制,不受某个具体骨骼或层级的限制。Henry左手的动画状态,每一个层的结构与功能都清晰明了 技巧3 模式的重用 状态与子状态机种逻辑模式的重用有助于提升开发的速度,也有助于其他人制作类似的内容,同时故障的排查也更容易,减少bug产生的数量。 以下类型的模式有助于Layer的构建: 轮状图:该种模式的故障排查较为简单,你可以清晰地看到转换在空状态与其它状态之间游走。下面轮状图中轮轴的每个轮辐都应重置其连接的对应状态。Henry右手的轮状图 入口/出口共用模式:通过将状态进行组合来达到“入口”-“执行/循环”-“出口”的模式,你可以较为容易地将任意动画事件或状态机行为附加到“入口”或“出口”状态上。和混合树很相似的一点是你可以迭代并修改内部的“执行/循环”状态而无需担心会混乱游戏的其它部分。从入口到出口:Henry右手拿书的所有状态 关键节点与次要节点模式:对于可中断的动画,尤其是由用户输入驱动的动画,你需要将动画片段分割为两个部分。首先关键节点需包含所有状态的变化、效果与伤害等,就是必须完整播放的部分。其次是次要节点,即可以优雅地回到空闲动画的节点,同时可以被来自用户的新输入所中断。调整后的节点模式 技巧4 不要在状态机行为中编写过于复杂的代码 状态机行为就是可以被附加在动画状态上的小段代码。你可以使用这些脚本为状态机附加行为。 尽量避免在这些代码中编写复杂的游戏代码,因为这会让你很难找到状态机中什么地方做了什么。如果你需要使用状态机行为来驱动游戏代码,请使用消息系统。将请求传递给某个管理类,或者在更高层级上关闭某些参数。 最后推荐状态机行为:Debug.break。这是最实用的状态机行为,你可以在动画体系中的任意地方附加该行为,它的作用就像断点一样,和可视化编程系统很相似。 技巧5 使用状态机行为来确保某个动画事件被正确应用 动画事件可以将动画剪辑片段中的某个瞬间与游戏的某种状态联系起来,它们可以被用来设置诸如视觉或声音效果。然而如果状态机中某个事件在被发布之前状态就被转出,则这个事件就根本不会被发布。一种解决方案是添加一个新的状态机行为,用于确保在某个瞬间事件确实地被发布出来,无论游戏中发生了什么事情。 使用动画状态机事件脚本
各位新上手的萌新注意,Unity将放弃JavaScript支持 该来的终于来了,还在坚守JS的童鞋建议转C#,不要担心,真的不难,基础语法基本一致,而且众多第三方类库支持会让你发现新世界的大门。 注:UnityScript即Unity中的JavaScript,由于不是真正的JS,只是借鉴语法,故又称为UnityScript正文: 告别UnityScript,Unity将仅支持C#脚本编程 UnityScript是Unity中类似于JavaScript的脚本语言,从Unity 1.0开始伴随至今,终于迎来了告别之旅。我们已经开始逐步弃用UnityScript,仅保留C#作为Unity脚本编程语言。 目前仅有3.6%的Unity项目重度使用UnityScript脚本语言进行开发,持续维护UnityScript将影响Unity对新脚本功能的支持,所以我们决定将弃用UnityScript。 弃用UnityScript原因 每次Unity决定放弃支持一些功能,都会先了解这些决定可能会为用户带来的不便。所以确保这些决定有其值得进行的理由对我们来说也至关重要。Unity脚本编程正在经历重大升级,其中一些重要功能包括: 脚本运行时升级,支持使用.NET 4.6与C# 6; JobSystem,支持轻松编写多线程代码,且避免竞争条件与死锁; NativeArray类型,支持创建及使用大型数组,它们拥有原生代码控制的存储区域,以便于对内存分配行为拥有更多控制权,从而不必再担心垃圾回收机制; 支持控制脚本编译管线,以便自定义将哪些脚本整合进程序集。 上述内容仅仅是一小部分,我们还将继续支持一些脚本新功能,并计划开展一些脚本项目。除了这些项目之外,我们也正利用最为合适的语言结构,更多地开放引擎底层API。 目前UnityScript与C#在功能与性能方面不相上下,C#可以实现的内容使用UnityScript也能达到同样的效果。而谈到开发生态,显然C#是赢家,不仅仅是因为C#教程与示例比比皆是,还有C#语言丰富的工具集,例如Visual Studio提供的代码重构与智能提示。可能这些工具目前还不足以成为C#取代UnityScript的理由,但这仅仅是目前。 技术总是不断发展的,随着我们升级脚本运行时并支持最新的C#版本,会出现一些使用C#轻而易举但UnityScript无法轻易实现或者不支持的内容。目前UnityScript就不支持为方法参数提供默认值,并且C#语言支持的功能越来越多,例如返回引用等,都是问题。目前我们暂未在API中使用这些功能,但出于性能与API结构设计考虑,我们也希望尽快利用这些新功能。 当然,也可以选择花时间来弥补UnityScript所欠缺的功能,但要持续维护UnityScript,就意味着该开发者无法进行其它工作,例如添加新功能或修复Bug等。这还不包括在脚本更新器中支持UnityScript需要的工作,以及相应的文档更新工作等等。 所以不如换个方向思考,如果弃用UnityScript,有多少用户会被影响呢?Unity编辑器会定期发送Unity项目相关数据,包括项目所使用的脚本类型与使用频率,我们可以据此统计出正在使用UnityScript的项目。统计结果如下: 截止目前使用Unity 5.6的项目中,包含至少一个.js文件的项目占14.6%。这个比例看起来相当高,但进一步分析数据,看看各项目中.js文件与总文件数(.js文件 + .cs文件)占比,会有新发现。 也就是说,85.4%的Unity项目完全使用C#语言,根本不包含UnityScript脚本。 9.5%的Unity项目大量使用C#语言,其中也包含一些UnityScript脚本,但脚本数量占脚本总数不足10%。还有1.5%的Unity项目所包含的UnityScript脚本占项目脚本总数在10~20%之间。 3.6%的Unity项目使用UnityScript语言的脚本占脚本总数20%以上。 仅有0.8%的Unity项目完全使用UnityScript。 以上数据表明,大量Unity开发者都没有重度使用UnityScript。甚至项目所包含的UnityScript也并非实际使用的脚本,可能只是资源商店某个插件的示例代码,对实际项目并无影响。所以我们弃用UnityScript计划的第一步,就是从资源商店发行商着手,移除所有插件中的UnityScript脚本。 对于那3.6%较多使用UnityScript的Unity项目,以及那些0.8%完全使用UnityScript的项目,我们表示很抱歉。我们明白这样的决定会对您产生影响,我们正采取一些措施来尝试让整个转换过程更加流畅,也希望大家能够理解并支持我们所做出的决定。 弃用计划 我们会逐步弃用UnityScript而非一刀切。主要计划步骤如下: 首先,从6月开始我们已经修订了Asset Store资源商店的插件提交条款,拒绝接受包含UnityScript代码的插件。所有新提交至资源商店的插件都必须使用C#代码(在执行此项规定前我们已与资源商店发行商进行讨论与沟通)。很快我们将会对资源商店的现有插件进行代码扫描,查看其中是否包含UnityScript文件,如果有则通知发行商将代码转换为C#。一段时间后,代码未转换为C#的插件将从资源商店下架。 其次,您可能已经注意到了,Unity 2017.2测试版的Create Assets菜单下已经不再包含Javascript(即UnityScript)选项。目前我们仅移除了此菜单项,Unity编辑器仍然支持UnityScript,您仍然可以从编辑器之外创建UnityScript文件(例如MonoDevelop)。这么做的原因是保证新用户不会继续使用UnityScript,以免浪费大家的学习成本。 另外,我们已经在开发UnityScript自动转换为C#的工具。目前该工具已有些成果,但仍在完善中。我们暂未决定是否将该工具集成到Unity编辑器,或单独开源提供。无论以何种方式,该工具都会在今年年底Unity 2017.2正式发布时供大家使用。后续也会单独介绍该工具,请大家保持关注。 最后,我们也将持续关注分析数据,并希望所有Unity项目可以尽快切换至C#,尤其是UnityScript脚本数量少于10%的那部分项目,需要移植的代码较少。但如果开发者无法完全弃用UnityScript,我们会暂停弃用计划并调查无法移植的原因。在彻底弃用UnityScript之前,我们将确保不遗漏任何重要信息。 在确认UnityScript使用率足够低之后,我们将不再支持UnityScript编译器,并且不再将.js文件识别为脚本代码。我们也会从文档中移除UnityScript代码示例,并且脚本更新器将不再支持UnityScript。 如果有需要,仍可从Unity的GitHub中下载UnityScript编译器,我们不会接受任何推送请求,但您可以创建自己的分支以实现您的需求。 关于Boo 我们在2014年宣布放弃在编辑器与文档中支持Boo语言。但Boo编译器仍存在与编辑器中,因为UnityScript用到了Boo的运行库,并且UnityScript编译器本身就是用Boo语言编写的。您仍可在Unity项目中使用.boo文件。 在取消支持UnityScript之后,也就意味着会移除Boo编译器。目前所有使用Unity 5.6的项目中仅有0.2%包含了.boo文件,仅有0.006%的项目拥有3个以上.boo文件。我们再次表示抱歉,但这也是必然之势。 结语 我们希望能够清楚了解弃用功能将为大家带来的所有影响,所以会依照这样的流程:通知大家我们的计划,推动资源商店插件与编辑器UI更新,最后基于实际使用率的数据来决定是否执行。 弃用某个功能看起来就像是退步,但这也是提高Unity开发效率的必经之路。我们希望集中精力为大家尽快修复现有问题并提供新功能,也希望大家能够理解并支持我们的决定。
【新手进阶向】Unity生命周期的完整靠谱测试,更加稳固的基础知 大部分的主要Mono函数周期大家可能都已经了解了,但这些函数实在太多太杂,目前网上也并没有一个靠谱的完整周期测试,所以顺手也做了吧~ 协程是假线程,还是基于Update周期的,其执行位置在Update和LateUpdate中间,可以看到执行协程的时间总是跟帧周期相同,并不是精准的计时执行。 (相比之下InvokeRepeating则是非常精准的计时周期。) (但是新手请注意的是,协程绝不是为了让你做开枪间隔的计时器而设计的。)在IEnumerator Start()内使用yield不会阻塞主线程,可见Start其实也是一种协程调用(Awake不是)。 (注:经常被忽略的是yield return new WaitForFixedUpdate()的使用,可以等待一次物理判定,用于只要一帧检测物理的需求,比如持续一帧的爆炸范围伤害。实例化,物理一次即销毁。) 但如果在Start内yield return null延迟一帧,则后续内容在第二个Update之后执行,见下图,因为第一个Update跟Start同帧执行,而下一个Update赶在了Start协程前面执行协程的等待过程中,禁用GameObject对象会中断协程(这很体贴),但是!禁用脚本组件不会中断。 StopCoroutine可以中断协程对象,但是StopAllCoroutines()只能中断自己脚本中的协程。 下面是一张完整的周期循环图,可以说明很多问题,包括物理判定的先后这一张图就更有趣了关于Enable 和 Disable: 对象在被Destroy之前会调用Disable,对象被实例化在Awake之后调用Enable,但是!这里有个很微妙的关系,如果对象是启用状态,那么Enable紧跟在Awake之后调用,在这段代码中A物体在Awake里实例化B物体,而B物体的Enable抢在A的Enable之前执行,因为B物体的Awake先执行完毕,注意看A物体Awake里的Debug,也在B的Enable之后。但是从Start开始 就恢复正常顺序了。这也是Awake和Start在调用阶段上最大的区别。 还有一点需要注意的是物理周期在实例化当帧马上进行了碰撞判定。再看这张,跟上一张不同的是实例化移动到了Start里,前面的顺序正常,但可以看到区别是B物体的Start改为在A的FixedUpdate之后执行了,但是仍然赶在了同一帧(这对一些极为细致的物理判定微操十分有用)。(此为第一帧的情况,之后Update和FixedUpdate便分道扬镳不再同步执行) 以上,以后有更多测试再补充吧~ 其实很多答案可以从这张著名的周期图上找出,要多观察,不要只是看看,比如很多人的疑问是为什么我在代码里更改不了动画角色的骨骼角度数据?因为Update在Animation周期的前面呀,你改掉之后动画又帮你重置了,所以把修改动画数据的代码写在LateUpdate里就可以了,因为它在Animation周期后面~ 这个图比较老的,其中Animation的周期部分发生了一些变化,其它还是适用当前的~
【萌新治愈求教】装备的搭配选择问题。。。求指导~~~ 今晚我的治愈终于116级了,迫不及待的换上期待已久的巫灵套+黑珍珠将军3件。。。还有我喜爱的白鸦项链。。。 伤心的发现水伤居然比之前水羊+黑珍珠将军3件居然还要低。。。。只有407.。。 感觉直接没法看啊。。。之前公会的人喊我去火羊(对今晚第一次打火羊升的115级。。然后自己看帖子去沙漠做任务混到116.。。。) 我真的不是伸手党啊游戏里有个挺热心的朋友推荐我一个资料网站,我有自己用这个网站的搭配尝试了不同的套装,都是以巫灵为主的。。只有极地碎石者4件+巫灵3件能有233的水伤比现在的搭配能多19点。。。但是仍然好少啊。。。而且比现在的搭配少1射程。(因为不能戴白鸦)可我最喜欢射程了啊。每次看到空血队友点不到都觉得揪心。。。。。可惜战斗面板看不到这个属性。。。 然后我又尝试了各种散件比如巫灵4件+M头 +猪油胸甲和护肩啊。。。射程和移动都很好看。。。可是水伤只有更加悲惨的205加成啊。。。 真的不知道该怎么配了。。。那些600多水伤的治愈都是怎么做到啊。。我觉得能过500我已经开心死了。。。 所以真心求大家指导~~。。。还有更好的配装方案吗?~~~当然最好别贵到不切实际。。。比如沉默杖什么的。。。 我就这一个治愈号。。。公会里的人都4开6开好厉害的说。。。那我觉得我也没什么钱,没有固定队伍,武器还是用的沙滩斧头,最喜欢去打寂静副本而且要3+1比较省钱,寂静我最熟悉啦~~~所以最喜欢去,别的地方没人带呀,面板太低,每天跟野队去寂静为蹭经验练级,本以为今天116了换套装会有个小提升。。唉!!!!!!看来以后还是没人带呢。。。桑心~~只能来求助啦~~~希望还有救。。。图片来自:http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fxiangce.baidu.com%2Fpicture%2Falbum%2Flist%2F6ae269b8521739beed10743f45034e6f37db3b08&urlrefer=be87b08de8bf826da903d0b4fa47f6ed放图求关注求回复~~~
1 下一页