1. 项目概述：为什么我们需要一个运行时关卡编辑器？

如果你在Unity3D里做过稍微复杂点的项目，尤其是那些需要频繁调整关卡布局、摆放物件、测试玩法节奏的游戏，那你一定对“编辑-构建-运行-修改-再构建”这个循环深恶痛绝。每次想微调一下某个平台的位置，或者给场景里临时加个测试用的道具，都得退出游戏，回到Unity编辑器，改完再点播放，运气不好还得重新打包。这个过程不仅打断心流，更严重的是，它让快速迭代和现场调试变得异常低效。

这就是“运行时关卡编辑器”存在的意义。它不是一个独立的软件，而是一套集成在你游戏内部的工具集，允许你在游戏运行的过程中，直接像在Unity编辑器里一样，移动、旋转、缩放物体，创建新物件，甚至修改一些游戏逻辑参数。GILES，全称“Gameplay Integrated Level Editor System”，就是这样一个旨在解决上述痛点的工具。它让你能在真机（比如手机、PC）上运行的游戏里，实时编辑关卡内容，所见即所得，修改结果甚至可以即时保存，下次游戏启动时直接生效。

想象一下这个场景：你的游戏是一个平台跳跃关卡，测试时发现某个跳跃点对玩家来说太难了。传统流程下，你需要记下问题，退出游戏，在Unity里找到那个平台，调整位置，重新运行测试。而有了GILES，你可以在游戏过程中直接暂停，呼出编辑器界面，用鼠标或手柄拖拽那个平台到一个更合适的位置，然后继续游戏，瞬间验证修改效果。这对于独立开发者、小型团队，甚至是大型项目中负责关卡设计的同事来说，效率的提升是颠覆性的。

最近社区里关于Unity3D运行时和编辑器的讨论也很热，比如有人研究ugui+dotween做动态界面，有人折腾模型从SolidWorks导入Unity，还有人在解决各种运行时环境配置问题。这都说明，大家越来越不满足于仅在设计期工作，而是希望将更多的灵活性和控制力延伸到游戏运行的那一刻。GILES正是这种思潮下的一个具体实践，它把一部分编辑器的能力“编译”进了你的游戏里。

2. GILES核心功能与设计思路拆解

2.1 核心需求：从“设计时”到“运行时”的编辑能力平移

GILES的设计目标非常明确：在游戏运行时，复现Unity编辑器场景视图（Scene View）和检视面板（Inspector）的核心交互功能。但这不仅仅是UI的模仿，其背后是一套完全不同的运行时对象管理和序列化体系。

1. 对象选取与变换：在Unity编辑器中，你点击一个GameObject，它会被高亮，并且出现移动、旋转、缩放的Gizmo。在运行时实现这一点，核心是射线检测（Raycasting）。GILES需要一套系统，能够将屏幕点击或触摸位置，转换成场景中的射线，并与可编辑物体的碰撞体进行交互，从而选中目标。选中后，需要在世界空间中绘制出对应的Gizmo（通常是使用GL库或Graphics.DrawMesh来绘制线框），并响应鼠标/触摸的拖拽事件，实时计算位移、旋转或缩放量，并应用到目标物体的Transform组件上。

2. 属性动态查看与修改：这是比变换操作更复杂的一环。在编辑器中，Inspector能列出组件所有可序列化的字段、属性。在运行时，GILES需要通过C#的反射（Reflection）机制，动态获取被选中物体上所有MonoBehaviour组件，以及每个组件中的公共字段或标记了特定Attribute（如[SerializeField]）的私有字段。然后，它需要为每种数据类型（int, float, string, bool, Enum, Vector3等）生成对应的UI控件（输入框、滑块、下拉菜单等）。当用户修改UI控件的值时，再通过反射将新值写回对应的字段。这个过程必须考虑性能，因为反射开销较大，需要做适当的缓存（例如缓存组件类型和字段信息）。

3. 资源的创建与实例化：在编辑器中，你可以从Project窗口拖拽Prefab到场景。在GILES的运行时版本中，你需要一个“资源仓库”的概念。这通常意味着在构建游戏时，需要将可能用到的Prefab打包进资源包（如使用Addressable Assets系统或Resources文件夹），并提供一个UI列表供用户选择。当用户点击创建时，系统调用Instantiate方法，并在场景中生成该物体的实例，同时这个新实例应该自动进入可编辑状态。

