那些事情是用Unity开发项目应该一开始规划好的？如何避免后期酿成巨坑
那些事情是用Unity开发项目应该一开始规划好的？如何避免后期酿成巨坑
作者：刘源链接：/question//answer/来源：知乎著作权归作者所有，转载请联系作者获得授权。总的来说，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。不少项目是主程做这事，也有让较厉害的程序做这的。单机情况下，靠谱的战斗的模型有2：&纯服务器，客户端只播片; 使用中间语言写纯代码的确定性战斗库，客户端服务器使用同样的输入，获得相同结果。如果从做战斗之前就通盘考虑，一般没什么问题。比较害怕的是，客户端在不考虑验证的情况下先做了战斗，然后一般就很难收场。往往战斗代码涉及到美术资源、甚至涉及到Unity的collider、CharactorController。即使不涉及，可能代码复杂度太高，服务器做起来有坑等等。多人情况就更麻烦。这些都是最初就直接决定整个战斗系统架构的东西。主要是：* 贴图复用需要依赖打包(或者类似机制)* 拆出通用贴图，按类型/风格可以得到自然的正交分类。通用贴图尽量占满图集。对于美术策划，UI尽量统一风格，复用设计，不要老是画新素材。* 警惕所有不能做成九宫格的素材；警惕九宫格的大圆角，大贴花，曲线型高光和阴影* 一般关掉mipmap，但是不绝对。* 部分问题需要复杂方案，例如大面积底纹(大理石纹理/理发店型斜条纹) 。可以考虑shader、自定义widget这些大杀器。* 过大的专用贴图就动态加载卸载吧作者：饭后温柔链接：/question//answer/来源：知乎著作权归作者所有，转载请联系作者获得授权。楼上的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是个编辑器，意思是不只是程序员用它。请所有相关的开发人员熟悉基本的工作流程与概念。作者：fonzieyang链接：/question//answer/来源：知乎著作权归作者所有，转载请联系作者获得授权。以下总结一部分来自经验之谈，一部分来自其他人的分享。总的来讲，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)要一开始就想清楚。资源加载和优化尽可能早地给出雏形(只是雏形，帮助你对需求的把握，因为这时候你还不知道热点在哪)，因为一旦没有规划好异步和资源释放，那么阻塞卡顿和内存飙升那是意料之内的。因为有雏形，那么代码会间接一点，也为改变提供了空间。稍微大一点的项目，我个人倾向于一个Scene就一个唯一的GameObject C#绑定脚本，其他脚本都通过动态加载。动态加载的好处，容易维护，同时比如容易适应变化。感觉脚本绑定这玩意比较鸡肋啊。说个不大不小的坑吧：DLL模块要事先规划好。Unity会根据Folder自动将所有代码打包成4个DLL，其中两个是Editor的，两个是游戏的。当项目比较大的时候AssemblyCSharp.dll.o在连接时会报连接错误。为了解决单一DLL过大的问题，最简单的方法就是将代码“分摊”到Plugins文件夹里。因为外边的代码对于Plugins里头不可见，所以如果代码的依赖关系一开始没有理顺的话，这将会是一个非常痛苦的过程。因此，尽量在项目初期就确定好DLL的划分（其实本质是代码的单向依赖关系），游戏无关的底层代码尽量往Plugins里头放。能单独做成DLL的一定要提出来打包。代码结构理顺了项目后期会省不少事的。程序功能、架构尽可能的先想清楚。多人开发的话，同步机制也要理清楚。最好是建目录相同的两个工程，一个是客户端工程，另一个是美术资源工程，并且要有专人核对美术资源工程，或是专门开发个检查错误的小工具，来保证资源上传的正确性。程序角度，几个点：是否做资源热更新，如果要做，如何组织资源结构，如何打包assetbundle是否做代码热更新，如果要做，规划好，哪些要热更新，哪些不能热更如何差量更新资源，例如一个安装包安装后，资源放在哪里，如何访问，热更新的资源如何访问shader如何管理，（最好是项目开始前，把要用的shader放在一起，即使是系统shader，copy一份出来，不要直接引用系统shader）图片格式如何管理，是alpha分开，还是用unity5.2开始的自动etc2（在某些android模拟器有问题）开始多做demo实验，把每一块都摸清楚，做项目功能，只是项目很小一部分以上脚本可以在项目管理栏里设置标记颜色，然后物体上就会显示脚本标志了。哦,没说清楚,点一下Project里的脚本,然后在Inspector显示的脚本图标上点一下就会有一个select icon的小选项卡,随便挑个颜色这样Scene里的Game object旁边就会显示出带着颜色的脚本标志了..作者：feicheng wu链接：/question//answer/来源：知乎著作权归作者所有，转载请联系作者获得授权。我的代码大概遵循这么几条原则吧（想到哪儿写哪儿不分先后）：1.逻辑脚本基于场景划分2.抽离静态配置数据、全局管理数据以及对局临时数据的管理3.使用单例模式创建不依赖于场景的游戏对象及其上的全局管理器4.避免使用GameObject.Find以及SendMessage，声明对象引用以显示标明脚本之间的依赖性，活用delegate解耦合5.多用组合少用继承（Component的架构真的是太棒了）6.数据行为与逻辑表现分离，即V与MC的分离，换句话说多写class少写MonoBehavior。（通常初期在快速开发原型时会把一个功能全部实现写在一个继承于MonoBehavior的脚本中，尽早进行重构，抽离出负责数据管理与控制的类，这对于后期功能的增加与修改时很有必要的）7.善用Coroutine(Coroutine真是太方便了）8.尽量能够使用自定义的配置文件辅助Prefab上脚本参数的配置。总的来说记得知乎上看到谁说过cocos2d是程序员友好的，而Unity3D是设计师友好的，写了这么多年Unity3D代码我真是觉得我的思考方式越来越像策划而不是程序员了，使用Unity3D开发，写代码应该只占了大概50%的工作，另外50%都在编辑器上，如果你用过相信你懂得。全局管理数据主要就是指跨场景的数据对象，主要有玩家的游戏记录、场景间转换控制参数等等，这些数据往往都是跨场景的因此最好统一在一处进行管理结合第3条。临时对局数据就比如是玩家在游戏场景中的角色属性这种数据，这个数据有可能是基于全局的玩家记录数据生成的，但是要注意二者的区分，主要是想表达这个意思吧。至于第八条只要你还觉得Prefab好用就不用管，主要意思是Prefab应该是用来配置游戏对象结构的，至于其上的数据参数配置应该作为静态配置数据自己管理（这个没必要做就不用做，简单高效优先）如果你的组件是动态创建的，那它的创建者一定可以持有它的引用。如果是定死的话可以在Awake里调用Find一次，并将该引用保持下来。我的意思就是不要滥用Find，因为这会导致你的代码与场景Hierarchy耦合的很死，时间久了无论是场景修改还是代码修改都会很容易产生问题。当然你说的是UI，NGUI为了便于开发，这块设计的就是代码与场景耦合的很紧，所以也不用过于在意这点。作者：欧宇龙链接：/question//answer/来源：知乎著作权归作者所有，转载请联系作者获得授权。有句话，我总会仔细的跟很多朋友讲到做游戏，牛逼的不是实现某一个功能，而是把成百上千的功能放到一起，却不乱。而我认为，这条路，必须自己不断总结反思。别人给的经验，往往并不一定合适具体的项目。不管别的，有几个标准可以检验你的代码是否合理1：美术资源 提交后，策划配表提交后，不需要程序变换，即可立马看到结果。
比如，一个图标变了，美术可以打包图集，提交。 策划变了一个配表，他可以直接提交配表。 一个新的怪物出现了，让美术自己提交怪物资源.....
最后他们自己跑游戏里一看，发现东西是OK 的。
不管你程序如何设计，这事是最重要的一条。
简单来说就是 让美术和策划能够提交后直接看到结果。2：游戏暂停时，能否直接通过 视图窗口，看到尽量多的游戏当前状态。以我做的ARPG为例，再某一下，我一刀挥出去，打到一个怪物了。
再怪物受击的那一瞬间，我点击暂停。这个时候我点击怪物这个GameObject，可以看到怪物当前正在播放那个动画，重力是多少，重力加速度是多少，受击的效果有哪几个，数值分别是多少...
可以通过视图窗口看到当前怪物移动组件是否使用中，AI 组件是不是被停滞掉了.........这个点是存在争议的，诸多从C++过来的朋友，cocos写得多的朋友。并不习惯组件化这样的东西3：是否一个类只干一件事这个同样很重要甚至可以说是需要被确保的。组件化或许这点有些爽。就是基本确保了你写的某个组件只干一件事。开发了3个Unity项目, 想到几个问题需要注意:1. 避免monobehavior脚本滥用, 作为一种需要挂到gameobject的资源脚本, 与很多prefab产生了大量相关性, 造成维护困难, 除非一些不经常修改的, 如ngui的各种资源型脚本, 避免游戏逻辑扑到该脚本上. 写一个健壮的MVC架构, 顶住各种"便利"的实现方式, 是项目成功的必备基础2. 资源目录划分, 涉及到如何打包资源, 如何发布版本, 如何控制资源大小, 做一些你认为可行的划分方式, 如按照图片, 动画, 模型等, 或按照角色, UI, 特效等, 写一些必要的效率插件, 写一个稳定的资源管理框架3. 程序脚本, 美术资源, 策划配置, 常常会因为项目的仓促进行, 导致最终发版本一团乱, 同上述第2点, 前期一定要规划好版本控制方式, 是否采用git, svn, asset server等等, 是否需要开发专用工具导入导出, 版本发布是否需要考虑各种本地化, 渠道分支怎么管理, 甚至开发人员职责如何划分(逻辑程序, 插件程序, 引擎程序等)unity是基于组件开发 一上来确实不太适应，也跟同事讨论了好久，至今没什么太好的结论。说下我们的方案，一.启动场景一个 object上挂脚本主入口，他负责驱动游戏内所有manager的创建,更新及销毁。二.人物,AI等需要继承的通过持有gameObject来是实现。而不是挂载到gameObject上。三.基础功能通过组件实现。挂载到gameObject上。总体上就是最基础层面 负责具体功能的用组件来降低耦合度,这样也清晰。而一些需要始终存在的或者需要继承则通过原来的方式，创建脚本对象，然后持有Object，这是这个object不在负责具体逻辑，只是各个基础功能的总和。首先是几点要在项目初期考虑清楚的东西，会影响到代码组织：是否要做热更新（代码，资源），怎么做？项目是什么类型，有些什么特点，不同类型组织方式不同是否要套用框架（个人不赞成）这几点会影响：如果你要热更新，就不能在prefab上直接挂脚本（prefab上的脚本不能热更新），无论是dll方式，还是lua。如果是lua热更新，要考虑清楚哪些部分用lua，哪些部分用c#，中间如何衔接，c#部分是否通过dll热更？不同的项目，特点很不一样，除掉一些框架性的部分（网络，资源管理等），游戏的框架要因项目而异。大而全的框架，维护和调优都是困难的，且会增大持续开发难度，毕竟手游是个快速产品是否要用框架？（一些mvc框架），个人不赞成游戏套用MVC，MVC更适合软件开发模式，不适合游戏，如果使用，反而会大大臃肿游戏框架。定一个针对项目类型的清晰直接的更好，手游项目，更看重快速迭代，重构，而不是写好一个，通用之。我来说一句，少用挂脚本！少用挂脚本！少用挂脚本！游戏逻辑只用一个Monobehaviour驱动，这样的项目再乱也是有下限的，不知道有多少公司多少项目被滥用挂脚本坑了。
发表评论：
TA的最新馆藏}