Auto-sync: 2026-04-26 12:02

wiki/sources/blender-addon-engineer.md

@@ -0,0 +1,53 @@
+---
+title: "Blender Add-on Engineer Agent Personality"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Blender 工具开发专家 AI Agent 人格规范——通过 Python + bpy API 构建 Blender 原生工具（自定义 Operator、Panel、资产验证器、导出器），将重复性 DCC 工作流自动化为可靠的一键工作流。
+- 问题域：3D 资产生成中的命名漂移、未应用变换、错误材质槽映射、导出配置不一致等交接错误问题。
+- 方法/机制：数据 API（bpy.data）优先于操作符（bpy.ops）以确保可靠性；非破坏性验证优先于自动修复；确定性命名规范；Pipeline 可靠性三角（验证→报告→确认→导出）。
+- 结论/价值：每个工具必须节省时间或防止一类真实的交接错误；Asset Validation 可在资产离开 Blender 前拦截问题；Export Preset 确保引擎端交接的可重复性。
+
+## Key Claims（用中文描述）
+- 主体 + 机制 + 结果：Blender Add-on Engineer 偏好数据 API 访问（bpy.data/bpy.types）而非脆弱的上下文相关操作符（bpy.ops），使得 Operator 行为可预测且稳定。
+- 主体 + 机制 + 结果：验证工具必须在自动修复前报告问题，确保用户知情同意，避免破坏性意外修改。
+- 主体 + 机制 + 结果：批量工具必须精确记录其修改内容，使得 Pipeline 可审计且可回滚。
+- 主体 + 机制 + 结果：导出器必须保留源场景状态，除非用户明确选择破坏性清理，确保交接过程可重复验证。
+
+## Key Quotes
+> "Every tool must save time or prevent a real class of handoff error." — 默认要求：每个工具必须有可量化的价值
+> "Operators must fail with actionable error messages — never silently 'succeed' while leaving the scene in an ambiguous state." — 操作符失败规范
+> "Never destructively rename, delete, apply transforms, or merge data without explicit user confirmation or a dry-run mode." — 非破坏性工作流核心原则
+
+## Key Concepts
+- [[bpy]]：Blender Python API，提供数据访问（bpy.data）和操作符执行（bpy.ops）两套接口；Add-on Engineer 偏好数据 API 以确保可靠性。
+- [[Asset-Validation]]：资产验证——在资产离开 Blender 前检查命名、变换、材质槽、集合放置等标准的自动化流程，是 Pipeline 可靠性的第一道防线。
+- [[Non-Destructive-Workflow]]：非破坏性工作流——不主动修改源数据，通过验证→报告→确认→执行四步确保用户知情同意，是 Blender Add-on Engineer 的核心设计原则。
+- [[Export-Presets]]：导出预设——可配置的引擎交接规则集（FBX/glTF/USD），确保导出设置在多次运行间保持可重复性。
+- [[Pipeline-Reliability]]：Pipeline 可靠性三角——命名确定性 + 变换分离检查 + 材质槽顺序验证 + 集合包含/排除显式规则，是 Add-on Engineer 交付的核心质量标准。
+- [[AddonPreferences]]：Blender Add-on 持久化设置机制，用于存储跨会话保留的工具配置（如默认导出路径、验证规则开关）。
+- [[PropertyGroups]]：Blender Python 属性组——结构化自定义属性的声明方式，支持 UI 绑定和序列化存储。
+
+## Key Entities
+- [[Blender]]：Blender Foundation 开发的开源 3D DCC 软件，通过 Python bpy API 支持插件扩展；本文档的核心目标平台。
+- [[BlenderAddonEngineer]]：The Agency Game Development 部门 Blender 专项专家 Agent，核心理念"Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded"。
+
+## Connections
+- [[TechnicalArtist]] ← extends ← [[BlenderAddonEngineer]]：技术美术是 Blender Add-on Engineer 的上级角色，后者是 Blender 专项实现。
+- [[GameDesigner]] ← depends_on ← [[BlenderAddonEngineer]]：游戏设计师依赖资产验证和导出管线确保设计资产正确交接。
+- [[UnityArchitect]] ← parallel ← [[BlenderAddonEngineer]]：同为 DCC 工具开发专家，但 Unity Architect 专注 Unity Editor 扩展；两者共享 Editor 工具开发的通用原则（验证优先、持久化配置、非破坏性）。
+- [[UnrealSystemsEngineer]] ← parallel ← [[BlenderAddonEngineer]]：同为工具开发专家，Unreal Systems Engineer 专注 UE5 C++/Blueprint 扩展；两者共享"管道优先、验证先行"理念。
+- [[BlenderAddonEngineer]] ← provides ← [[Asset-Validation]] → feeds → [[GameDesigner]]：验证工具产出报告，供设计师决策修复方案。
+
+## Contradictions
+- 与 [[UnityArchitect]] 在"编辑器工具的数据修改时机"上存在设计哲学差异：
+  - 冲突点：Unity Architect 建议通过 ScriptableObject 实现编辑时-运行时状态分离，倾向于在编辑器扩展中直接修改资产；Blender Add-on Engineer 坚持非破坏性原则，验证后必须用户主动确认才执行修改。
+  - 当前观点：Blender 艺术家工作流强调"保留原始数据"——任何破坏性修改必须在 Dry-run 模式下预演，用户确认后才执行。
+  - 对方观点：Unity Editor 工具倾向于"所见即所得"——编辑器内修改即为正式修改，ScriptableObject 负责持久化状态。
+  - 协调建议：两者均强调"验证先行"——Blender Add-on Engineer 的非破坏性验证 + Unity Architect 的 SO 状态分离，本质上是从不同平台约束出发的等效安全实践。

wiki/sources/engineering-software-architect.md

@@ -0,0 +1,58 @@
+---
+title: "Software Architect Agent Personality"
+type: source
+tags: [agent-personality, software-architecture, system-design, engineering]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/engineering/engineering-software-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：软件架构与系统设计 Agent 的角色定义，专注于设计可维护、可扩展、符合业务领域的系统架构
+- 问题域：架构决策、模式选择、技术权衡、系统演进
+- 方法/机制：领域驱动设计（DDD）、边界上下文（bounded contexts）、架构决策记录（ADR）、C4 模型
+- 结论/价值：为 AI Agent 提供系统思维框架，强调权衡分析优先于最佳实践、领域优先于技术
+
+## Key Claims（用中文描述）
+- 最佳架构是团队能够实际维护的架构：架构不应过度设计，必须匹配团队能力
+- 每个抽象必须有复杂度理由：避免架构宇航员式的过度设计
+- 权衡优先于最佳实践：命名所放弃的，而非仅描述所获得的
+- 领域优先、技术其次：理解业务问题，再选工具
+- 可逆性很重要：优先选择易变更的决策，而非"最优"决策
+- 记录决策，而非仅记录设计：ADR 捕捉 WHY，而非 WHAT
+
+## Key Quotes
+> "Designs systems that survive the team that built them. Every decision has a trade-off — name it." — 核心设计哲学
+
+> "No architecture astronautics — Every abstraction must justify its complexity." — 关键规则 1
+
+> "Domain first, technology second — Understand the business problem before picking tools." — 关键规则 3
+
+> "Reversibility matters — Prefer decisions that are easy to change over ones that are 'optimal'." — 关键规则 4
+
+## Key Concepts
+- [[Bounded Contexts]]：领域驱动设计中划分业务边界的核心概念
+- [[Trade-off Analysis]]：架构决策中命名权衡而非仅列举优点的分析方法
+- [[Architecture Decision Record (ADR)]]：记录架构决策上下文、选项和理由的标准化模板
+- [[Modular Monolith]]：适合小型团队、不清晰边界的架构模式
+- [[Microservices]]：适合清晰领域、需要团队自治的架构模式
+- [[Event-Driven Architecture]]：适合松耦合、异步工作流的架构模式
+- [[CQRS]]：命令查询职责分离，适合读写不对称的系统
+- [[C4 Model]]：用四层图（C4：Context, Container, Component, Code）交流架构的标准化方法
+- [[Quality Attributes]]：可扩展性、可靠性、可维护性、可观测性等非功能需求
+
+## Key Entities
+- （本文档为通用 Agent 角色定义，未涉及特定人物、公司或产品）
+
+## Connections
+- [[BackendArchitectWithMemory]] ← shares_design_philosophy ← [[SoftwareArchitectAgent]]
+- [[WorkflowArchitect]] ← uses_ADR_pattern ← [[SoftwareArchitectAgent]]
+- [[SpecializedWorkflowArchitect]] ← architectural_decision_making ← [[SoftwareArchitectAgent]]
+
+## Contradictions
+- 与 [[UnityArchitect]] 冲突：
+  - 冲突点：架构约束与团队规模的关系
+  - 当前观点（Software Architect）：最佳架构取决于团队能力； microservices 不适合小团队
+  - 对方观点（Unity Architect）：针对特定技术平台（Unity）的架构师角色，可能倾向于选择特定技术栈而非纯权衡驱动
+  - 注：两者领域不同（通用软件架构 vs 游戏引擎架构），冲突仅为框架层面的方法论差异

wiki/sources/godot-gameplay-scripter.md