4. 修改的持久化（保存/加载）：这是区分“玩具”和“工具”的关键。运行时编辑的结果如果不能保存，就失去了大部分意义。GILES需要一套序列化方案，将场景中被编辑物体的状态（位置、旋转、缩放、组件属性）保存到磁盘。这不能直接使用Unity的场景文件（.unity），因为那是编辑器格式。通常的做法是定义一种自定义的、轻量级的数据格式（如JSON、二进制），在游戏启动时读取这个数据文件，并按照描述重新实例化和配置场景中的物体。这里的一个高级技巧是“增量保存”，只记录相对于初始状态的变化量，而不是全量数据。

2.2 架构选型：IMGUI vs uGUI vs 自定义渲染

构建GILES的编辑器界面，有三种主要的技术路径：

1. IMGUI (Immediate Mode GUI)：这是Unity内置的旧版UI系统，其API如GUILayout.Label,GUILayout.Button。它的优点是极其轻量，绘制逻辑与游戏逻辑在同一循环中，非常适合这种需要每帧更新、状态简单的调试工具或编辑器界面。代码写起来直观，一个OnGUI函数里就能搞定所有界面绘制和交互逻辑。许多知名的运行时调试工具（如UnityExplorer）都基于IMGUI。对于GILES这种工具，IMGUI是快速原型和开发的绝佳选择，因为它省去了复杂的UI对象树管理和事件绑定。

2. uGUI (Unity UI)：这是Unity当前主流的、基于GameObject的UI系统。你需要创建Canvas、Panel、Button、InputField等UI元素。它的优点是外观美观、布局灵活、动画支持好（结合Dotween做动态效果非常方便，正如网络热词中提到的），并且有成熟的交互事件系统。但如果用于全功能的运行时编辑器，你需要动态创建大量的UI元素来对应不同的物体和属性，管理复杂度会急剧上升。更适合用于制作编辑器中的固定面板，比如工具栏、资源浏览器。

3. 自定义渲染：完全使用Mesh或GL绘制界面，或者使用第三方低层级UI库（如Dear ImGui的Unity移植版）。这能提供最高的性能和最灵活的视觉效果，但开发成本也最高。

GILES的合理选择：对于一个专注于功能的运行时关卡编辑器，采用“IMGUI为主，uGUI为辅”的混合架构是最务实的。核心的编辑器窗口（物体列表、属性面板、Gizmo操作提示）使用IMGUI快速实现，因为它状态管理简单，与游戏逻辑结合紧密。而一些需要精美布局和交互动效的部分，比如主菜单、模式切换按钮、颜色选择器等，可以使用uGUI预制体来构建，并动态加载显示。这样既保证了核心编辑功能的开发效率，又能在用户体验上做到一定程度的提升。

注意：使用IMGUI时，务必注意它的执行顺序和性能。所有OnGUI调用都在主线程，如果界面元素过多，每帧绘制大量控件会导致明显的CPU开销。需要做好优化，比如只绘制当前激活的窗口，对长列表使用滚动视图并做虚拟化处理。

3. 核心模块实现与实操要点

3.1 运行时对象选取与Gizmo交互系统

这是编辑器最“手感”的部分，目标是让用户感觉和在Unity编辑器里操作一样自然。

1. 射线检测与对象高亮：

// 伪代码示例：在编辑模式下的Update中处理选取 if (IsEditModeActive && Input.GetMouseButtonDown(0)) { Ray ray = EditorCamera.ScreenPointToRay(Input.mousePosition); RaycastHit hit; // 只与可编辑层的物体进行碰撞检测 int editableLayerMask = 1 << LayerMask.NameToLayer("Editable"); if (Physics.Raycast(ray, out hit, Mathf.Infinity, editableLayerMask)) { GameObject selectedObj = hit.collider.gameObject; // 清除之前的高亮 ClearPreviousSelectionHighlight(); // 高亮当前选中对象（例如，附加一个外发光或线框渲染组件） HighlightObject(selectedObj); // 设置当前选中对象 CurrentSelectedObject = selectedObj; // 为选中对象生成并显示Gizmo ShowGizmoForObject(selectedObj); } else { // 点击空白处，取消选择 ClearSelection(); } }

