Unity自定义编辑器界面（Inspector）强迫症患者的福利_unity培训吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：16贴子：
Unity自定义编辑器界面（Inspector）强迫症患者的福利
好吧，我承认自己是个强迫症患者，在做项目的时候 发现脚本的Inspector面板上暴露的密密麻麻的变量头皮一阵发麻~~~举个例子 比如我要写 一个 Enemy的类，我希望这个Enemy里面包括了所有的 敌人类型，比如 飞机 坦克等等。但是由于类型不同，他们的一直变量类型也不同，比如 坦克的 变量类型可能有 移动速度，子弹类型，或者其他的，飞机的变量类型有飞行速度，等等。如果不加整理 那么在Inspector 面板就会暴露出密密麻麻的 变量 不仅头晕，而且不利于调试。其实就是我强迫症发作了，我只想面板显示我想要的东西。好吧 下面开始首先 我新建一个 test1 脚本 C# 我们的目标是通过枚举类型来定义当前物体的类型。如果m_type是 player，那么就显示 playerlife；如果是 enemy 就显示enemylife。下面我们需要写一个脚本去重写Inspector界面。新建一个文件夹 命名为 Editor 因为我们需要
using unityEditor 而是用这个的脚本必须在名字为Editor 的文件下。在Editor 文件下创建一个C#新脚本 名字随意 我的叫 Inspector_test1
首先 头部 加入 using UnityEditor [CunstomEditor(typeof(test1))]继承改为 Editor 首先我们要序列化一个物体 就是说脚本会附在一个Object上
还有脚本的变量
在OnEnable（） 里面 初始化 Objcet对象 抓取脚本里面的属性然后 再重写 OnInspectorGUI()
首先是更新脚本的信息test.Update();然后显示枚举类型变量 m_type 这个变量是一定要暴露出来的 因为通过它来定义这个物体的属性 是player 还是 enemy EditorGUILayout.propertyField(m_type);然后 我们来判断这个m_type是哪个值 是player 还是enemy. 我们通过 SerializedProperty.enumValueIndex 枚举值索引 来检索当前枚举类型的变量值是哪个
例如在 type 枚举类型里面 player 的枚举值索引下标为 0 enemy
的枚举值索引下标为 1这样 我们通过判断 m_type 的 枚举下标的值就可以推断出 当前值的哪一个，进而进行相关的操作了。最后，通过SerializedObject.ApplyModifiedProperties 应用修改的属性效果
贴吧热议榜
使用签名档&&
保存至快速回贴unity 读取Excel注意大坑 - 简书
unity 读取Excel注意大坑
前提:使用unity读取excel时，使用如图的dll：
去读取的时候，在编辑器内运行正常，但是在导出时会发现exe在运行时不能正常读取excel。用这个dll可以读取2007以后的格式.xlsx，也可以读取97-2003的.xls。笔者最开始使用的是2007版本，导出exe不能读取数据。解决方法：读取97-2003的文件就可以。但是读取97-2003文档的方法有点不同，//1. Reading from a binary Excel file ('97-2003 *.xls)IExcelDataReader excelReader = ExcelReaderFactory.CreateBinaryReader(stream);//2. Reading from a OpenXml Excel file (2007 *.xlsx)IExcelDataReader excelReader = ExcelReaderFactory.CreateOpenXmlReader(stream);读取到的excelReader有三种方法：选取一种可以使用的（自己多试试哈）//3. DataSet - The result of each spreadsheet will be created in the result.TablesDataSet result = excelReader.AsDataSet();//4. DataSet - Create column names from first rowexcelReader.IsFirstRowAsColumnNames =DataSet result = excelReader.AsDataSet();//5. Data Reader methodswhile(excelReader.Read()){//excelReader.GetInt32(0);}最后上代码：public static void GameReadExcel(string ExcelPath){FileStream stream = File.Open(Application.dataPath + ExcelPath, FileMode.Open, FileAccess.Read);//读取2007以后版本// IExcelDataReader excelReader = ExcelReaderFactory.CreateOpenXmlReader(stream);//读取2003以后版本IExcelDataReader excelReader = ExcelReaderFactory.CreateBinaryReader (stream);result = excelReader.AsDataSet();columns = result.Tables[0].Columns.C//获取列数rows = result.Tables[0].Rows.C//获取行数Debug.Log(columns);Debug.Log(rows);////从第二行开始读//for (int i = 1; i & i++)//{//
for (int j = 0; j & j++)//
string nvalue = result.Tables[0].Rows[i][j].ToString();//
Debug.Log(nvalue);//
}//}}本文如有版权问题请联系作者。 源码地址:/ExcelDataReader/ExcelDataReaderUnity3D开发技巧：如何避开unity编辑器的那些坑 - 简书
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)要一开始就想清楚。资源加载和优化尽可能早地给出雏形(只是雏形，帮助你对需求的把握，因为这时候你还不知道热点在哪)，因为一旦没有规划好异步和资源释放，那么阻塞卡顿和内存飙升那是意料之内的。因为有雏形，那么代码会间接一点，也为改变提供了空间。
Don't reinvent the wheel.}