如何避开unity编辑器的那些坑【gad吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：10,267贴子：
如何避开unity编辑器的那些坑收藏
以下总结一部分来自经验之谈，一部分来自其他人的分享。总的来讲，unity开发原型和效果、验证想法，确实是无比便利。可能一个月就把核心玩法做得差不多。强大的编辑器功能让我们也有很大的可扩展空间来协助我们开发工具。可是编辑器是把双刃剑。如果提前看清楚有什么坑在前面，或者其他人踩过什么坑。我想这会对项目风险的把控会有很大帮助。
黄金星玩家
百度星玩家累积成长值为500,
上海西唐生物公司,销售各类科研试剂盒, 专业检测经验,免费实验代测服务.人,鼠, 猪,兔细胞因子ELISA试剂盒, Western,荧光定量PCR代测,抗体,生化,免疫组化试剂
　　避开unity的坑　　1.制作抽象的prefab来做关卡编辑　　尽可能制作抽象的prefab来做关卡编辑，该prefab应该足够抽象简单(只有一个GameObject，然后通过Gizmo来绘制是个不错的手段)，否则以后变化的时候(常见的就是改美术资源)，所有关卡都lost prefab，那么对策划来说是一场灾难。可以考虑通过数据表+编辑器的方式来提供策划操作同时也不再需要担心lost prefab的问题。prefab越简单抽象越不容易丢失，prefab之间嵌套的正确方式是通过链接而不是挂在节点下面。
黄金星玩家
百度星玩家累积成长值为500,
　　2.尽可能避免修改Scene，方法有几种：　　使用xml之类的数据组织场景　　尽量多让scene由prefab组成，这样变动都在prefab上　　使用工具做场景Merge
黄金星玩家
百度星玩家累积成长值为500,
　　3.不要过度依赖Component特性来开发，考虑数据驱动。　　4.逻辑容易散落在编辑器各处，可以做一个中心管理。
黄金星玩家
百度星玩家累积成长值为500,
　　利用unity的特性　　组织好hierarchy，不管是编辑的时候还是运行的时候，编辑的时候可以通过工具来简化组织层级的工作。　　让每个场景自己能跑。　　利用基于组件的架构，尽可能少的使用继承(用C#的话)，多通过组合来完成开发。遇到需要数据访问的通用接口，我们可以通过组合的方式来完成，而不是提供一个公共基类接口来继承，只要大家都认识这个公共组件就可以取到数据了。遇到通用的事件派发，我们可以用字符串拼接的方式派发到指定的对象或者更参数组合派发事件到对象身上。　　框架采用星型架构+事件机制，由于unity3d没有一个所谓的入口函数，不利于代码跟踪，这样的基础架构能带来很多便利。　　unity界面扩展能力很强，而且借助CLR(commom language runtime)的反射能力，C#里面开发界面非常容易。　　做好tag、layer规划，要考虑业务中哪类物体之间需要交互。　　在代码里面get某个prefab或者GameObject，可以考虑利用界面拖目标过来，这样更加直观，而且也能对抗变化，比如目标名字变了也不怕，而且还能节省代码量。
黄金星玩家
百度星玩家累积成长值为500,
　　代码　　这里针对C#，静态强类型面向对象本身就是一个坑，继承带着两个职责，一个是复用代码，一个是接口继承。虽然性能比lua高那么一丢丢，因为性能瓶颈不在业务本身，设计上的问题要严重得多。我认为像lua这种动态语言的元编程才能够贯彻单点真理，通过元编程把真理推导到系统的每一处。让代码始终保持语义，而我认为写业务代码最重要的是保持语义。保持语义的简单有效评判方法就是看这个类中的某个函数，单独看它能否看懂;多个接口能否组成完备的解决方案。静态强类型面向对象语言比较适合需求稳定的严谨的系统开发，而不是游戏开发。容易经过多次的策划需求冲刷，语义很容易扭曲，各种抽象泄露、各种hack。好吧，跑题了。　　Unity3D容易被破解，因为发布版本的IL是非常容易被反编译的，要做好混淆的考虑。在Unity3D中混淆要考虑对编辑器的影响。　　复杂类型尽量使用引用类型，值类型反射麻烦，不方便序列化以及做成编辑器。值类型要小心赋值对象是否只是临时对象。　　引用类型释放之后，引用它的指针会置为null，可以放心使用。　　foreach、linq、协程慎用，反射只在编辑器中使用。　　考虑封装Time，方便做暂停。　　考虑使用调度器来完成功能，而不是在Update自己维护状态，这样做暂停也很容易，代码更清晰，功能更内聚。　　增量更新要一开始就想清楚。
黄金星玩家
百度星玩家累积成长值为500,
　　美术　　Unity3D可以通过扩展编辑器让非技术人员编辑界面来工作，组织好美术资源规格、路径，并且自动生成prefab。游戏场景物件也要规划好逻辑节点，这个也应该通过编辑器扩展好。复杂功能也应该通过编辑器开发给策划微调，特别是可视化比较重要的模块，比如动作调整。　　制作原型美术，让开发提升开发效率。　　有统一的约定，比如模型总是中心对齐，角色总是脚部对齐，统一的缩放、统一的动画骨骼命名，资源有统一的路径。　　支持换装(avatar)要一开始就想清楚。　　资源加载和优化尽可能早地给出雏形(只是雏形，帮助你对需求的把握，因为这时候你还不知道热点在哪)，因为一旦没有规划好异步和资源释放，那么阻塞卡顿和内存飙升那是意料之内的。因为有雏形，那么代码会间接一点，也为改变提供了空间。
黄金星玩家
百度星玩家累积成长值为500,
登录百度帐号推荐应用　　先总结一下今天的收获：在一个脚本类中对其成员变量进行初始化时，什么时候在Awake（）中，什么时候在Start（）中是有讲究的。
　　　　1）当成员变量会被外部脚本引用时，尤其是该成员变量是一个自己定义的非脚本类必须用构造函数初始化的时候。并且，被外部脚本引用指的是 &引用该变量的内部成员函数或属性被外部函数调用的时候&，该成员变量应该在Awake函数中进行初始化。
　　　　2）如果该成员变量只在自身所在的脚本类被引用时，则应该在Start函数中进行初始化。
　　今天遇到的第一个坑就是因为没有注意以上两点。我在Start函数中使用构造函数初始化了一个Poker类，但是这个类的实例在自身的公有方法中，被外部其他脚本调用了。这倒不是最重要的，因为之前我遇到过一次。重要的是：在Update（）函数中拷贝预设体，其Awake（）函数在当前帧的Update中就会被立即调用，但是Start（）函数则会在在下一帧执行。
　　第二个坑是这样的：我将一个共有函数绑定到NGUI的UIButton脚本里的OnClick事件中作为事件处理函数，在这个共有函数中使用了两个if语句，则当事件触发时函数不会被执行，但是我改为 if（）{} else if（）{}就可以执行，明明相同的逻辑却又不一样的结果，让人匪夷所思呀。
　　第三个坑是：在NGUI中有一个大坑，就是创建NGUI中的游戏对象时，如果你使用Instantiate（）函数，创建的控件会非常的大，但是使用NGUITools.AddChild()函数时生成的控件大小就会正好合适。【原因还不祥】
一下我将之前遇到的问题说一下，也是空引用异常的问题，和第一个坑差不多，其实也不能说是坑，而是自己对自己的逻辑没有考虑清楚，将各种类的相互引用考虑进来就会发生问题的。
之前已经实现了跑道的动态生成，今天要是实现的是在动态生成的跑道上的路点处随机产生提前准备好的陷阱预设体。
&&&&&&&& 遇到的问题：因为之前在动态生成跑道时，顺便实现了另一个类，路点管理器类。我们的陷阱就要在路点附近生成，所以，利用之前跑道上自带的路点是很好的选择。但是，将道具生成器脚本类顺利加入到之前的代码还是比较繁琐的。因为封装的函数太依赖于动态生成跑道和记录游戏角色附近的路点这两个逻辑，所以必须再次明白之前是如何设计生成跑道和如何计算路点的，并且这还不是最重要的。
&&&&&&&& 最重要的问题是：在ElementsGenerator脚本类中维护一个List&Transform& waypointList来负责在当前跑道上所有路点处生成障碍物、陷阱。由于是脚本类，所以并不存在构造函数这个概念，所以我就在 Awake（）这个函数中创建waypointList，但是我明明已经创建了该列表，但是总是报空引用这样的错误。我百思不得其解，最后，我明白了为什么？？？
&&&&&&&& 主要问题是：我在PlayMove这个脚本类中的Awake（）函数中对作为单例出现在整个游戏场景中的跑道生成器进行了初始化：raceTrackGenerator.Init ()&& 这里这个函数的初始化是在 waypointList之前执行的【不同脚本中的Awake函数执行顺序我不知道如何确定】。主要问题的产生就是因为跑道生成器初始化时需要调用ElementsGenerator脚本类的GetWaypointList（）函数，但是此时该函数必须的waypointList还没有创建出来。
阅读(...) 评论()Unity3D开发技巧：如何避开unity编辑器的那些坑
招聘信息：
文/瀚阳以下总结一部分来自经验之谈，一部分来自其他人的分享。总的来讲，Unity开发原型和效果、验证想法，确实是无比便利。可能一个月就把核心玩法做得差不多。强大的编辑器功能让我们也有很大的可扩展空间来协助我们开发工具。可是编辑器是把双刃剑。如果提前看清楚有什么坑在前面，或者其他人踩过什么坑。我想这会对项目风险的把控会有很大帮助。避开unity的坑1.制作抽象的prefab来做关卡编辑尽可能制作抽象的prefab来做关卡编辑，该prefab应该足够抽象简单（只有一个GameObject，然后通过Gizmo来绘制是个不错的手段），否则以后变化的时候（常见的就是改美术资源），所有关卡都lost prefab，那么对策划来说是一场灾难。可以考虑通过数据表+编辑器的方式来提供策划操作同时也不再需要担心lost prefab的问题。prefab越简单抽象越不容易丢失，prefab之间嵌套的正确方式是通过链接而不是挂在节点下面。2.尽可能避免修改Scene，方法有几种：使用xml之类的数据组织场景尽量多让scene由prefab组成，这样变动都在prefab上使用工具做场景Merge3.不要过度依赖Component特性来开发，考虑数据驱动。4.逻辑容易散落在编辑器各处，可以做一个中心管理。利用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)要一开始就想清楚。资源加载和优化尽可能早地给出雏形(只是雏形，帮助你对需求的把握，因为这时候你还不知道热点在哪)，因为一旦没有规划好异步和资源释放，那么阻塞卡顿和内存飙升那是意料之内的。因为有雏形，那么代码会间接一点，也为改变提供了空间。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量10968点击量8300点击量7901点击量7805点击量7379点击量6153点击量5580点击量5244点击量4906
&2016 Chukong Technologies,Inc.
京公网安备89Unity 3D BehaviorDesigner初用 一些小坑 - 暗光之痕的博客 - CSDN博客
Unity 3D BehaviorDesigner初用 一些小坑
版本：unity 5.4.1& 语言：C#
突然发现漏了一章，不过我看了书之后真是一脸懵逼，这本书介绍的知识都是非常实用，但一些勘误和篇幅的原因，真正要学习该知识的话必须自己查资料去深入了解，这本书只是带个头吧。
BehaviorDesigner行为树插件，这个东西其实是用图形界面来处理复杂的AI问题，这类图形插件的学习最好是看视频，这里推荐一下泰课上siki老师的教学视频，老师讲得不错，我也得多多学习！
这里介绍几个小坑吧，首先是以下错误：
CreateInstanceFromType is not allowed to be called from a ScriptableObject constructor (or instance field initializer), call it in OnEnable instead. Called from ScriptableObject 'BehaviorDesignerWindow'See &Script Serialization& page in the Unity Manual
for further details.
反正我也没怎么看懂，一开始以为是我用的版本问题，因为下载的是siki老师的破解包，他用的是5.3.1的，我就去下了一个，结果还会报错。
问题是什么呢？打开编辑器后有个Inspector，里面有个Comment，这玩意应该是注释，但是你只要用了这个，在里面写了内容就会报错，简直强迫症的噩梦，所以这个报错即使你不理它也是没有问题的。
然后打Log，我一直打不出Log原因跟上面的错误也是直接相连的，就是我把Log信息放到了Comment中。。。输出Log应该放到Text的内容中。
行为树插件的基本使用看了视频后基本没有问题了，简直强大到没有朋友，配合上Animator或者Animation可能不用写代码了。
程序员的作用也就越来越小了。。。哈哈，下周继续。
我的热门文章}