关键在于“可编辑层”。你需要为所有允许在运行时编辑的物体设置一个特定的Layer（如“Editable”）。这样在射线检测时，可以过滤掉UI、特效等不需要编辑的物体，提升效率和准确性。高亮效果可以通过动态添加一个Outline Shader组件，或者使用Graphics.DrawMesh绘制一个半透明的包围盒来实现。

2. Gizmo的实现：Gizmo通常包含三个部分：移动（Translate）、旋转（Rotate）、缩放（Scale）的手柄。每个手柄是一个小的3D模型（如箭头、圆环、方块）。

• 交互判断：当鼠标在屏幕上移动时，需要发射射线检测是否与某个Gizmo手柄相交。这需要为每个手柄设置一个简单的碰撞体（如BoxCollider）。检测到相交后，根据手柄类型（X轴箭头、XY平面方块等）进入不同的拖拽模式。
• 变换计算：在拖拽过程中，需要将鼠标在屏幕上的二维位移，转换为物体在世界空间或本地空间的三维变换。
  • 移动：最常用的是将鼠标位移投影到某个平面（如地面平面或物体自身坐标系下的某个平面）或轴上，计算偏移量。

  // 例如，沿世界X轴移动 if (currentGizmoType == GizmoType.TranslateX) { // 计算射线与垂直于X轴的平面的交点 Plane dragPlane = new Plane(Vector3.right, selectedObject.position); float enter; if (dragPlane.Raycast(currentMouseRay, out enter)) { Vector3 hitPoint = currentMouseRay.GetPoint(enter); // 根据上一帧的交点计算位移差 Vector3 delta = hitPoint - previousHitPoint; // 只应用X轴分量 selectedObject.position += Vector3.Project(delta, Vector3.right); } }

  • 旋转：通常围绕某个轴旋转。计算鼠标绕旋转中心的角速度或角度变化。
  • 缩放：根据鼠标位移，按比例改变物体局部缩放值。
• 视觉反馈：在拖拽时，Gizmo和被编辑物体的视觉反馈要即时、准确。可以改变Gizmo手柄的颜色，或者实时绘制辅助线、网格。

实操心得：Gizmo的交互手感是编辑器好用的灵魂。建议参考Unity编辑器本身或者Blender等专业软件的行为。一个常见的坑是“万向节锁”和坐标系选择（世界坐标 vs 本地坐标）。务必提供切换坐标系的功能，本地坐标对于编辑复杂层级的子物体至关重要。

3.2 动态属性面板的实现

属性面板是编辑器的“大脑”，它需要智能地应对各种组件和数据类型。

1. 反射与字段发现：

// 获取选中物体所有MonoBehaviour组件 MonoBehaviour[] comps = selectedObject.GetComponents<MonoBehaviour>(); foreach (var comp in comps) { if (comp == null) continue; // 处理可能丢失的脚本 Type compType = comp.GetType(); // 获取所有公共字段，以及标记了SerializeField的私有字段 FieldInfo[] fields = compType.GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance); foreach (var field in fields) { // 过滤掉不需要显示的字段（如标记了NonSerialized或HideInInspector） if (field.IsPrivate && !field.IsDefined(typeof(SerializeField), true)) continue; if (field.IsDefined(typeof(HideInInspector), true)) continue; // 根据字段类型field.FieldType，生成对应的UI控件 DrawFieldUI(field, comp); } // 同样可以处理属性（Property） }

这里需要建立一个类型到UI绘制方法的映射字典。例如，int类型画一个IntField，float画一个FloatField或滑块，bool画一个勾选框，Vector3画三个FloatField，Enum画一个下拉菜单。

2. UI控件的绘制与数据绑定：使用IMGUI时，数据绑定是“即时模式”的，逻辑相对直接。