@@ -0,0 +1,79 @@
+---
+title: "Godot Gameplay Scripter Agent Personality"
+type: source
+tags: ["godot", "gdscript", "game-development", "agent-personality"]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
+
+## Summary（用中文描述）
+- 核心主题：Godot 4 游戏逻辑脚本专家 Agent 人格定义，强调以软件架构师的纪律性构建游戏系统
+- 问题域：如何用 GDScript 2.0 和 C# 构建类型安全、信号驱动、可组合的游戏玩法系统
+- 方法/机制：严格静态类型 + 信号架构 + 组合优于继承 + 正确的 Autoload 使用模式 + GDScript/C# 互操作规范
+- 结论/价值：提供了一套完整的 Godot 4 游戏开发规范，包括命名约定、代码模式、工作流程和性能指标
+
+## Key Claims（用中文描述）
+- GodotGameplayScripter Agent 以软件架构师的纪律性和独立游戏开发者的务实精神构建游戏玩法系统
+- GDScript 信号必须使用 snake_case 且携带类型化参数，C# 信号使用 PascalCase + EventHandler 后缀
+- 所有变量、函数参数和返回值必须显式类型化，禁止在生产代码中使用无类型 var
+- 组合优于继承：通过子节点附加组件（如 HealthComponent）优于创建继承层级
+- Autoload 仅用于真正的跨场景全局状态，不得包含游戏逻辑
+- 场景必须可独立实例化，不得假设父节点类型或兄弟节点存在
+
+## Key Quotes
+> "Everything is a node — behavior is composed by adding nodes, not by multiplying inheritance depth"
+> 核心哲学：一切皆为节点，行为通过添加节点组合，而非增加继承深度
+
+> "Adding the type here catches this bug at parse time instead of 3 hours into playtesting"
+> 类型安全即功能：在解析时捕获 bug，而非在测试 3 小时后发现
+
+> "Don't add this to Player — make a component, attach it, wire the signal"
+> 通信风格：组合优于捷径，永远不要把逻辑直接加到 Player 上，而是创建组件
+
+> "GDScript signals use snake_case; if you're in C#, it's PascalCase with EventHandler"
+> 语言感知：在 GDScript 中信号用 snake_case；在 C# 中用 PascalCase 加 EventHandler 后缀
+
+## Key Concepts
+- [[Signal-Driven Architecture]]：信号驱动架构——通过信号解耦系统，避免直接方法调用，信号必须携带类型化参数
+- [[Static Typing in GDScript 2.0]]：GDScript 2.0 静态类型——所有变量、参数、返回值必须显式类型化，使用 typed arrays
+- [[Composition Over Inheritance]]：组合优于继承——通过附加子节点组件实现行为，而非创建继承层级
+- [[Event Bus Autoload]]：事件总线 Autoload——跨场景解耦通信的全局信号总线，只用于真正跨场景的事件
+- [[Type-Safe Signal Design]]：类型安全信号设计——信号命名遵循语言约定，参数必须类型化，连接时验证方法存在性
+- [[GDScript C# Interoperability]]：GDScript/C# 互操作——跨语言信号连接模式，类型转换和连接命名规范
+
+## Key Entities
+- [[GDScript 2.0]]：Godot 4 默认脚本语言，支持静态类型、装饰器、改进的信号系统
+- [[C# (Godot)]]：Godot 4 支持的 .NET 脚本语言，通过 GodotSharp bindings 与引擎交互
+- [[GDExtension]]：Godot 4 原生扩展机制，允许用 C++ 编写性能关键系统并暴露给 GDScript
+- [[HealthComponent]]：健康组件示例——展示类型化信号声明、@export 属性、伤害/治疗逻辑的标准模式
+- [[EventBus]]：事件总线 Autoload——全局跨场景信号发射器，用于解耦通信
+
+## Connections
+- [[GDScript 2.0]] ← uses ← [[Static Typing in GDScript 2.0]]
+- [[GDScript 2.0]] ← uses ← [[Type-Safe Signal Design]]
+- [[C# (Godot)]] ← uses ← [[Type-Safe Signal Design]]
+- [[EventBus]] ← implements ← [[Signal-Driven Architecture]]
+- [[HealthComponent]] ← demonstrates ← [[Composition Over Inheritance]]
+- [[GDExtension]] ← extends ← [[C# (Godot)]]
+
+## Contradictions
+- 无已知冲突内容
+
+## Technical Deliverables Summary
+
+### 核心代码模式
+- **Typed Signal (GDScript)**：`signal health_changed(new_health: float)` + `died.emit()`
+- **Signal Bus Autoload**：`signal player_died` + `signal score_changed(new_score: int)`
+- **Typed Signal (C#)**：`[Signal] public delegate void HealthChangedEventHandler(float newHealth)`
+- **Composition Pattern**：`@onready var health: HealthComponent = $HealthComponent`
+- **Typed Array**：`var _active_enemies: Array[EnemyBase] = []`
+- **GDScript/C# Interop**：`health_component.HealthChanged.connect(_on_health_changed)`（PascalCase）
+
+### 质量指标
+- 生产代码零无类型 var 声明
+- 所有信号参数显式类型化，无 Variant
+- 零运行时路径查找（所有 get_node 仅在 _ready 中通过 @onready）
+- 组件节点 < 200 行，每个处理一个游戏关注点
+- 所有场景可独立运行（F6 测试通过）

wiki/sources/godot-multiplayer-engineer.md

@@ -0,0 +1,55 @@
+---
+title: "Godot Multiplayer Engineer Agent Personality"
+type: source
+tags: [Godot, Multiplayer, Networking, Game Development, Godot 4, RPC, ENet, WebRTC]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Godot 4 网络多人游戏专家 Agent，基于 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 和 RPC 机制实现实时多人游戏网络同步
+- 问题域：多人游戏权威模型设计、RPC 安全性、场景复制、延迟模拟测试、NAT 穿透与 WebRTC 集成
+- 方法/机制：通过 `set_multiplayer_authority()` 显式设置权威节点，RPC 调用模式（any_peer/authority/call_local）分层控制，MultiplayerSynchronizer 按需同步属性，MultiplayerSpawner 处理动态生成节点的网络复制
+- 结论/价值：提供生产级 Godot 4 多人游戏网络架构，覆盖服务器权威模型、RPC 安全审计、ENet/WebRTC 传输层配置、延迟测试与 matchmaking 集成
+
+## Key Claims（用中文描述）
+- Godot Multiplayer Engineer 通过 `set_multiplayer_authority()` 显式设置权威节点（而非依赖默认值 peer 1），确保每个动态生成节点的状态归属清晰
+- 所有游戏关键状态（位置、生命值、分数、物品状态）必须由服务器（peer 1）持有权威，客户端通过 RPC 发送输入请求，由服务器验证并更新权威状态
+- `@rpc("any_peer")` 允许任何对端调用，必须仅用于客户端→服务器请求，且函数体内必须进行服务器端验证和发送者 ID 检查，否则构成作弊漏洞
+- `MultiplayerSpawner` 是所有动态生成网络节点的唯一正确方式，手动 `add_child()` 会导致对端节点丢失同步
+- 所有 `@rpc("any_peer")` 函数必须进行服务器端验证（发送者 ID + 输入合理性检查），这是防止作弊的关键安全审计点
+
+## Key Quotes
+> "MANDATORY: The server (peer ID 1) owns all gameplay-critical state — position, health, score, item state" — 服务器权威模型强制规范
+> "Never use @rpc("any_peer") for functions that modify gameplay state without server-side validation inside the function body" — RPC 安全红线
+> "MultiplayerSynchronizer property paths must be valid at the time the node enters the tree — invalid paths cause silent failure" — Synchronizer 配置关键约束
+> "Don't add_child() networked nodes manually — use MultiplayerSpawner or peers won't receive them" — 场景复制核心原则
+
+## Key Concepts
+- [[MultiplayerAPI]]：Godot 4 核心网络 API，提供 `set_multiplayer_authority()`、`is_multiplayer_authority()`、RPC 调用和多人信号管理
+- [[Server-Authoritative Model]]：服务器权威模型 — 所有游戏关键状态由服务器持有权威，客户端发送输入请求，服务器验证后更新状态，防止作弊
+- [[RPC（Remote Procedure Call）]]：远程过程调用，通过 `@rpc()` 装饰器声明函数调用模式（any_peer/authority/call_local），实现跨网络的过程调用
+- [[MultiplayerSynchronizer]]：属性同步器 — 广播权威节点属性变更到所有对端，支持 ON_CHANGE 模式避免每帧同步
+- [[MultiplayerSpawner]]：场景生成器 — 在权威节点自动生成子场景并复制到所有对端，是动态生成网络节点的唯一正确方式
+- [[ENet]]：可靠 UDP 传输层，支持服务器/客户端两种模式，用于桌面平台的生产级网络连接
+- [[WebRTC]]：Web 实时通信协议，通过 `WebRTCPeerConnection` + `WebRTCMultiplayerPeer` 实现浏览器端 P2P 多人游戏和 NAT 穿透
+- [[Authority Model]]：权威模型 — 每个网络节点有且只有一个权威持有者（peer ID），只有权威才能修改该节点的关键状态
+- [[RPC Security Pattern]]：RPC 安全模式 — 所有 `any_peer` RPC 函数必须进行发送者 ID 验证和输入合理性检查，防止客户端作弊
+
+## Key Entities
+- [[Godot 4]]：开源游戏引擎，版本 4.x 引入了 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 构成完整的场景复制体系
+- [[Nakama]]：开源游戏服务器，用于 Godot 多人游戏的 matchmaking、大厅、排行榜和 DataStore 集成
+
+## Connections
+- [[godot-gameplay-scripter]] ← extends ← [[godot-multiplayer-engineer]]（多人游戏建立在 Godot 游戏逻辑脚本基础上）
+- [[godot-shader-developer]] ← parallel ← [[godot-multiplayer-engineer]]（同属 Godot Game Dev 部门的不同专精方向）
+- [[unity-multiplayer-engineer]] ← parallel ← [[godot-multiplayer-engineer]]（跨引擎多人游戏实现，核心概念一致但 API 不同）
+
+## Contradictions
+- 与 [[unity-multiplayer-engineer]] 在权威模型实现细节上有差异：
+  - 冲突点：Unity 使用 NetworkTransform/NetworkVariable 隐式同步，Godot 使用 MultiplayerSynchronizer 显式配置
+  - 当前观点：Godot 的显式权威模型（每节点 `set_multiplayer_authority()`）更透明，开发者对状态归属有完全控制
+  - 对方观点：Unity 的隐式同步减少模板代码，但在复杂场景下权威归属不如 Godot 明确
+```

wiki/sources/godot-shader-developer.md

@@ -0,0 +1,50 @@
+---
+title: "Godot Shader Developer Agent Personality"
+type: source
+tags: [Godot, Shader, Game Development, GLSL, Visual Effects]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/godot/godot-shader-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Godot 4 渲染专家 Agent，使用 Godot 着色语言（GLSL-like）编写高性能 2D/3D 视觉效果着色器
+- 问题域：Godot 4 的 CanvasItem（2D）和 Spatial（3D）着色器开发、VisualShader 编辑器、后处理、性能优化
+- 方法/机制：通过 `shader_type` 声明、uniform 参数暴露、渲染器兼容性检查、纹理采样计数审计实现跨平台视觉效果
+- 结论/价值：为 Godot 4 游戏提供创作性正确且性能合规的着色器方案，覆盖 2D 精灵描边、3D 溶解/水面着色、全屏后处理
+
+## Key Claims（用中文描述）
+- Godot Shader Developer 通过 `shader_type` + GLSL-like 语法实现 2D CanvasItem 和 3D Spatial 着色器，在 Forward+ / Mobile / Compatibility 三种渲染器下提供差异化效果
+- VisualShader 编辑器适合艺术家快速迭代，代码着色器适合性能关键路径；两者互补而非替代
+- 所有 uniform 参数必须附带 hint（`hint_range`、`source_color`、`hint_normal` 等），否则 Inspector 无法正确显示
+- `SCREEN_TEXTURE` 采样会触发帧缓冲区复制，在移动端每帧 shader 中使用会严重影响性能
+- `discard` 在移动端不透明空间着色器中应替换为 Alpha Scissor，以保证性能合规
+
+## Key Quotes
+> "MANDATORY: Godot's shading language is not raw GLSL — use Godot built-ins (TEXTURE, UV, COLOR, FRAGCOORD) not GLSL equivalents" — Godot 4 着色语言核心规范
+> "8 texture samples in this fragment is 4 over mobile budget — here's a 4-sample version that looks 90% as good" — 移动端纹理采样性能审计原则
+> "Use VisualShader for effects artists need to extend — use code shaders for performance-critical or complex logic" — 工具选型原则
+
+## Key Concepts
+- [[CanvasItem Shader]]：Godot 2D/UI 着色器类型，使用 `shader_type canvas_item`，通过 `TEXTURE`、`UV`、`COLOR` 内置变量操作精灵和 UI 效果
+- [[Spatial Shader]]：Godot 3D 世界着色器类型，使用 `shader_type spatial`，通过 `ALBEDO`、`METALLIC`、`ROUGHNESS`、`NORMAL_MAP` 输出变量控制 PBR 材质
+- [[VisualShader]]：Godot 图形化着色器编辑器，将 GLSL 节点化，支持艺术家快速搭建材质变体；Group 和 Comment 节点用于组织复杂图
+- [[CompositorEffect]]：Godot 4 Forward+ 渲染器的全屏后处理扩展点，通过 GDScript `extends CompositorEffect` 实现自定义后处理 Pass
+- [[Forward+ Renderer]]：Godot 4 高端渲染器，支持 `DEPTH_TEXTURE`、`SCREEN_TEXTURE`、`NORMAL_ROUGHNESS_TEXTURE` 全部特性
+- [[Mobile Renderer]]：Godot 4 中端渲染器，避免 `discard` 使用，优先 Alpha Scissor；纹理采样预算严格
+- [[Compatibility Renderer]]：Godot 4 最广泛支持渲染器，无 compute shader、无 `DEPTH_TEXTURE` canvas 采样、无 HDR 纹理
+
+## Key Entities
+- [[Godot]]：Juan Linietsky 和 Ariel Manzur 主导的开源游戏引擎，Godot 4 引入了 Forward+ 渲染器和重构的着色语言
+- [[GLSL]]：OpenGL 着色语言，Godot 着色语言基于 GLSL 但有自己的内置变量和 API（`texture()` vs `texture2D()`）
+
+## Connections
+- [[Godot Gameplay Scripter]] ← collaborates_with ← [[Godot Shader Developer]]（Godot 游戏中脚本与着色器协同开发）
+- [[Unity Shader Graph Artist]] ← compares_to ← [[Godot Shader Developer]]（两大主流游戏引擎的着色器方案对比）
+- [[Technical Artist]] ← overlaps_with ← [[Godot Shader Developer]]（两者均涉及渲染技术与美术的桥梁工作）
+- [[Godot Shader Developer]] ← uses ← [[VisualShader]]（VisualShader 作为快速原型工具）
+- [[Godot Shader Developer]] ← targets ← [[Forward+ Renderer]] / [[Mobile Renderer]] / [[Compatibility Renderer]]（三种渲染器适配）
+
+## Contradictions
+- 无已知冲突内容。

wiki/sources/roblox-avatar-creator.md

@@ -0,0 +1,58 @@
+---
+title: "Roblox Avatar Creator Agent Personality"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/roblox-studio/roblox-avatar-creator.md]]
+
+## Summary（用中文描述）
+- 核心主题：Roblox UGC（用户生成内容）化身系统专家 AI Agent 人格规范——从建模绑定到 Creator Marketplace 提交的完整 avatar pipeline
+- 问题域：Roblox avatar 配件系统、Layered Clothing 分层服装、Creator Marketplace 合规审核、化身自定义 API
+- 方法/机制：R15 骨骼权重系统；附件点（Attachment）定位；纹理规范（256-1024px PNG）；三角面数硬限制（配件≤4000、Bundle部件≤10000）；InnerCage/OuterCage 双笼系统
+- 结论/价值：提供可直接使用的 Luau 代码模块（HumanoidDescription、Layered Clothing cage setup、UGC Shop UI flow）和 Creator Marketplace 提交检查清单
+
+## Key Claims（用中文描述）
+- UGC 配件网格必须低于 4,000 三角面——超过此限制将导致自动拒绝（Roblox 强制规则）
+- 所有 UGC 配件必须使用单个 UV 通道，UV 范围严格限制在 [0,1] 空间内——超出该范围将导致贴图采样错误
+- Layered Clothing 配件必须同时包含外层网格和 InnerCage 网格——缺失 InnerCage 将导致服装穿透过角色身体
+- 化身附件必须使用标准命名：HatAttachment、FaceFrontAttachment、LeftShoulderAttachment 等——命名错误导致跨 body type 附件失效
+- Creator Marketplace 商品名称必须准确描述商品——误导性名称将触发审核暂停
+
+## Key Quotes
+> "4,000 triangles is the hard limit — model to 3,800 to leave room for exporter overhead" — Roblox 网格三角面数规范：留 200 面余量防止导出器开销
+> "Looks great in Blender — now test it on Rthro Broad in a run cycle before submitting" — 测试原则：必须覆盖所有 5 种 body type 动画循环
+> "That logo will get flagged — use an original design instead" — 纹理内容规范：禁止任何商标或真实世界品牌
+> "Similar hats sell for 75 Robux — pricing at 150 without a strong brand will slow sales" — Creator Marketplace 定价策略：参考同类商品定价
+
+## Key Concepts
+- [[UGC]]: User Generated Content，Roblox 平台允许创作者发布和销售虚拟物品的经济系统
+- [[LayeredClothing]]: Roblox 分层服装系统，需要 Outer Mesh + InnerCage + OuterCage 三层 cage 网格实现变形
+- [[HumanoidDescription]]: Roblox 化身 API，通过 description.Apply() 方法应用全身装扮，支持 Shirt/Pants/Accessory 等属性
+- [[R15Rig]]: Roblox R15 avatar 骨骼系统，Layered Clothing 权重绑定到标准 R15 骨骼
+- [[CreatorMarketplace]]: Roblox 官方 UGC 交易平台，所有 UGC 商品需通过 Creator Dashboard 提交并通过自动化+人工审核
+- [[AttachmentPoint]]: Roblox 化身附件定位点，名称必须匹配 Roblox 标准（HatAttachment/FaceFrontAttachment 等）
+- [[RthroBodyType]]: Roblox 瘦长型化身比例，与 Classic/R15 Normal 不同——需单独测试附件兼容性
+
+## Key Entities
+- [[Blender]]: 3D 建模软件，用于制作 UGC 配件网格和 cage 网格
+- [[RobloxStudio]]: Roblox 官方开发工具，通过 Avatar → Import Accessory 导入 UGC 物品
+- [[R15TestBodies]]: Roblox Studio 提供的 5 种测试化身预设：Young / Classic / Normal / Rthro Narrow / Rthro Broad
+- [[DataStore]]: Roblox 服务器端持久化系统，用于存储玩家装扮数据
+
+## Connections
+- [[RobloxSystemsScripter]] ← game-dev-scope ← [[RobloxAvatarCreator]]
+- [[RobloxExperienceDesigner]] ← player-economy ← [[RobloxAvatarCreator]]
+- [[Blender]] ← mesh-pipeline ← [[RobloxAvatarCreator]]
+- [[RobloxStudio]] ← asset-pipeline ← [[RobloxAvatarCreator]]
+- [[CreatorMarketplace]] ← submission ← [[RobloxAvatarCreator]]
+- [[R15Rig]] ← bone-weights ← [[RobloxAvatarCreator]]
+
+## Contradictions
+- 与 [[UnityArchitect]] / [[UnityMultiplayerEngineer]] 冲突：
+  - 冲突点：角色自定义系统的实现路径差异
+  - 当前观点（Roblox）：使用 HumanoidDescription API 实现服务端权威的化身自定义，数据通过 DataStore 持久化
+  - 对方观点（Unity）：推荐客户端预测式角色定制，使用 LocalPlayer 状态缓存提升响应体验
+  - 说明：此差异由平台架构约束决定——Roblox 的 LocalScript 不可写 DataStore，Unity 无此限制，均为各自平台最优解

wiki/sources/roblox-experience-designer.md

@@ -0,0 +1,63 @@
+---
+title: "Roblox Experience Designer"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/roblox-studio/roblox-experience-designer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Roblox 平台原生体验设计师 Agent——专注于 Roblox 受众（9-17岁）的参与度循环设计、变现系统与玩家留存
+- 问题域：如何在 Roblox 平台设计可发现、有奖励感、符合平台政策的商业化体验
+- 方法/机制：DataStore 驱动进度系统、Game Pass/Developer Product/UGC 原生化变现、参与度阶梯（首次会话→每日留存→周留存）、每日奖励系统、分析事件追踪
+- 结论/价值：提供完整的 Roblox 原生 UX 和变现设计框架，涵盖技术代码示例（Lua）、入职流程三阶段设计、留存指标体系
+
+## Key Claims（用中文描述）
+- RobloxExperienceDesigner Agent：面向 9-17 岁受众的 Roblox 原生产品设计师，擅长参与度循环设计与合乎伦理的变现
+- 所有付费内容必须遵守 Roblox 政策——禁止 pay-to-win，免费体验必须完整
+- DataStore 存储玩家进度数据必须带重试逻辑，进度丢失是玩家永久流失的首要原因
+- Roblox 算法以同时在线人数、收藏量和访问量为信号——设计应鼓励组队游玩和分享
+- 每日奖励是投入产出比最高的留存功能，应在上线前实现
+- 入职流程第 1 分钟（0-60秒）是留存关键：玩家必须在首分钟内完成核心动作并获得成功体验
+- D1 留存率低于 25% 意味着入职流程未生效，需要审计前 5 分钟
+
+## Key Quotes
+> "Player-advocate, platform-fluent, retention-analytical, monetization-ethical" — RobloxExperienceDesigner 四大核心人格标签
+> "Loss of progression is the #1 reason players quit permanently" — DataStore 安全的首要原则
+> "If D1 is below 25%, the onboarding isn't landing — let's audit the first 5 minutes" — 留存分析与决策框架
+> "That feels like a dark pattern — let's find a version that converts just as well without pressuring kids" — 变现伦理准则
+
+## Key Concepts
+- [[EngagementLoop]]：参与度循环——从首次会话到每日返回再到周留存的完整阶梯设计，每层有清晰奖励闭环
+- [[DailyRewardSystem]]：每日奖励系统——基于连续登录天数的奖励阶梯（1-7天循环），驱动玩家习惯性返回
+- [[DataStoreDrivenProgression]]：DataStore 驱动进度——玩家投入（等级、道具、货币）持久化存储，创造不愿失去的沉没成本
+- [[GamePassMonetization]]：Game Pass 变现——永久性权益/功能通行证，通过 MarketplaceService 验证所有权
+- [[DeveloperProduct]]：开发者产品——可重复购买的消耗品（货币包、道具包），用于软货币变现
+- [[OnboardingFlow]]：入职引导流程——三阶段设计（60秒/5分钟/15分钟），最小化早期流失并通过游戏教学
+- [[RobloxAlgorithm]]：Roblox 推荐算法——以同时在线人数、收藏量、访问量为排名信号
+- [[AnalyticsService]]：分析服务——Roblox 内置 AnalyticsService，用于追踪自定义事件（D1/D7留存、首次购买、会话时长）
+- [[SoftCurrencyFunnel]]：软货币首次购买漏斗——给新玩家足够货币以跨越首次购买心理障碍
+- [[PriceAnchoring]]：价格锚定——在标准选项旁展示高级选项，使标准选项显得实惠
+
+## Key Entities
+- [[RobloxExperienceDesigner]]：Agent 身份——Roblox 原生体验设计师，核心使命是设计让玩家返回、分享和付费的体验
+- [[RobloxPlatform]]：平台——主要受众 9-17 岁，提供 Game Pass/Developer Product/UGC 三大变现工具及推荐算法
+- [[MarketplaceService]]：市场服务——Lua API，用于验证 Game Pass 所有权和触发购买流程
+- [[DataStoreService]]：数据存储服务——Roblox 云端持久化 API，存储玩家进度数据（含每日奖励记录）
+- [[AnalyticsService]]：分析服务——Roblox 内置事件追踪（无第三方依赖），在 Creator Dashboard 可见
+- [[VoiceChatService]]：语音聊天服务——用于社交/RP 类体验的空间语音集成
+
+## Connections
+- [[GameDesigner]] ← extends ← [[RobloxExperienceDesigner]]（Game Designer 的具体平台化实现）
+- [[DailyRewardSystem]] ← depends_on ← [[DataStoreService]]（奖励记录依赖 DataStore 持久化）
+- [[GamePassMonetization]] ← uses ← [[MarketplaceService]]（Game Pass 购买验证）
+- [[OnboardingFlow]] ← feeds → [[AnalyticsService]]（入职完成事件上报）
+- [[RobloxPlatform]] ← rewards → [[EngagementLoop]]（平台算法奖励参与度循环）
+
+## Contradictions
+- 与 [[UnityArchitect]] 冲突：
+  - 冲突点：变现策略
+  - 当前观点：Roblox 受众（9-17岁）必须遵守严格伦理变现——禁止 pay-to-win、人工稀缺、暗黑模式
+  - 对方观点：Unity 平台面向更广泛受众，变现策略更灵活，可接受更强付费优势

wiki/sources/roblox-systems-scripter.md

@@ -0,0 +1,55 @@
+---
+title: "Roblox Systems Scripter Agent Personality"
+type: source
+tags: [roblox, game-development, luau, client-server, datastore, security]
+date: 2026-04-26
+---
+
+## Source File
+- [[raw/Agent/agency-agents/game-development/roblox-studio/roblox-systems-scripter.md]]
+
+## Summary（用中文描述）
+- 核心主题：Roblox 平台工程专家的 Agent 人格定义，专注于 Luau 语言下的服务器权威架构与安全实现
+- 问题域：如何构建可扩展、防作弊、持久化数据安全的 Roblox 游戏体验
+- 方法/机制：服务器权威模型、RemoteEvent/RemoteFunction 安全验证、DataStore 重试与双保存机制、ModuleScript 模块化架构
+- 结论/价值：提供一套完整的 Roblox 系统脚本工程规范，涵盖从基础架构设计到高级并行 Luau 优化的全链路最佳实践
+
+## Key Claims（用中文描述）
+- 服务器是唯一的真相来源：客户端只接收视觉确认，不拥有任何游戏状态
+- 客户端通过 RemoteEvent/RemoteFunction 发送的请求，服务器必须重新验证，不能信任
+- DataStore 操作必须用 `pcall` 包装并实现指数退避重试，防止数据损坏
+- 玩家数据必须在 `PlayerRemoving` 和 `game:BindToClose()` 两处保存，缺一不可
+- 所有游戏系统必须放在 ModuleScript 中，Script/LocalScript 仅做引导，不含核心逻辑
+
+## Key Quotes
+> "Clients request, servers decide. That health change belongs on the server." — 客户端-服务器信任边界原则
+> "That save has no `pcall` — one DataStore hiccup corrupts the player's data permanently" — DataStore 安全核心警示
+> "RemoteFunction:InvokeClient() from the server — a malicious client can yield the server thread forever" — 危险操作警示
+
+## Key Concepts
+- [[Server-Authoritative Architecture]]：服务器权威模型——所有游戏逻辑状态由服务器拥有，客户端只显示状态，不决定状态
+- [[RemoteEvent Security]]：RemoteEvent 安全模式——FireServer 请求需在服务器端完整验证，不能信任客户端数据
+- [[DataStore Reliability]]：DataStore 可靠性模式——pcall 包装 + 指数退避重试 + 双保存点（PlayerRemoving + BindToClose）
+- [[ModuleScript Architecture]]：ModuleScript 架构规范——所有逻辑放入 ModuleScript 返回表，Script/LocalScript 仅 bootstrap
+- [[Parallel Luau]]：并行 Luau——使用 task.desynchronize() 和 Actor 模型实现真正的多线程脚本执行
+- [[Object Pooling]]：对象池模式——预实例化 effects 和 NPC，减少 GC 压力
+- [[UpdateAsync Atomic Pattern]]：UpdateAsync 原子写入——处理并发写入冲突，比 SetAsync 更安全
+
+## Key Entities
+- [[Roblox]]：游戏开发平台，提供 Roblox Studio、Lua 变体 Luau、DataStore 服务
+- [[Luau]]：Roblox 的脚本语言，是 Lua 的类型安全变体
+- [[DataStoreService]]：Roblox 数据持久化服务，用于保存玩家数据到云端
+- [[ReplicatedStorage]]：Roblox 实例容器，RemoteEvent 存放位置，客户端和服务器均可访问
+- [[ServerStorage]]：Roblox 实例容器，仅服务器可访问，用于存放核心模块
+
+## Connections
+- [[Roblox Experience Designer]] ← extends ← [[Roblox Systems Scripter]]
+- [[Server-Authoritative Architecture]] ← foundational ← [[RemoteEvent Security]]
+- [[DataStore Reliability]] ← depends_on ← [[Server-Authoritative Architecture]]
+
+## Contradictions
+- 与 [[Unity Architect]] 冲突：
+  - 冲突点：客户端预测（Client Prediction）策略
+  - 当前观点：Roblox Systems Scripter 建议简化场景下不做本地预测，所有状态由服务器驱动
+  - 对方观点：Unity Multiplayer Engineer 建议使用服务器回滚式 client prediction 提升响应体验
+  - 说明：两者平台不同，Roblox 的 RemoteEvent 架构天然适合服务器权威，Unity 的 Photon/Netcode 支持更灵活的预测策略

wiki/sources/unity-architect.md

@@ -0,0 +1,58 @@
+---
+title: "Unity Architect"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/unity/unity-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：Unity 游戏架构师 AI Agent 人格规范，专注于数据驱动、ScriptableObject（SO）优先的模块化可扩展架构
+- 问题域：如何构建避免"意大利面条式代码"的 Unity 项目，消除硬引用、单例滥用、God MonoBehaviour 等反模式
+- 方法/机制：ScriptableObject 事件通道（GameEvent）、RuntimeSet 无单例实体追踪、单一职责组件拆分、Inspector SO 引用连线、Custom PropertyDrawer 设计师赋能、Addressables 资源管理、Unity DOTS/ECS 混合架构
+- 结论/价值：通过 SO-first 设计，Unity 项目实现零 GameObject.Find()、每个 MonoBehaviour < 150 行、Prefab 场景无关自包含、设计师无需代码即可创建游戏变量/事件/运行时集合
+
+## Key Claims（用中文描述）
+- ScriptableObject-First 设计：所有共享游戏数据必须存于 ScriptableObject，绝不通过 MonoBehaviour 字段跨场景传递
+- GameEvent 事件通道：跨系统通信禁止使用 GetComponent<> 或单例，必须通过 SO 事件通道连线
+- RuntimeSet 无单例追踪：全局实体追踪使用 RuntimeSet : ScriptableObject 而非静态单例
+- 单一职责强制：每个 MonoBehaviour 只解决一个问题，若能用"and"描述则必须拆分
+- 反模式零容忍：God MonoBehaviour（500+ 行）、DontDestroyOnLoad 单例滥用、Update 内轮询逻辑均为禁止项
+- Unity DOTS 混合架构：性能关键系统迁移至 Entities（ECS），编辑器友好型游戏逻辑保留 MonoBehaviour
+
+## Key Quotes
+> "Every MonoBehaviour solves one problem only — if you can describe a component with 'and,' split it." — 单一职责原则核心表述
+> "Treat every scene load as a clean slate — no transient data should survive scene transitions unless explicitly persisted via SO assets." — 场景卫生核心原则
+> "Designer-accessible: Non-technical team members can create new game variables, events, and runtime sets without touching code." — 设计师赋能核心价值
+
+## Key Concepts
+- [[ScriptableObject]]：Unity 资产形式的可序列化对象，用于存储共享数据、事件通道、运行时集合
+- [[RuntimeSet]]：继承 ScriptableObject 的泛型集合类型，用于全局追踪活跃实体而不依赖单例
+- [[GameEvent]]：SO 形式的事件通道（GameEvent : ScriptableObject），用于跨系统解耦通信
+- [[SingleResponsibilityPrinciple]]：每个 MonoBehaviour 只负责单一职责，超过 150 行即违反
+- [[EventDrivenArchitecture]]：事件驱动替代 Update() 内轮询，消除 GC 分配
+- [[DataDrivenDesign]]：数据驱动的模块化 Unity 架构设计理念
+- [[ScriptableObjectEventChannel]]：ScriptableObject 形式的 GameEvent 系统，通过 Raise/Register 模式实现松耦合
+- [[Addressables]]：Unity 资源管理系统，替代 Resources.Load()，支持细粒度内存控制和 DLC
+- [[UnityDOTS]]：Data-Oriented Tech Stack，ECS + Job System + Burst Compiler，用于性能关键路径
+- [[EditorUtilitySetDirty]]：编辑器脚本修改 SO 数据后必须调用以确保序列化持久化
+
+## Key Entities
+- [[UnityArchitect]]：本文档定义的 AI Agent 人格，数据驱动模块化架构专家，精通 ScriptableObject、职责拆分、单例消除
+- [[UnityEditor]]：Unity 编辑器环境，ScriptableObject 通过 [CreateAssetMenu] 对设计师可见
+- [[UnityDOTS]]：Unity Data-Oriented Tech Stack（Entities、Jobs、Burst），用于 CPU 密集型批量操作
+
+## Connections
+- [[UnityArchitect]] ← builds_with ← [[ScriptableObject]]
+- [[UnityArchitect]] ← extends ← [[UnityMultiplayerEngineer]]（网络层叠加 SO 架构）
+- [[UnityArchitect]] ← complements ← [[UnityShaderGraphArtist]]（SO 数据驱动视觉资产）
+- [[UnityArchitect]] ← complements ← [[UnityEditorToolDeveloper]]（Custom PropertyDrawer 赋能 SO 设计师体验）
+- [[UnityArchitect]] ← builds_with ← [[UnityDOTS]]（性能关键路径使用 ECS 混合架构）
+
+## Contradictions
+- 与 [[UnityMultiplayerEngineer]] 在客户端预测实现上存在框架差异：
+  - UnityArchitect 侧：NetworkVariable 通过 SO 引用在 MonoBehaviour 间传递状态
+  - UnityMultiplayerEngineer 侧：NetworkVariable 直接挂载在 NetworkBehaviour 上
+  - 两者均遵循服务器权威原则，差异在于 SO 层抽象程度，属架构风格差异而非绝对冲突

wiki/sources/unity-editor-tool-developer.md

@@ -0,0 +1,49 @@
+---
+title: "Unity Editor Tool Developer"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/unity/unity-editor-tool-developer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Unity 编辑器扩展开发工程师（Editor Tool Developer）的 AI Agent 人格规范——通过 EditorWindows、PropertyDrawers、AssetPostprocessors、Build Validators 等工具自动化团队工作流，减少人工错误
+- 问题域：游戏团队每日面临的素材导入错误、Inspector 数据误操作、命名规范失控、构建前人工检查等重复性工作
+- 方法/机制：基于 Unity Editor API 构建编辑器扩展工具，使用 `[SerializeField]` + `[MenuItem]` + `AssetPostprocessor` 模式实现自动化；通过 `Undo.RecordObject()` 保证操作可撤销；通过 `EditorUtility.DisplayProgressBar` 反馈长操作进度
+- 结论/价值：最佳工具是"隐形"的——在问题到达 QA 前自动拦截，在创意人员意识到需求前提前自动化
+
+## Key Claims（用中文描述）
+- UnityEditorToolDeveloper 通过 Editor 自动化，使艺术/设计/工程团队效率可量化提升
+- 所有 Editor 脚本必须置于 `Editor` 文件夹或使用 `#if UNITY_EDITOR` 保护——Editor API 调用进入运行时代码将导致构建失败
+- `EditorWindow` 必须通过 `[SerializeField]` 或 `EditorPrefs` 持久化状态，跨域重载不丢失
+- `AssetPostprocessor` 必须幂等——同一资源重复导入必须产生相同结果
+- `PropertyDrawer.OnGUI` 必须调用 `EditorGUI.BeginProperty` / `EndProperty` 以正确支持 Prefab Override UI
+- 构建验证器失败时必须抛出 `BuildFailedException`，而非仅 `Debug.LogWarning`
+
+## Key Quotes
+> "The best tools are invisible — they catch problems before they ship and automate the tedious so humans can focus on the creative." — UnityEditorToolDeveloper 核心理念
+
+> "Can you Ctrl+Z that? No? Then we're not done." — Undo 是交付门槛，不支持撤销的工具不能发布
+
+> "DX over raw power: The tool can do 10 things — let's ship the 2 things artists will actually use." — 开发者体验优先于功能堆砌
+
+## Key Concepts
+- [[EditorWindow]]：Unity 编辑器窗口扩展基类，用于构建团队可见的编辑器工具（资产审计、资源统计、验证面板）
+- [[AssetPostprocessor]]：Unity 资源导入拦截器，在资源导入时自动强制执行命名规范、压缩设置、平台配置，确保每次导入结果一致且幂等
+- [[PropertyDrawer]]：自定义 Inspector 属性绘制器，扩展编辑器中序列化类型的显示方式，支持 MinMax Slider 等复合控件
+- [[AssemblyDefinitionFiles]]：`.asmdef` 文件用于在编译时强制 Editor/Runtime 程序集分离，防止 UnityEditor 命名空间泄漏到构建产物
+- [[BuildValidation]]：`IPreprocessBuildWithReport` 接口允许在构建前运行检查列表，失败时抛出 `BuildFailedException` 阻止打包
+
+## Key Entities
+- [[UnityEditorToolDeveloper]]：本 Source 对应的 AI Agent 人格——编辑器自动化专精，强调 DX、可量化的效率提升和隐形工具哲学
+- [[UnrealEditorToolDeveloper]]：对应 Unreal Engine 端的编辑器工具开发（比较视角）
+
+## Connections
+- [[unity-editor-tool-developer]] ← game_dev_editor_extension ← [[game-designer]]
+- [[unity-editor-tool-developer]] ← editor_automation ← [[unreal-systems-engineer]]（两者共享"构建前验证"模式）
+- [[unity-editor-tool-developer]] ← tool_patterns ← [[technical-artist]]（Technical Artist 也负责编辑器工具和资产管线）
+
+## Contradictions
+- 与 [[unreal-systems-engineer]] 在"编辑器工具 vs. 构建系统"边界上存在领域分工差异：Unity 侧通过 `IPreprocessBuildWithReport` 在构建前验证资源合规性；Unreal 侧通过 UAssetCheckConfig + UAssetCheckRule 在编辑器内实时检查。两者的目标相同（防止问题到达 QA），但实现时机和 API 不同——属互补而非冲突。

wiki/sources/unity-multiplayer-engineer.md

@@ -0,0 +1,64 @@
+---
+title: "Unity Multiplayer Engineer"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/unity/unity-multiplayer-engineer]]
+
+## Summary（用中文描述）
+- 核心主题：Unity 多人游戏网络编程专家 Agent人格定义，涵盖 Netcode for GameObjects（NGO）、Unity Gaming Services（Relay/Lobby）集成、服务器权威模型、延迟补偿和状态同步等技术规范。
+- 问题域：如何为 Unity 游戏构建安全、抗作弊、延迟容忍的多人联网系统。
+- 方法/机制：服务器权威架构 + 客户端预测与调和 + RPC/NetworkVariable 分层设计 + UGS Relay/Lobby 匹配服务。
+- 结论/价值：提供完整的 Unity 多人游戏开发技术规范，包括网络代码模板、带宽管理策略、反作弊架构和高级性能优化方案。
+
+## Key Claims（用中文描述）
+- 服务器必须拥有所有游戏状态的权威真相——位置、生命值、分数、物品所有权，客户端仅发送输入。
+- NetworkVariable 用于持久化复制的状态，RPC 用于一次性事件，二者不可混用。
+- 客户端预测移动必须与服务器状态进行调和，当偏差超过阈值时强制回正。
+- Unity Relay 应用于所有玩家托管游戏，禁止直接 P2P 连接以保护主机 IP 安全。
+- 带宽管理：非关键状态更新（如血条、分数）应限流至最高 10Hz，避免每帧同步。
+
+## Key Quotes
+> "The client doesn't own this — the server does. The client sends a request." — 服务器权威原则
+
+> "That NetworkVariable fires every frame — it needs a dirty check or it's 60 updates/sec per client" — 带宽控制原则
+
+> "Design for 200ms — not LAN. What does this mechanic feel like with real latency?" — 延迟设计原则
+
+> "If it persists, it's a NetworkVariable. If it's a one-time event, it's an RPC. Never mix them." — RPC vs Variable 原则
+
+## Key Concepts
+- [[ServerAuthority]]：服务器权威模型——服务器拥有所有游戏状态的最终真相，客户端仅发送输入请求。
+- [[ClientPrediction]]：客户端预测——客户端立即执行输入预测移动，再与服务器权威状态调和校正。
+- [[NetworkVariable]]: NGO 中用于持久化复制状态的类型，仅在值变化时触发网络同步。
+- [[ServerRpc]]: 客户端调用、服务器执行的 RPC，用于提交输入请求，服务器端必须验证所有输入。
+- [[ClientRpc]]: 服务器调用、所有客户端执行的 RPC，用于广播确认的游戏事件（如命中确认、技能激活）。
+- [[UnityRelay]]: Unity Gaming Services 的中继服务，解决 NAT 穿透问题，保护主机 IP 不暴露。
+- [[UnityLobby]]: Unity Gaming Services 的匹配大厅服务，仅存储元数据（玩家名、地图选择），不存储游戏状态。
+- [[LagCompensation]]: 延迟补偿机制——服务器在处理客户端输入时考虑网络延迟影响。
+- [[BandwidthManagement]]: 带宽管理——通过 dirty check、差分序列化、限流等策略控制网络流量。
+- [[AntiCheatArchitecture]]: 反作弊架构——所有游戏关键值必须经过服务器验证，客户端不可信。
+
+## Key Entities
+- [[UnityMultiplayerEngineer]]：本 Agent 角色定义——构建确定性、抗作弊、延迟容忍的 Unity 多人游戏系统的专家。
+- [[NetcodeForGameObjects]]：Unity 官方网络代码框架，提供 NetworkObject、NetworkVariable、ServerRpc、ClientRpc 等核心网络原语。
+- [[UnityGamingServices]]: Unity 云服务集合，包含 Relay（流量中继）和 Lobby（匹配大厅）两个多人游戏核心服务。
+- [[UnityTransport]]: Unity Netcode 的传输层，支持直连和 Relay 两种连接方式。
+
+## Connections
+- [[UnityMultiplayerEngineer]] ← extends ← [[NetcodeForGameObjects]]
+- [[UnityMultiplayerEngineer]] ← depends_on ← [[UnityGamingServices]]
+- [[ServerAuthority]] ← implements ← [[ClientPrediction]]
+- [[ClientPrediction]] ← reconciles_with ← [[ServerAuthority]]
+- [[UnityRelay]] ← enables ← [[ServerAuthority]]
+- [[UnityLobby]] ← provides ← [[AntiCheatArchitecture]]
+
+## Contradictions
+- 与 [[UnrealMultiplayerArchitect]] 潜在差异：
+  - 冲突点：客户端预测实现细节。
+  - 当前观点（Unity）：使用 NetworkVariable + 自定义调和逻辑，在 LateUpdate 中检测并纠正客户端与服务端位置偏差。
+  - 对方观点（Unreal）：使用更细粒度的帧缓冲和回滚机制。
+  - 说明：两者均遵循服务器权威原则，差异源于底层网络框架设计哲学不同，两者可互补学习。

wiki/sources/unity-shader-graph-artist.md

@@ -0,0 +1,59 @@
+---
+title: "Unity Shader Graph Artist"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[raw/Agent/agency-agents/game-development/unity/unity-shader-graph-artist.md]]
+
+## Summary（用中文描述）
+- 核心主题：Unity Shader Graph Artist Agent 角色定义 —— 一个精通 Unity 渲染管线的专业 AI Agent，专注于 Shader Graph 可视化材质创作与 HLSL 性能优化
+- 问题域：游戏/实时渲染视觉效果开发、跨 URP/HDRP 管线的 Shader 创作规范与性能约束
+- 方法/机制：通过 Sub-Graph 模块化架构、Renderer Feature 自定义渲染通道、Shader Complexity Audit 复杂度审核流程，确保视觉效果与性能的平衡
+- 结论/价值：提供了一套完整的 Unity 渲染 Agent 工作体系，覆盖从设计简报到 Shader 交付、艺术家交接的全链路规范
+
+## Key Claims（用中文描述）
+- 所有 Shader Graph 必须使用 Sub-Graph 封装重复逻辑 —— 重复的节点簇是维护和一致性失败
+- URP 自定义通道必须使用 `ScriptableRendererFeature` + `ScriptableRenderPass` —— 禁止使用 `OnRenderImage`（仅限内置管线）
+- HDRP 自定义通道使用 `CustomPassVolume` + `CustomPass` —— API 与 URP 不同，不可互换
+- 透明材质优先使用 Alpha Clipping 而非 Alpha Blend —— Alpha clipping 无过度绘制深度排序问题
+- 所有 Fragment Shader 必须在 Unity Frame Debugger 和 GPU Profiler 中完成性能分析后方可发布
+
+## Key Quotes
+> "Every Shader Graph must use Sub-Graphs for repeated logic — duplicated node clusters are a maintenance and consistency failure" — Shader Graph 架构强制规范
+
+> "URP custom passes use `ScriptableRendererFeature` + `ScriptableRenderPass` — never `OnRenderImage` (built-in only)" — URP/HDRP 管线 API 差异说明
+
+> "Mobile: max 32 texture samples per fragment pass; max 60 ALU per opaque fragment" — 移动端性能硬约束
+
+## Key Concepts
+- [[Shader Graph]]：Unity 可视化 Shader 编辑器，允许艺术家通过节点图创建材质，无需手写 HLSL
+- [[Sub-Graph]]：Shader Graph 中的可复用子图模块，用于封装重复逻辑节点簇
+- [[URP (Universal Render Pipeline)]]：Unity 通用渲染管线，轻量级，跨平台支持
+- [[HDRP (High Definition Render Pipeline)]]：Unity 高清渲染管线，面向高端主机/PC 的 PBR 渲染
+- [[ScriptableRendererFeature]]：URP 自定义渲染通道系统，允许注入自定义全屏效果
+- [[HLSL]]：High-Level Shader Language，Shader Graph 编译的目标代码，可手写以实现极致性能
+- [[Alpha Clipping]]：透明裁剪渲染模式，通过像素丢弃实现透明效果，避免深度排序问题
+- [[Frame Debugger]]：Unity 内置帧调试工具，逐 draw call 分析渲染管线
+- [[RenderDoc]]：第三方 GPU 帧捕获工具，用于 Shader 调试和寄存器值检查
+
+## Key Entities
+- [[Unity Technologies]]：Unity Engine 开发商，提供 Shader Graph、URP、HDRP 等渲染系统
+- [[DissolveCore]]：Sub-Graph 封装示例，包含溶解效果的节点逻辑，可复用于多个角色材质
+- [[OutlineRendererFeature]]：自定义 URP Renderer Feature，实现描边效果的 C# 类
+- [[CustomLit.hlsl]]：URP 兼容的 PBR 自定义 Shader 示例，展示完整的 HLSL 编写规范
+
+## Connections
+- [[UnityShaderGraphArtist]] ← authored_by ← [[TechnicalArtist]]（Technical Artist 可能指导或审查 Shader Graph Artist 的输出）
+- [[Shader Graph]] ← requires ← [[URP / HDRP]]（Shader Graph 必须在正确的渲染管线下创作）
+- [[Sub-Graph]] ← enables ← [[Shader Graph]]（Sub-Graph 是 Shader Graph 模块化的基础）
+- [[ScriptableRendererFeature]] ← part_of ← [[URP]]（自定义渲染通道是 URP 的扩展机制）
+
+## Contradictions
+- 与 [[UnrealTechnicalArtist]] 关于渲染管线选择：
+  - 冲突点：Unreal 使用 Material Editor + Custom Node（HLSL）方案，Unity 使用 Shader Graph + Sub-Graph 方案
+  - 当前观点：Unity Shader Graph Artist 认为 Shader Graph 应为艺术家首选，HLSL 仅用于性能关键路径
+  - 对方观点：Unreal Technical Artist 认为 HLSL 编码在所有情况下都是首选方案
+  - 说明：两者均为各自平台的最佳实践，冲突源于平台差异而非绝对优劣

wiki/sources/unreal-multiplayer-architect.md

@@ -0,0 +1,57 @@
+---
+title: "Unreal Multiplayer Architect"
+type: source
+tags: [game-development, unreal-engine, networking, multiplayer, ue5]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/unreal-engine/unreal-multiplayer-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：UE5多人游戏网络架构专家角色定义——构建服务器权威模型、延迟容忍、作弊防护的多人游戏系统
+- 问题域：Actor复制、网络预测、RPC安全验证、带宽优化、GAS复制、专用服务器构建
+- 方法/机制：Server-authoritative架构、UFUNCTION(Server, Reliable, WithValidation)、GetLifetimeReplicatedProps、Replication Graph、双路径GAS初始化
+- 结论/价值：提供生产级UE5多人游戏网络系统的完整技术方案，涵盖从基础复制到高级预测框架的全栈实现
+
+## Key Claims（用中文描述）
+- 服务器必须拥有所有游戏状态变化的执行权威，客户端仅发送RPC请求，由服务器验证后复制
+- 所有游戏逻辑相关的Server RPC必须实现WithValidation，不得省略_Validate()实现
+- 网络复制频率应按Actor类型差异化配置，默认100Hz过高，大多数Actor仅需20-30Hz
+- GAS的AbilitySystemComponent初始化必须在PossessedBy（服务器路径）和OnRep_PlayerState（客户端路径）两个入口点分别执行
+- 专用服务器构建必须使用Linux平台+Shipping配置+Cooked内容
+
+## Key Quotes
+> "The server owns truth. The client requests it — the server decides." — 权威模型的核心原则
+> "WithValidation tag is not optional for any game-affecting RPC" — 安全验证的强制性要求
+> "Bandwidth per player < 15KB/s at maximum player count" — 性能基准指标
+> "Every Server RPC needs a `_Validate`. No exceptions. One missing is a cheat vector." — 作弊防护的非妥协立场
+
+## Key Concepts
+- [[ServerAuthoritativeModel]]：服务器权威模型——服务器模拟真实状态，客户端预测并对账，所有游戏逻辑在服务器执行
+- [[ActorReplication]]：Actor复制——UPROPERTY(Replicated)将状态从服务器同步到客户端，支持ReplicatedUsing触发RepNotify
+- [[RPC]]：远程过程调用——Client/Server/NetMulticast三种RPC类型，Server RPC必须带验证
+- [[NetworkPrediction]]：网络预测——客户端本地预测操作，服务器确认后校正，减少感知延迟
+- [[ReplicationGraph]]：复制图——空间分区优化，仅向相关客户端复制区域内的Actor，降低带宽
+- [[GAS]]：Gameplay Ability System——UE5技能系统，支持复制和预测的技能与属性管理
+- [[DedicatedServer]]：专用服务器——无图形界面的纯服务器实例，处理所有游戏逻辑
+- [[NetworkRelevancy]]：网络相关性——根据客户端视角决定哪些Actor需要复制，节省带宽
+- [[NetMulticast]]：多播RPC——服务器向所有客户端广播事件，用于仅表现层效果
+
+## Key Entities
+- [[GameMode]]：服务器独有（永不复制）——生成逻辑、规则仲裁、胜负条件判定
+- [[GameState]]：复制到所有客户端——共享世界状态（回合计时器、队伍分数等）
+- [[PlayerState]]：复制到所有客户端——每玩家公开数据（名称、延迟、击杀数）
+- [[PlayerController]]：仅复制到拥有客户端——输入处理、摄像机、HUD控制
+- [[AbilitySystemComponent]]：GAS核心组件——管理技能和属性，必须正确配置复制
+- [[ReplicationGraph]]：UE5复制图插件——用空间分区替代默认扁平相关性模型
+
+## Connections
+- [[GameMode]] ← spawns + governs ← [[GameState]]
+- [[PlayerController]] ← possesses ← [[PlayerState]]
+- [[GameplayAbilitySystem]] ← depends_on ← [[ActorReplication]]
+- [[NetworkPrediction]] ← extends ← [[ActorReplication]]
+- [[DedicatedServer]] ← hosts ← [[GameMode]]
+
+## Contradictions
+- 与现有Wiki内容暂无冲突——本页面为独立技术领域（UE5网络架构）

wiki/sources/unreal-systems-engineer.md

@@ -0,0 +1,54 @@
+---
+title: "Unreal Systems Engineer"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/unreal-engine/unreal-systems-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：Unreal Engine 5 系统架构师 AI Agent 人格规范——C++/Blueprint 边界决策、性能优化、网络就绪游戏系统构建
+- 问题域：AAA 级 UE5 游戏项目中的技术架构决策、性能瓶颈规避、网络复制可靠性保障
+- 方法/机制：C++/Blueprint 分层架构（Tick 逻辑必须 C++）、GAS 网络复制配置、Nanite 实例预算管理、智能指针内存安全、Unreal Build System 反射宏规范
+- 结论/价值：建立了一套完整的 UE5 系统工程师能力标准，涵盖从内存管理到高级渲染的 AAA 级开发规范
+
+## Key Claims（用中文描述）
+- Tick 逻辑必须实现于 C++——Blueprint VM 开销与缓存未命中在每帧调用频率下构成性能风险
+- Nanite 单场景硬上限 1600 万实例——开放世界项目需提前规划实例预算
+- 所有 UObject 派生指针必须声明 UPROPERTY()——缺失将导致垃圾回收意外销毁
+- GAS 网络复制必须通过 UAbilitySystemComponent——禁止手动复制技能状态
+- FGameplayTag 优于字符串——标签支持层级结构、复制安全、全局搜索
+
+## Key Quotes
+> "Any logic that runs every frame (`Tick`) must be implemented in C++ — Blueprint VM overhead and cache misses make per-frame Blueprint logic a performance liability at scale." — UnrealSystemsEngineer 核心原则
+
+> "Nanite supports a hard-locked maximum of 16 million instances in a single scene — plan large open-world instance budgets accordingly." — Nanite 实例预算警告
+
+> "All `UObject`-derived pointers must be declared with `UPROPERTY()` — raw `UObject*` without `UPROPERTY` will be garbage collected unexpectedly." — 内存安全核心规范
+
+## Key Concepts
+- [[GAS-Gameplay-Ability-System]]：UE5 技能与属性管理框架，通过 UGameplayAbility/UAttributeSet/UAbilitySystemComponent 实现网络就绪的技能系统
+- [[Nanite]]：UE5 虚拟几何体系统，支持自动 LOD 和海量实例化渲染，单场景上限 1600 万实例
+- [[LumenGI]]：UE5 全局光照系统（源文档关联提及，未独立建页）
+- [[Chaos-Physics]]：UE5 物理与破坏系统框架（源文档 Advanced Capabilities 提及，建议后续独立建页）
+- [[Mass-Entity]]：Unreal ECS 实现，通过 UMassEntitySubsystem 处理海量 NPC/投射物/人群代理
+- [[Lyra-Gameplay-Framework]]：Epic 的模块化游戏框架模式，GameFeatureAction 运行时组件注入
+
+## Key Entities
+- [[UnrealEngine5]]：Epic Games 开发的游戏引擎，提供 C++/Blueprint 双轨开发、Gas、Nanite、Lumen 等全栈工具链
+- [[UnrealMultiplayerArchitect]]：多人网络架构师 Agent，与本 Agent 在网络就绪系统设计上存在协作关系（GAS 配置中涉及网络复制）
+- [[UnrealTechnicalArtist]]：视觉系统工程师 Agent，与本 Agent 在 Nanite 几何优化上存在协作关系（Technical Artist 负责 Nanite 资产验证）
+
+## Connections
+- [[UnrealMultiplayerArchitect]] ← shares_gas_architecture_with ← [[UnrealSystemsEngineer]]
+- [[UnrealTechnicalArtist]] ← shares_nanite_optimization_with ← [[UnrealSystemsEngineer]]
+- [[UnrealEngine5]] ← provides_engine_capabilities_to ← [[UnrealSystemsEngineer]]
+
+## Contradictions
+- 与 [[UnrealMultiplayerArchitect]] 在 GAS 职责边界：
+  - 冲突点：GAS 配置中技能系统实现与网络复制配置的职责归属
+  - 当前观点（本 Agent）：系统架构师负责 UGameplayAbility/UAttributeSet C++ 实现和网络复制配置
+  - 对方观点：网络架构师负责 RPC 通信层面和 Server Authoritative 状态同步
+  - 解决方向：两者互补——系统工程师构建 GAS 内部逻辑，网络架构师确保 RPC 层安全调用 GAS

wiki/sources/unreal-technical-artist.md

@@ -0,0 +1,58 @@
+---
+title: "Unreal Technical Artist"
+type: source
+tags: ["game-development", "unreal-engine", "technical-art", "vfx", "procedural-generation"]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/agency-agents/game-development/unreal-engine/unreal-technical-artist.md]]
+
+## Summary（用中文描述）
+- 核心主题：Unreal Engine 5 视觉系统工程师的 AI Agent 人格定义，专注于 UE5 的材质编辑器、Niagara VFX、PCG 程序化内容生成和美术-引擎管线
+- 问题域：如何在 AAA 级项目中，在硬件预算内交付高质量的视觉效果；如何建立可复用、可扩展的视觉工具链
+- 方法/机制：
+  - Material Editor 规范：Material Functions 复用原则、Material Instances 变体机制、Quality Switch 质量分层
+  - Niagara VFX 规范：GPU/CPU 模拟选择、粒子数量限制、Scalability 分级预设
+  - PCG 规范：确定性图生成、地形采样、密度过滤、Nanite 优化
+  - LOD 与剔除：Nanite 策略、Cull Distance Volumes、HLOD 配置
+- 结论/价值：定义了完整的 UE5 视觉技术交付标准，覆盖从材质到 VFX 到程序化场景的全管线
+
+## Key Claims（用中文描述）
+- 可复用逻辑必须封装为 Material Functions，绝不在多个 Master Material 间重复节点簇
+- 所有粒子系统必须设置 `Max Particle Count`，禁止无限粒子
+- PCG 图是确定性的：相同输入参数始终产生相同输出
+- 所有 PCG 放置的资产在符合条件时必须启用 Nanite
+- Substrate（UE5.3+）可实现多层物理材质叠加，替换传统 SSS workaround
+
+## Key Quotes
+> "Reusable logic goes into Material Functions — never duplicate node clusters across multiple master materials" — Material Editor 核心原则
+> "CPU simulation for < 1000 particles; GPU simulation for > 1000" — Niagara GPU/CPU 选择标准
+> "PCG graphs are deterministic: same input graph and parameters always produce the same output" — PCG 确定性保证
+> "All Nanite-ineligible meshes require manual LOD chains with verified transition distances" — LOD 验收标准
+> "Every Static Switch doubles shader permutation count — audit before adding" — 材质复杂度控制
+
+## Key Concepts
+- [[MaterialFunction]]：UE5 材质系统中可复用的节点逻辑封装单元，用于消除跨材质重复逻辑
+- [[NiagaraVFX]]：UE5 新一代粒子和 VFX 系统，支持 GPU/CPU 模拟分离与 Scalability 分级
+- [[PCG]]：Procedural Content Generation，UE5 程序化内容生成框架，通过图节点控制开放世界资产分布
+- [[Nanite]]：UE5 虚拟几何体系统，支持自动 LOD 和海量实例化渲染
+- [[Substrate]]：UE5.3+ 多层材质系统，支持物理正确的层叠材质（湿涂层/泥土/岩石），替代传统 SSS workaround
+- [[LOD]]：Level of Detail，根据距离切换网格精度，是开放世界性能优化的基础机制
+- [[QualitySwitch]]：UE5 材质节点，支持在单一材质图中定义移动/主机/PC 三档质量层级
+
+## Key Entities
+- [[UnrealEngine5]]：Epic Games 开发的游戏引擎，提供 Material Editor、Niagara、PCG、Nanite 等视觉工具链
+- [[UnrealInsights]]：UE5 性能分析工具，用于识别渲染性能瓶颈
+- [[WorldPartition]]：UE5 开放世界管理系统，与 HLOD 和 PCG 流式加载协同工作
+
+## Connections
+- [[MaterialFunction]] ← 核心依赖 ← [[UnrealTechnicalArtist]]
+- [[NiagaraVFX]] ← 核心依赖 ← [[UnrealTechnicalArtist]]
+- [[PCG]] ← 核心依赖 ← [[UnrealTechnicalArtist]]
+- [[UnrealEngine5]] ← 基于 ← [[UnrealTechnicalArtist]]
+- [[UnrealWorldBuilder]] ← 协同 ← [[UnrealTechnicalArtist]]
+- [[UnrealSystemsEngineer]] ← 协同 ← [[UnrealTechnicalArtist]]（技术艺术家负责视觉，系统工程师负责底层）
+
+## Contradictions
+- 暂无冲突内容

wiki/sources/unreal-world-builder.md

@@ -0,0 +1,50 @@
+---
+title: "Unreal World Builder Agent Personality"
+type: source
+tags: ["unreal-engine", "open-world", "ue5", "world-partition", "game-development"]
+date: 2026-04-26
+---
+
+## Source File
+- [[raw/Agent/agency-agents/game-development/unreal-engine/unreal-world-builder.md]]
+
+## Summary（用中文描述）
+- 核心主题：Unreal Engine 5 开放世界环境构建 Agent 的角色定义与工作规范
+- 问题域：大型开放世界游戏（4km² ~ 64km²）的环境流送、渲染优化、内容生成等技术挑战
+- 方法/机制：World Partition 分区流送、Landscape 地形系统、PCG 程序化内容生成、HLOD 层级 LOD、Nanite 虚拟几何体、RVT 运行时虚拟纹理
+- 结论/价值：提供了一套完整的 UE5 开放世界技术交付标准，覆盖从网格规划到性能验证的全流程
+
+## Key Claims（用中文描述）
+- World Partition 格子大小必须由目标流送预算决定：密集城区用 64m、空旷地形用 128m、沙漠/海洋用 256m+
+- Landscape 材质超过 2 层时必须启用 Runtime Virtual Texturing（RVT），否则产生每像素层混合成本爆炸
+- HLOD 必须为所有 500m 以外可见区域生成，未构建 HLOD 会导致远距离 Actor 数量激增
+- PCG 大规模植被必须使用预烘焙输出，运行时 PCG 仅限 1km² 以下小区域
+- 大世界坐标（LWC）必须在任何轴超过 2km 的世界启用，否则约 20km 后出现浮点精度错误
+
+## Key Quotes
+> "Cell size must be determined by target streaming budget — smaller cells = more granular streaming but more overhead" — World Partition 配置核心原则
+> "HLOD must be built for all areas visible at > 500m camera distance — unbuilt HLOD causes actor-count explosion at distance" — HLOD 必建规则
+> "Foliage Tool (legacy) is for hand-placed art hero placement only — large-scale population uses PCG" — PCG 替代 Foliage Tool 的使用场景
+> "Enable Large World Coordinates for worlds > 2km in any axis — floating point precision errors become visible at ~20km without LWC" — LWC 启用阈值
+
+## Key Concepts
+- [[WorldPartition]]: UE5 的开放世界分区管理系统，将世界划分为格子，支持按需流送
+- [[Landscape]]: UE5 地形系统，支持多层混合烘焙和运行时虚拟纹理
+- [[PCG]]: Procedural Content Generation，程序化内容生成，用于大规模植被和环境资产放置
+- [[HLOD]]: Hierarchical Level of Detail，层级 LOD，通过网格合并减少远距离 Draw Call
+- [[Nanite]]: UE5 虚拟化几何体系统，处理大规模几何细节，支持数百万实例
+- [[RuntimeVirtualTexturing]]: RVT，运行时虚拟纹理，消除地形层混合的像素级计算开销
+- [[LargeWorldCoordinates]]: LWC，双精度坐标系统，解决超大世界浮点精度问题
+
+## Key Entities
+- [[UnrealEngine5]]: 开发平台，UE5 提供 World Partition、Nanite、LWC 等开放世界基础设施
+- [[EpicGames]]: Unreal Engine 发行商，World Partition 和 Nanite 均为 Epic 内部开发的技术
+
+## Connections
+- [[UnrealSystemsEngineer]] ← skill_overlap ← [[UnrealWorldBuilder]]（共享 World Partition 流送基础设施）
+- [[UnrealTechnicalArtist]] ← extends ← [[UnrealWorldBuilder]]（共享 Landscape 材质与 RVT 技术）
+- [[UnrealWorldBuilder]] ← depends_on ← [[Nanite]]（PCG 植被依赖 Nanite 优化实例渲染）
+- [[UnrealWorldBuilder]] ← depends_on ← [[HLOD]]（开放世界远距离渲染优化依赖 HLOD 系统）
+
+## Contradictions
+- 未发现与现有 Wiki 内容的冲突。