君，已阅读到文档的结尾了呢~~
广告剩余8秒
文档加载中
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
Unity3D游戏开发
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口那些事情是用Unity开发项目应该一开始规划好的？如何避免后期酿成巨坑？
我们都有一种体验，每次做完一个项目，必然有很多感慨和愤恨，希望在下个项目一定要避免，要做的更好的。希望大家能讲一讲用Unity作项目后，如果在做一个项目，有哪些点是希望一开始就规划好？有那些点希望能警示后人一定要注意的？
总的来说，unity没有啥天坑。只要肯研究，后期都能改进，也都不会影响到上线。小坑太多，说不完。unity上手容易坑太多，基本事件机制，生存周期，场景和资源管理，mono虚拟机的gc机制都是坑。要说的话，真正影响到架构的是（排序）1. 是否要用lua2. （对于需操作的游戏）客户端游戏如何做战斗验证-----------------------------------------------------公司的话，推荐：参加Unity年会购买Unity的官方支持问答平台，人有源代码，还能找总部-----------------------------------------------------下面列举小坑吧。不建议都绕开，毕竟没有那么多时间做前期调研的。对应版本Unity4.x1. 客户端程序层面总的来说C#超级给力的，不过别玩脱了1) mono虚拟机gcUnity的mono虚拟机使用不分代的gc算法，临时对象积攒起来，导致重量级GC游戏频繁卡顿。Unity官方：认真review每帧20B以上，以及一次2K以上的GC Alloc的行为。传闻：Unity5会改进。推荐阅读：评价：请像C++一样精确了解各种行为的gc，foreach 都不要随便用。严重，但游戏是可以卡巴卡巴上线的。后期一位核心开发人员修2~3周。2) 苹果aot编译问题：模板问题mono在苹果上采用aot将C#编译为静态代码。首先，依赖于动态代码生成的复杂模板容易运行时崩溃；其次，mono会将客户端生成一个库。模板代码实例化容易膨胀导致该库超过40M而无法链接。实战：碰到了改写法吧。不过我本人是静态类型检查派的。3) 少用coroutineyield只支持try--finally，与异常体系兼容性极差；难以提供返回值；异步本身是非线性的，很难保证逻辑完备实战：复杂异步逻辑用状态机。不致命，多修bug也能抗过。4) 自行处理配置数据序列化严重影响配置读取速度。C#自带的xml序列化很慢，自带的二进制序列化也不够快。实战：打包配置考虑protobuf或者代码生成器。中后期一周左右。5) 反射手机上jit情况下，第一次反射一个类很慢。乱用足够影响启动速度。6) 本地化如果公司习惯于做海外市场，一开始就可以考虑全套本地化方案。后期改需要一个人1~2个月工作量。2 资源优化Unity资源优化，一个靠谱的TA很重要。1) 资源内存占用512内存机器能用的资源大概只有50~60M。需透彻研究贴图。考虑换皮怪资源复用、UI的图集合理化。没有UI优化经验的话，强烈建议一个核心开发死跟，像抠代码优化一样优化图集总结经验。这个后期很难收场。每个粒子发射器占用10K内存；有些项目在动画上会有内存问题。2) 关注资源包大小最大的是贴图和骨骼动画。贴图关注内存即可。骨骼动画可以占到模型的一半大小，重做的话有各种优化方案。但超标后期也很难收场。3) 依赖打包Unity4.x和Unity5完全不同。其中Unity4.x机制庞大繁杂容易错，要有心理准备。扯一些要点：* 一定要搞清其内存占用和生存周期。要实测，特别容易跌眼镜。* 每个API都有坑。我个人目前推荐压缩模式、LoadFromCache，此时不能拆太碎。战斗前预加载。* shader加载慢，应当放入依赖包* bundle不能重名4) 场景、drawcall、camera场景面多了考虑动态batching不同材质透明物体（例如粒子）穿插可能引起drawcall暴增。camera是重型对象，越少越好5) svn资源选Text模式、显式保存.meta，便于版本管理。资源分人或者锁了改，规避冲突。3 Unity和Flash一样容易学的3D编辑器1 ) 事件机制Unity事件机制很不好用。单个对象，Awake，Start，Enable调用时机相当复杂。Unity完全不保证多个对象的事件执行顺序，导致很多人绕开Start。不恰当的使用事件，很容易导致父子对象不在同一帧出现，画面不干净。Destroy操作是延迟的，对象会活到帧的结尾，然后必定销毁。库级设计时，必须考虑到这一点(例如对象池/动画库)。2) 资源管理只说Unity4.x。合理做法是依赖很卡的UnloadUnusedAssets、LoadScene清理无引用资源（另注意前者是异步的），或者Bundle.Unload(true)，这些方案各有限制。试图更细粒度手工清理的困难在于，并不存在系统性文档解释Unity资源的分类和生存周期，且Destroy操作很保守。例如，销毁mesh时，并不会销毁material、texture，更不会清理脚本资源。此外，特定的普通操作会造成资源克隆。例如访问Renderer.meterial，Animation.AddClip。4 NGUI久经验证的掉链子王。新项目也可以尝尝uGUI1) panel重绘widget改变后，所在panel需要生成多边形，很慢，坑新人没商量，注意合理分panel。panel中多边形过多会爆（貌似是65535个顶点？）。uGUI原理相同，就是c代码比C#快不少。2) panel渲染顺序搞清楚ui上放置3D物体咋办，ui如何和特效混合排序。3) 策划/美术ui规范潜规则很多。Anchor、动画不可作用于同一个物体。widget必须是panel的子节点，不然他就会自己造panel，经常搞出乱子。再加上上面的panel规则等，要策划美术折腾ui可费神了。项目组自制UI编辑器自然是极好的，不过不一定必要。4) 创建速度慢由于序列化字段多，NGUI对象创建可导致卡顿。多状态对象不要靠隐藏-显示，而要动态创建。尤其是状态中包含粒子发生器/Animation，这俩还有内存问题（10K一个）。5) 与Unity事件机制强耦合与Unity的事件机制强耦合，不完备，容易有bug。例如，panel绘制依赖于LateUpdate。coroutine中同时关闭旧界面，创建新界面，此时当前帧 LateUpdate 已过，表现为有一帧画面为空白。----------------------------------------------------------------------------------------正文分割线Q:回答在评论区的问题
“能详细说说使用 UnloadUnusedAssets()、LoadScene() 等等 APIs 的细节吗? 有没有替代方案 ”。A: 需要区分 SceneMemory和Asset。Instantiate出的GameObject及其Component属于SceneMemory。贴图、Mesh、Shader、自定义Component代码、AnimationClip等，还有AssetBundle中的GameObject及其Component属于Asset。Destroy　仅删除SceneMemory对象，不删Asset。UnloadUnusedAssets、LoadScene 检索代码堆（不检查栈），删除所有未引用的Asset。AssetBundle.Unload(true) 删除bundle自有Asset。DestroyImmediate 删除Asset说一下UnloadUnusedAssets慢的原因。核心问题在于，Unity希望C#代码可以引用资源，而且能维持其资源生命周期。然后Unity决定每次UnloadUnusedAssets都去扫描所有C#对象！这个挺慢的。从API看，下面是比较原汁原味Unity的模式，都避免了关卡中间UnloadUnusedAssets：A. 静态关卡关卡进入前加载所有资源，在关卡结束后一次性清理。特别的，Unity觉得你应该使用Scene，他的lightmap、navimesh都是与Scene绑定的。这种情况下，都不需要调用UnloadUnusedAssets()。优点是关卡非常流畅，但是关卡必须是有限大小，有限内容。B. AssetBundle为单位管理动态资源动态资源放到AssetBundle中，不再使用时，用Unload(true)彻底删除Asset。缺点是和A方案比起来加载可能会卡；此外不卸载的bundle本身，合到一起经常有10~30M的额外内存占用。具体游戏，怪物、特效、UI、玩家用A还是B就是权衡问题了。最后，如果觉得Unity不好，可以考虑全手动管理资源，能绕开一些限制，多榨一些性能。如果项目可以有一个人专门深度优化技术，可以考虑尝试，时间两个月起，也会引入不少bug。不少项目是主程做这事，也有让较厉害的程序做这的。
楼上的NGUI好用的很，我基本没遇到什么问题，必须升级到3.0以上版本。说说我所看到unity相关的，不好的习惯：1
尽量不要在Awake(), start()等函数内加入业务逻辑的初始化代码。首先无法简便的直接启动调试查看。逻辑代码依赖太多，很多时候你只是希望检查界面编辑效果，在你不加入逻辑代码直接启动的话，基本会出来一大堆错误。另外，各个脚本start等函数的调用顺序很难控制，不要说可以调整脚本优先级，这个功能大致用用可以，不要依赖它。更何况很多人甚至不知道这个功能。初始化必须要显式调用，除非你知道自己在干什么（比如一些单纯的效果类脚本）。
不要public太多的变量到编辑器中，特别是逻辑变量。尽量减少脚本外部引用特别是对GameObject的引用。这对维护来说真的是一个梦魇，死的很难看。
一个Level内，要控制它的tree层级。你能想象一个MainMenu的level，直接包含了所有的UI，他们直接的脚本相互之间引用Level内GameObject。你能想象一个主脚本内有几十个引用到外部GameObject的变量吗？ 单是要在编辑器内找到这些变量对应的GameObject眼睛都要瞎掉。有时在缺少信息的情况下只能靠猜的。应该把每个功能独立开来做成预制件，每个功能有管理自己的独自脚本组，然后再添加到主level内。这是基本的模块化而已，不能因为unity太好用就可以乱来。
有人似乎意识到了自己public出来的变量太多了，或者纯粹是懒得加了，于是当他确实需要引用某个外部GameObject时，通常都用someobject.getchild(i)来取得引用。 这绝对是值得捅一刀的行为，你的项目如果有人这么用，不要我说了吧。除非父节点之下是一个节点链表（如滑动框集合），否则谁知道getchild(i)得到什么意外？我就发现往某个节点增加了一张图片，然后整个模块的逻辑全乱掉了，这简直是谋杀未遂啊。
管理规划好你的NGUI的depth。2.7版本以下不要随意移动z轴和depth来达到显示效果，永远要有一个基本depth参照值。设计好atlas的划分，如果你不想遇到增加或减
少一张图片就会遇到奇怪的遮盖或消失问题。特别是你的level很庞大时，我发现无解。强烈建议升级到NGUI3.x，痛苦但值得。
coroutine是个好东西，但别滥用。实现一个状态机是有必要的。别的不说，至少不会在所有模块的各个角落里都添加上新手指引的代码了吧？建议仿照boost的statechart写一个简化版本，爽死你。
善用uigrid，uitable。当你写一个背包UI时，还要手动写每个格子的长宽，padding逻辑这是折磨自己，坑死别人，何苦。
规划好你的object的结构，这通常比你所写的脚本更重要。更一般的说，数据结构简单易懂，直接反映问题，这样你的逻辑代码才会清晰简洁。
设计不要超越或强迫程序。比如，要求一部分UI背景处在3D背景之后，其他UI的在3D背景之前，而这个3D场景是游戏主场景，忘了说你还要照顾在这之间穿插的粒子效果呢。我无法理解这种给自己下绊的尴尬决定是如何诞生的。可能2个原因吧，一是之前程序使用NGUI2.7，整个3d场景的layer被设成跟UI一致（无法想象），然后程序通过z轴和depth来达到这些效果。看到这我已经很凌乱了，而且居然无法说服他们这是不对的...
资源命名有待规范，目前资源包括预制件的命名混乱随意。这个是整个项目人员素质问题，或者说缺少个规划。
atlas的资源分布好好好规划。美术风格上尽量使用通用的控件，通用的控件使用的atlas限制一张之内。不要鬼扯什么设计不美观的问题，一张的atlas大小，都容不下你惊人的设计能力？特殊的图片按照level或加载状态分好atlas。尽量做到动态创建销毁。不要包含过多的大图片，能从设计上避免就避免。
我真的不建议把UI直接跟level做在一起。如果是轻UI类型的项目可以。做uiniy要时常考虑一点就是，level，prefab，atlas等等都是个二进制文件，svn下不可比对，意味着你修改某个东西时，在这个level下的所有东西都要被锁定了，其他人只能等你。
SDK接入时，养成代码里就做好平台区分的习惯，用宏加上状态机。因为SDK是个巨坑，先保证己方代码不出错，才能自求多福啊。平台区分代码(宏)，尽量都放在相同的代码段中。
c#的话，模板可能会是个问题。我会告诉你相同的模板代码，在andriod下build通过，在wp8和ios就不行呢。写的朴实点了。
资源方面，请试着封装一个resource manager。加载资源，prefab，level等时想着bundle。到处resource.load是不行的。这是个蛮头痛的问题，我还没真正开始做，异步加载估计有很多问题等着。
在可编辑性和代码控制间权衡好是使用unity的很重要的问题。
unity是个编辑器，意思是不只是程序员用它。请所有相关的开发人员熟悉基本的工作流程与概念。
转自博客：以下总结一部分来自经验之谈，一部分来自其他人的分享。总的来讲，Unity开发原型和效果、验证想法，确实是无比便利。可能一个月就把核心玩法做得差不多。强大的编辑器功能让我们也有很大的可扩展空间来协助我们开发工具。可是编辑器是把双刃剑。如果提前看清楚有什么坑在前面，或者其他人踩过什么坑。我想这会对项目风险的把控会有很大帮助。避开unity的坑尽可能制作抽象的prefab来做关卡编辑，该prefab应该足够抽象简单（只有一个GameObject，然后通过Gizmo来绘制是个不错的手段），否则以后变化的时候（常见的就是改美术资源），所有关卡都lost prefab，那么对策划来说是一场灾难。可以考虑通过数据表+编辑器的方式来提供策划操作同时也不再需要担心lost prefab的问题。prefab越简单抽象越不容易丢失，prefab之间嵌套的正确方式是通过链接而不是挂在节点下面。尽可能避免修改Scene，方法有几种：使用xml之类的数据组织场景尽量多让scene由prefab组成，这样变动都在prefab上使用工具做场景Merge不要过度依赖Component特性来开发，考虑数据驱动。逻辑容易散落在编辑器各处，可以做一个中心管理。利用unity的特性组织好hierarchy，不管是编辑的时候还是运行的时候，编辑的时候可以通过工具来简化组织层级的工作。让每个场景自己能跑。利用基于组件的架构，尽可能少的使用继承（用C#的话），多通过组合来完成开发。遇到需要数据访问的通用接口，我们可以通过组合的方式来完成，而不是提供一个公共基类接口来继承，只要大家都认识这个公共组件就可以取到数据了。遇到通用的事件派发，我们可以用字符串拼接的方式派发到指定的对象或者更参数组合派发事件到对象身上。框架采用星型架构+事件机制，由于Unity3D没有一个所谓的入口函数，不利于代码跟踪，这样的基础架构能带来很多便利。unity界面扩展能力很强，而且借助CLR(commom language runtime)的反射能力，C#里面开发界面非常容易。做好tag、layer规划，要考虑业务中哪类物体之间需要交互。在代码里面get某个prefab或者GameObject，可以考虑利用界面拖目标过来，这样更加直观，而且也能对抗变化，比如目标名字变了也不怕，而且还能节省代码量。代码这里针对C#，静态强类型面向对象本身就是一个坑，继承带着两个职责，一个是复用代码，一个是接口继承。虽然性能比lua高那么一丢丢，因为性能瓶颈不在业务本身，设计上的问题要严重得多。我认为像lua这种动态语言的元编程才能够贯彻单点真理，通过元编程把真理推导到系统的每一处。让代码始终保持语义，而我认为写业务代码最重要的是保持语义。保持语义的简单有效评判方法就是看这个类中的某个函数，单独看它能否看懂；多个接口能否组成完备的解决方案。静态强类型面向对象语言比较适合需求稳定的严谨的系统开发，而不是游戏开发。容易经过多次的策划需求冲刷，语义很容易扭曲，各种抽象泄露、各种hack。好吧，跑题了。Unity3D容易被破解，因为发布版本的IL是非常容易被反编译的，要做好混淆的考虑。在Unity3D中混淆要考虑对编辑器的影响。复杂类型尽量使用引用类型，值类型反射麻烦，不方便序列化以及做成编辑器。值类型要小心赋值对象是否只是临时对象。引用类型释放之后，引用它的指针会置为null，可以放心使用。foreach、linq、协程慎用，反射只在编辑器中使用。考虑封装Time，方便做暂停。考虑使用调度器来完成功能，而不是在Update自己维护状态，这样做暂停也很容易，代码更清晰，功能更内聚。增量更新要一开始就想清楚。美术Unity3D可以通过扩展编辑器让非技术人员编辑界面来工作，组织好美术资源规格、路径，并且自动生成prefab。游戏场景物件也要规划好逻辑节点，这个也应该通过编辑器扩展好。复杂功能也应该通过编辑器开发给策划微调，特别是可视化比较重要的模块，比如动作调整。制作原型美术，让开发提升开发效率。有统一的约定，比如模型总是中心对齐，角色总是脚部对齐，统一的缩放、统一的动画骨骼命名，资源有统一的路径。支持换装(avatar)要一开始就想清楚。资源加载和优化尽可能早地给出雏形(只是雏形，帮助你对需求的把握，因为这时候你还不知道热点在哪)，因为一旦没有规划好异步和资源释放，那么阻塞卡顿和内存飙升那是意料之内的。因为有雏形，那么代码会间接一点，也为改变提供了空间。
说个不大不小的坑吧：DLL模块要事先规划好。Unity会根据Folder自动将所有代码打包成4个DLL，其中两个是Editor的，两个是游戏的。当项目比较大的时候AssemblyCSharp.dll.o在连接时会报连接错误。为了解决单一DLL过大的问题，最简单的方法就是将代码“分摊”到Plugins文件夹里。因为外边的代码对于Plugins里头不可见，所以如果代码的依赖关系一开始没有理顺的话，这将会是一个非常痛苦的过程。因此，尽量在项目初期就确定好DLL的划分（其实本质是代码的单向依赖关系），游戏无关的底层代码尽量往Plugins里头放。能单独做成DLL的一定要提出来打包。代码结构理顺了项目后期会省不少事的。
还记得一个著名球星说的话吗？我最精彩的进球永远是下一个。做了四个小游戏，每次完成之后都会收获良多，下次重复去做的时候，就会少走很多弯路，代码结构更清晰，资源管理更恰当。很多坑，你自己走过之后，才会明白和领悟。加油吧！一开始就规划好是不现实的，人生本就是个摸索的过程嘛。哈哈 unity初学者，spritekit使用了八个月，欢迎交流。
1.整个项目使用的语言，是使用C#还是Unity Script。不建议两者混用，到了后期如果引入plugin可能会引起麻烦。C#已经是最流行的语言，Assets Store里90%甚至更高的插件是用C#编写的。2.如果以后准备跨平台部署（Win，iOS，Android，WP等）在序列化反序列化的代码一定要小心。由于iOS纯AOT的特殊性。导致Emmit代码无法运行。因此在其他平台能够运行得很好的程序到了iOS上要么编译不过，要么运行直接闪退。建议先以iOS为目标平台开发并实机测试项目。保证兼容性。3.scene的内存管理。不要一味的在一个scene中堆砌太多的东西，在Editor或者pc上跑起来很顺畅的scene，会因为场景里物体太多在手机内存不足上直接闪退。到那个时候再来减少物品或者分拆scene就会很痛苦耗时了。在制作之前就好好的规划划分scene，以满足手机内存需求4.如果是新项目，强烈建议使用Unity 4.6.2以后或者最新的Unity5来进行开发。2015年6月以后苹果所有的项目都需要满足64bit发布。这个支持只有4.6.2或者5才支持。而由于Unity后台使用了一个新的IL2CPP技术，导致原来的代码在新技术编译下会出现各种问题。老项目请尽早升级Unity并尝试IL2CPP编译以确定并解决问题。
千万别用ngui .....咳咳都要问理由，好吧 我来说两个故事，第一个故事从前有个人开发了ngui,于是unity请它去开发ugui,后来他被fire了。第二个故事从前有个人叫康托耶夫（不要问我他是谁，我不会告诉你的），他从来不用ngui,因为他觉得ngui是坨屎，但是他从来不去论证这一点，所以他虽然苦口婆心的劝他的朋友不要用ngui,并且告诉他的仇人们要多用ngui,但是他的朋友们都不用他的仇家也不相信他。于是他开始渐渐怀疑ngui不是那么烂，开始怀疑自己的判断。有一天，他的一个朋友请他帮忙，说有一个虚拟现实赛车烂尾了，能不能帮着擦一下屁股，康托耶夫是个好人，就答应了。即使这个项目用的是ngui,即使ngui多层的情况下回选不中后面物体只能在hierachy里面选即使ngui没法再world里面做三维界面正确区分前后层，不能做仪表盘他还是把屁股擦得干干净净，他的朋友都很爱他，然后朋友说，我还有最后一个修正，能不能把其中一个图标换到，康托耶夫痛快的答应了，修改了图片，然后生成了atlas... 然后，，， 然后所有sprite都乱码了。。。。然后就把每个sprite重生成一次，相应的sprite才正常当生成到最后一个的时候，第一个又乱码了。。。他在自挂东南枝之前，留下的一句话是 见第一句
派专人管理资源，美术别自个上传资源，别问我为什么，这都是通宵加班的感悟。
大神们说了很多，我这个只是个附加答案，我觉得小坑太多了~说都说不完。前期把类写好点，然后事件发布、内存池、对象池等等这些让所有人讨论下，写出来，整理下，对以后开发搞模块化很有帮助。
程序功能、架构尽可能的先想清楚。多人开发的话，同步机制也要理清楚。最好是建目录相同的两个工程，一个是客户端工程，另一个是美术资源工程，并且要有专人核对美术资源工程，或是专门开发个检查错误的小工具，来保证资源上传的正确性。
已有帐号？
无法登录？
社交帐号登录