void DrawFloatField(FieldInfo field, object componentInstance) { float oldValue = (float)field.GetValue(componentInstance); GUILayout.Label(field.Name); float newValue = EditorGUILayout.FloatField(oldValue); // 注意：这里需要实现一个运行时的FloatField if (!Mathf.Approximately(newValue, oldValue)) { field.SetValue(componentInstance, newValue); // 标记对象已修改，需要保存 MarkObjectDirty(componentInstance); } }

难点在于实现运行时的EditorGUILayout类似功能。你需要用基础的GUILayout.TextField来接收输入，并做类型转换和验证。对于滑块，可以用GUILayout.HorizontalSlider。

3. 特殊类型的处理：

• 游戏对象引用：需要提供一个对象选取器，可能是一个弹出窗口列出场景中所有物体。
• 材质、纹理等资源引用：这更复杂，可能需要一个简化的资源浏览器，列出项目中已知的资源。
• 数组和列表：需要能动态折叠/展开，并允许增删元素。这是属性面板中最具挑战的部分之一，因为涉及嵌套的UI生成和数据结构操作。

注意事项：反射虽然强大，但频繁使用会影响性能。一个优化策略是，在第一次获取某个组件类型的字段信息后，将其缓存起来。下次遇到同类型的组件时，直接使用缓存的信息来生成UI，避免重复的反射调用。

3.3 资源管理与场景序列化

1. 运行时资源加载：你不能在运行时直接访问Unity工程中的Assets目录。因此，所有需要在GILES中创建的Prefab，必须提前打包到游戏可访问的位置。

• Resources文件夹：最简单的方法是将Prefab放入Resources文件夹，使用Resources.Load<GameObject>("PrefabPath”)加载。但Resources系统有缺点，容易导致包体臃肿，且无法动态更新。
• Addressable Assets System：这是Unity官方推荐的现代资源管理系统。你可以将Prefab标记为Addressable，并设置一个标签（如“RuntimeEditable”）。在GILES中，通过地址或标签来异步加载这些资源。这种方式支持热更新和更精细的内存管理。

// 使用Addressables加载 using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; AsyncOperationHandle<GameObject> handle = Addressables.LoadAssetAsync<GameObject>("MyEditablePrefab"); handle.Completed += (op) => { if (op.Status == AsyncOperationStatus.Succeeded) { GameObject prefab = op.Result; // 现在可以实例化prefab了 } };

在GILES的资源面板中，你需要遍历所有标记为可编辑的Addressable资源，并显示其缩略图和名称。

2. 场景状态序列化：保存场景时，你不能保存整个场景，而是保存场景中“动态编辑过”的物体的状态。

• 数据模型设计：定义一个可序列化的数据类，用来描述一个游戏对象的状态。

[System.Serializable] public class GameObjectData { public string name; public string prefabAddress; // 或Resources路径，用于重建 public Vector3 position; public Quaternion rotation; public Vector3 scale; public List<ComponentData> componentDataList; // 组件自定义数据 } [System.Serializable] public class ComponentData { public string componentType; // 组件类型全名 public List<PropertyData> properties; // 属性名和值的键值对 } [System.Serializable] public class SceneData { public List<GameObjectData> gameObjects; }

• 保存过程：遍历场景中所有可编辑对象（可以有一个RuntimeEditable标签的组件来标记），将其状态转换为GameObjectData，收集到SceneData中，最后使用JsonUtility.ToJson或BinaryFormatter（注意安全性）将其保存到Application.persistentDataPath下的一个文件中。
• 加载过程：游戏启动时，检查是否存在保存的场景数据文件。如果存在，读取并解析SceneData。对于每个GameObjectData，根据prefabAddress异步加载Prefab并实例化，然后根据数据设置其Transform和各个组件的属性。

实操心得：序列化时，要特别注意对特殊类型（如颜色、枚举、自定义结构体）的处理。JsonUtility对于Unity的基本类型（Vector3,Color等）支持很好，但对于自定义类，需要标记[Serializable]。另外，保存和加载应该是异步操作，避免卡顿。对于大型关卡，可以考虑分块保存和加载。

4. GILES的集成、优化与工作流

4.1 将GILES集成到你的项目

GILES不应该成为你游戏核心逻辑的一部分，而应该是一个可选的、条件编译的模块。

1. 使用编译指令隔离代码：这是最关键的一步。所有GILES相关的代码（编辑器窗口类、Gizmo渲染、属性面板逻辑）都应该用#if UNITY_EDITOR || DEVELOPMENT_BUILD预编译指令包裹起来。

#if UNITY_EDITOR || DEVELOPMENT_BUILD public class RuntimeLevelEditor : MonoBehaviour { // ... GILES的所有核心代码 } #endif

这样，在发布正式版本（Development Build未勾选）时，这些代码根本不会被编译进游戏，不会增加包体大小和产生任何性能开销。你只需要在开发测试时，通过某种方式（如特定的快捷键组合、隐藏菜单）来激活它。

2. 创建编辑器激活入口：通常，你会创建一个空的GameObject，挂载一个RuntimeEditorManager脚本。这个脚本在Awake中检查是否处于编辑模式。

public class RuntimeEditorManager : MonoBehaviour { void Awake() { #if UNITY_EDITOR || DEVELOPMENT_BUILD // 检查是否通过快捷键或命令行参数启用编辑器 if (Input.GetKey(KeyCode.LeftShift) && Input.GetKeyDown(KeyCode.F12)) { InitializeRuntimeEditor(); } #else // 正式版中，直接销毁这个管理器 Destroy(this.gameObject); #endif } void InitializeRuntimeEditor() { // 实例化GILES的UI Canvas，注册输入事件等 } }

激活方式可以很多样：双击屏幕特定区域、在游戏中输入作弊码、通过设备摇动（移动端）等。

3. 标记可编辑对象：为需要运行时编辑的对象创建一个简单的标记组件。

public class EditableObject : MonoBehaviour { // 可以在这里添加一些元数据，比如在编辑器中显示的图标、是否允许缩放等 }

在GILES的射线检测中，只选取带有EditableObject组件的物体。你也可以用Layer来实现，但组件方式更灵活，可以附带更多信息。

4.2 性能优化与内存管理

运行时编辑器本身是个“负担”，优化至关重要。

1. Gizmo与UI渲染优化：

• Gizmo绘制：使用CommandBuffer或Graphics.DrawMeshNow进行批量绘制，减少Draw Call。只在选中物体或进入编辑模式时才绘制Gizmo。
• IMGUI优化：IMGUI的OnGUI调用非常耗CPU。确保：
  • 将复杂的、不需要每帧更新的UI部分（如资源库）放在折叠区域，默认收起。
  • 使用GUILayout而不是GUI，但也要避免过度嵌套的GUILayout区域。
  • 对于长列表，手动实现滚动视图，并只绘制视口内的项（即UI虚拟化）。

2. 反射与缓存：如前所述，缓存组件和字段信息。可以设计一个TypeInspectorCache类，在首次遇到一种组件类型时，解析其所有可编辑字段并生成对应的UI绘制委托，之后直接调用委托，避免重复反射。

3. 资源加载与卸载：

• Prefab缓存：加载过的Prefab应该缓存在一个字典里，避免重复的Resources.Load或Addressables.Load。
• 及时卸载：当关闭GILES或切换场景时，卸载为编辑器加载的临时资源（如图标纹理、Gizmo网格）。

4. 输入处理：编辑器的输入（鼠标拖拽Gizmo、UI交互）需要与游戏本身的输入（角色移动、射击）完美隔离。通常通过一个“输入模式”状态机来管理。当编辑器激活时，游戏输入被禁用，所有输入事件先由GILES处理，如果GILES未消费该事件，再传递给游戏逻辑。

4.3 构建一个高效的工作流

有了GILES，你的关卡设计和调试流程可以彻底改变。

1. 快速原型搭建：在游戏初期，你可以用一些基础几何体（方块、球体、胶囊）快速搭建关卡白模。运行游戏，用GILES实时调整它们的位置和大小，直到玩法感觉对了。然后保存这个布局，这个数据文件可以直接作为关卡设计师在Unity编辑器中精细打磨的蓝图。

2. 实时数值平衡：对于游戏性参数（如敌人血量、武器伤害、技能冷却时间），如果它们被暴露为组件中的公共字段，你可以直接在运行时游戏中暂停，调整这些数值，然后继续游戏，立即感受变化。这比改代码、重新编译、重新运行快了几个数量级。

3. 客户端现场调试与反馈：如果你的游戏有测试团队或早期用户，你可以发布一个带有GILES的Development Build版本给他们。当他们遇到一个疑似关卡设计问题（如卡在某个角落）时，他们可以激活编辑器（如果你给了他们方法），稍微移动一下障碍物，然后继续游戏，看问题是否解决。他们甚至可以保存修改后的场景文件，发回给你。这极大地简化了问题反馈和复现的流程。

4. 与版本控制的协作：GILES保存的关卡数据文件（JSON或二进制）是纯数据。你可以将这些文件纳入你的版本控制系统（如Git）。设计师和开发者可以并行修改不同的关卡数据文件，合并冲突也比合并Unity场景文件（文本模式虽可读但复杂）要直观得多。

注意事项：虽然GILES强大，但必须建立严格的使用规范。要明确区分“设计期数据”（原始Prefab、核心配置）和“运行时编辑数据”（布局微调、临时参数）。运行时编辑的数据应该是可被覆盖、可重置的。核心的游戏平衡和设计，最终还是要回归到Unity工程中的可版本控制的源文件里。GILES是强大的辅助和加速器，而不是替代品。

5. 常见问题排查与实战技巧实录

即使按照最佳实践来构建GILES，在实际开发和使用中还是会遇到各种问题。这里记录一些典型坑点和解决思路。

5.1 Gizmo交互失灵或不准

问题现象：鼠标很难选中Gizmo手柄，或者拖拽时物体移动方向诡异，不受控制。

排查思路：

1. 射线检测层（Layer）设置：这是最常见的原因。确保你的Gizmo手柄物体被分配到了一个专用的Layer（如“Gizmo”），并且你的Gizmo交互脚本中的射线检测只针对这个Layer。同时，确保游戏中的其他物体（尤其是大型地面或背景）没有意外地被分配到这个Layer，否则它们会“挡住”射线。
2. Gizmo碰撞体大小：在3D空间中，屏幕上的一个像素对应的世界空间大小会随着摄像机距离变化。如果你的Gizmo手柄碰撞体（如BoxCollider）大小是固定的，当摄像机拉远时，手柄在屏幕上变得很小，射线就很难命中。一个技巧是根据物体到摄像机的距离，动态缩放Gizmo及其碰撞体的大小，使其在屏幕上始终保持一个可点击的视觉大小。
3. 坐标系混淆：拖拽计算错误，比如想在世界X轴移动，结果物体斜着飞走了。检查你的拖拽平面计算和位移投影代码。务必在拖拽开始时，将相关的向量（如平面法线、投影轴）从本地坐标系转换到世界坐标系（或反之）存储下来，并在整个拖拽过程中使用这个初始值进行计算，而不是每一帧都重新转换，因为物体的旋转可能在拖拽过程中发生变化。
4. UI遮挡：如果你的GILES有IMGUI或uGUI界面，这些UI元素默认会拦截输入事件。确保在检测3D物体Gizmo的射线检测之前，先检查鼠标位置是否落在了任何编辑器UI元素上。如果是，则应跳过3D交互。

5.2 属性面板显示为空或字段丢失

问题现象：选中物体后，属性面板是空的，或者某个你知道存在的公共字段没有显示出来。

排查思路：

1. 字段可见性：记住，默认情况下，只有public字段，或者标记了[SerializeField]的private/protected字段才会被序列化，也才是GILES通过反射能够“看到”的。检查你的组件字段是否有正确的访问修饰符和序列化标记。
2. 类型不支持：你自定义的class或struct，如果没有标记[System.Serializable]，JsonUtility和反射系统可能无法处理它。确保所有需要显示的自定义数据类型都是可序列化的。
3. 属性（Property）与字段（Field）：默认的反射GetFields()只获取字段，不获取属性（get/set）。如果你希望通过属性面板编辑属性，需要额外使用GetProperties()方法。但要注意，只有具有set访问器的属性才可编辑。
4. 脚本编译错误或丢失：如果组件对应的脚本在项目中已删除或存在编译错误，GetComponents<MonoBehaviour>()返回的数组中，该组件会变成null。你的代码需要处理这种null情况，否则在获取其类型时会抛出异常。
5. 缓存失效：如果你使用了字段信息缓存，但在游戏运行时动态添加了新的组件类型（例如通过代码AddComponent了一个之前从未出现过的类型），缓存里可能没有它。需要实现缓存未命中时的回退机制，动态解析并加入缓存。

5.3 保存/加载后物体状态异常

问题现象：编辑后保存场景，退出游戏再重新进入，加载的场景中物体位置、旋转或组件属性不对。

排查思路：

1. 序列化精度问题：特别是旋转使用四元数（Quaternion）表示。JsonUtility在序列化Quaternion时的精度损失，可能导致加载后的旋转有极其微小的偏差，在多次保存加载后可能累积。对于关键变换，可以考虑序列化欧拉角（Vector3），但要注意万向节锁。或者，使用二进制序列化（如BinaryFormatter，但需注意安全性和跨平台性）或更高精度的JSON库。
2. 引用丢失：如果你的组件字段引用了场景中的另一个GameObject（public GameObject target;），序列化时保存的是该对象的实例ID或路径。加载时，你需要根据这个ID或路径去查找新实例化场景中的对应物体并重新建立引用。这个过程（常称为“引用解析”）很容易出错，特别是当物体是动态生成的时候。一个更稳健的方法是，使用唯一的标识符（如GUID）来标记物体，保存和加载时都通过GUID来查找。
3. Prefab实例化路径错误：保存的GameObjectData中的prefabAddress（Resources路径或Addressables地址）必须100%准确。一个常见的错误是路径大小写不一致，或者Resources子文件夹结构在构建后发生了变化。使用Resources.Load时，确保路径不包含扩展名，且相对于Resources文件夹。使用Addressables时，确保地址的拼写和你在Groups中配置的一模一样。
4. 加载顺序依赖：如果物体A的脚本在Start或Awake中需要访问物体B的组件，但加载序列化数据、实例化并设置物体B的属性发生在物体A的Awake之后，那么物体A的初始化就可能失败。解决方法是，将所有对象的初始化从Awake/Start中分离出来，在GILES完成所有物体的加载和属性设置后，手动调用一个统一的Initialize()方法。

5.4 在移动设备（iOS/Android）上的适配

问题现象：在PC上运行良好的GILES，在手机或平板上一塌糊涂：点选不灵、UI错位、性能卡顿。

排查思路与技巧：

1. 输入适配：将鼠标点击逻辑改为触摸逻辑。Unity的Input类同时处理鼠标和触摸，Input.GetMouseButtonDown(0)在移动端对应第一个触摸点。但是，Gizmo交互在触摸屏上会非常困难，因为手指不精确。解决方案是：为移动端设计一个“选择模式”。例如，先点击一个物体选中它，然后通过屏幕上的虚拟摇杆或滑块来调整位置/旋转/缩放，而不是直接拖拽3D Gizmo。
2. UI缩放与布局：PC的IMGUI默认尺寸在手机小屏幕上会显得极其拥挤。你需要根据屏幕DPI动态缩放整个IMGUI的样式（GUI.skin或GUIStyle）。更好的方式是，为移动端单独设计一套更简洁的uGUI界面，用大按钮和清晰的布局。
3. 性能红线：移动设备的CPU和GPU性能远弱于PC。必须进行更激进的优化：
   • 彻底禁用或简化Gizmo：在移动端，可以考虑只显示一个包围盒，不显示复杂的轴向手柄。
   • 大幅减少属性面板的更新频率：不要每帧都重绘整个面板。只有当选中的物体或字段发生变化时才重绘。
   • 谨慎使用反射：移动端对反射带来的开销更敏感。确保缓存做到极致。
   • 条件编译：确保移动端发布版本完全剥离GILES代码。
4. 存储权限：在移动端，Application.persistentDataPath是安全的可写目录。但确保你的保存/加载文件操作放在非主线程，或者使用异步IO，避免卡顿。

一个实用的移动端适配技巧：实现“远程编辑”与其在性能受限的移动设备上运行完整的GILES，不如考虑另一种架构：在PC上运行一个编辑器服务器，移动设备上的游戏作为客户端连接到服务器。你在PC的服务器界面上进行编辑，操作指令通过网络实时同步到移动设备上的游戏场景中。这样，移动设备只负责渲染和接收指令，所有的编辑逻辑和复杂UI都在PC上完成。这可以通过简单的TCP/UDP或WebSocket连接来实现，虽然增加了网络复杂度，但提供了最好的移动端编辑体验。这对于需要在真机上调试AR/VR或特定移动设备交互的项目尤其有用。

GILES这样的工具，其价值在于它模糊了开发与测试的边界。它把调试和迭代从一种打断性的、回溯性的工作，变成了一种沉浸式的、前瞻性的创作过程。当你真正用它来打磨你的游戏关卡时，你会发现很多之前被繁琐流程所掩盖的设计问题，会更快地浮现并被解决。它需要的不仅仅是一套代码，更是一种思维方式的转变——让你的游戏在诞生之初，就具备自我调整和进化的能力。