<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Unity on Zhao Weidong Home Page</title><link>https://wdongz.github.io/blog/tags/unity/</link><description>Recent content in Unity on Zhao Weidong Home Page</description><generator>Hugo -- 0.154.4</generator><language>en-us</language><lastBuildDate>Sun, 11 Jan 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://wdongz.github.io/blog/tags/unity/index.xml" rel="self" type="application/rss+xml"/><item><title>基于逆向规划的玩家意图识别系统：在 Unity 中的实现与架构分析</title><link>https://wdongz.github.io/blog/projects/coplayer/</link><pubDate>Sun, 11 Jan 2026 00:00:00 +0000</pubDate><guid>https://wdongz.github.io/blog/projects/coplayer/</guid><description>&lt;p&gt;在合作型游戏或复杂交互系统中，赋予 AI 智能体“心理理论”（Theory of Mind）能力是提升交互体验的关键。这种能力使 AI 能够通过观察玩家的低级操作（Action），逆向推断其高级意图（Goal）。本文将深入解析在 Unity 引擎中实现的一套逆向规划（Inverse Planning）系统，探讨其如何通过数学建模与启发式搜索实现高效的玩家行动预测。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="系统逻辑架构综述"&gt;系统逻辑架构综述&lt;/h2&gt;
&lt;p&gt;该系统的核心任务是解决一个典型的逆向概率问题：给定当前世界状态 $s$ 和观察到的动作 $a$，推断玩家正在执行特定顶层目标 $\sigma$（如某个特定菜谱）的概率。&lt;/p&gt;
&lt;p&gt;系统架构由 &lt;code&gt;GoalLikelihoodEvaluator&lt;/code&gt;（似然评估器）作为计算核心，并依赖 &lt;code&gt;RecipeManager&lt;/code&gt;（食谱管理器）提供静态的配方依赖关系与动态的游戏状态权威。整个推断流程可以概括为：从原始动作观测开始，经过环境约束过滤、理性代价估算、概率分布转换，最终通过贝叶斯框架完成似然聚合。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-约束识别目标检索与依赖剪枝"&gt;1. 约束识别：目标检索与依赖剪枝&lt;/h2&gt;
&lt;p&gt;推断的第一步是确定在当前环境下，哪些子目标（Subgoals）在逻辑上是可行的。系统不会盲目评估所有潜在任务，而是通过 &lt;code&gt;RecipeManager&lt;/code&gt; 查询候选目标 $\sigma$ 的动态依赖图。&lt;/p&gt;
&lt;p&gt;通过 &lt;code&gt;GetUnconstrainedGoals&lt;/code&gt; 接口，系统会递归检查配方树的执行进度。例如，若“番茄汤”目标要求“切碎的番茄”和“烧开的水”，而环境状态显示水已烧开，则系统会将搜索空间剪枝，仅保留“切碎番茄”作为当前的&lt;strong&gt;原始目标（Primitive Goal）&lt;/strong&gt;。这种基于先验逻辑的过滤极大地降低了后续代价计算的维度。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="2-估值建模理性决策假设与启发式代价"&gt;2. 估值建模：理性决策假设与启发式代价&lt;/h2&gt;
&lt;p&gt;系统的预测能力建立在**理性假设（Rationality Assumption）**之上：即假设玩家倾向于以最小的代价完成任务。为此，系统需要为每个有效的子目标 $g$ 计算启发式代价 $Q$。&lt;/p&gt;
&lt;p&gt;$Q$ 值的计算由两部分组成。首先是&lt;strong&gt;空间成本&lt;/strong&gt;，即智能体位置与所需食材之间的欧几里得距离；其次是&lt;strong&gt;状态转换成本&lt;/strong&gt;，系统会扫描场景快照（WorldStateSnapshot）以寻找最近的交互设备（如砧板或锅具），并将设备距离与操作耗时（如切菜所需的固定时长）累加。若关键道具在当前快照中缺失，系统将施加极大的惩罚项，从而在数学上抑制该目标产生的似然度。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="3-概率转换玻尔兹曼分布下的噪声处理"&gt;3. 概率转换：玻尔兹曼分布下的噪声处理&lt;/h2&gt;
&lt;p&gt;原始的代价 $Q$ 值不能直接用于概率推断，因为现实中的玩家行为往往包含噪声或次优决策。系统采用玻尔兹曼分布（Boltzmann Distribution）将代价映射为概率空间：&lt;/p&gt;
&lt;p&gt;$$P(g | s, \sigma) = \frac{e^{-\beta \cdot Q(s, g)}}{\sum_{g&amp;rsquo; \in UC} e^{-\beta \cdot Q(s, g&amp;rsquo;)}}$$&lt;/p&gt;
&lt;p&gt;在该公式中，$Q(s, g)$ 代表启发式代价，而参数 $\beta$（理性系数）决定了系统对“非理性”行为的容忍度。高 $\beta$ 值意味着系统假设玩家高度专业，细微的代价差异也会导致概率分布的剧烈偏向；低 $\beta$ 值则使系统表现得更加稳健，能够处理操作失误或不确定性带来的干扰。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="4-动作匹配上下文关联验证"&gt;4. 动作匹配：上下文关联验证&lt;/h2&gt;
&lt;p&gt;在确定了各子目标的先验概率 $P(g | s, \sigma)$ 后，系统需要验证观察到的实际动作 $a$ 与子目标 $g$ 的匹配程度。这一步通过 &lt;code&gt;IsActionRelevantToGoal&lt;/code&gt; 逻辑实现。&lt;/p&gt;</description></item><item><title>Unity 角色智能决策架构演进：从 FSM 到 GOAP 的技术选型与实现</title><link>https://wdongz.github.io/blog/posts/my-first-game-project/</link><pubDate>Mon, 05 Jan 2026 00:00:00 +0000</pubDate><guid>https://wdongz.github.io/blog/posts/my-first-game-project/</guid><description>&lt;p&gt;在现代游戏开发中，非玩家角色（NPC）的行为逻辑是构建沉浸感的核心要素。随着游戏玩法的日益复杂，简单的脚本化逻辑已难以满足需求。在 Unity 生态中，有限状态机（Finite State Machine, FSM）、行为树（Behavior Tree, BT）与目标导向行动规划（Goal-Oriented Action Planning, GOAP）是三种主流的 AI 决策架构。&lt;/p&gt;
&lt;p&gt;本文将从工程实现角度深入剖析这三种架构的运行机制，对比其优劣，并探讨在不同业务场景下的技术选型策略。&lt;/p&gt;
&lt;h2 id="一-有限状态机fsm确定性的基石"&gt;一、 有限状态机（FSM）：确定性的基石&lt;/h2&gt;
&lt;p&gt;有限状态机是游戏 AI 中最古老且基础的架构。其核心理念是将 AI 的行为分解为离散的“状态”（State），并通过预设的“条件”（Condition）在状态之间进行转换（Transition）。&lt;/p&gt;
&lt;h3 id="11-技术实现机制"&gt;1.1 技术实现机制&lt;/h3&gt;
&lt;p&gt;在 Unity 中，FSM 的实现通常经历两个阶段的演进：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;基于 Switch-Case 的硬编码&lt;/strong&gt;：适用于原型阶段，但在逻辑扩展时极易导致代码臃肿。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;基于状态模式（State Pattern）的面向对象封装&lt;/strong&gt;：将每个状态封装为独立的类（继承自 &lt;code&gt;BaseState&lt;/code&gt;），拥有 &lt;code&gt;Enter&lt;/code&gt;、&lt;code&gt;Execute&lt;/code&gt;、&lt;code&gt;Exit&lt;/code&gt; 三个生命周期方法。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;状态机的运行依赖于严格的图论逻辑：&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;stateDiagram-v2
[*] --&amp;gt; Idle
Idle --&amp;gt; Patrol: 计时器结束
Patrol --&amp;gt; Chase: 发现玩家
Chase --&amp;gt; Attack: 距离 &amp;lt; 攻击范围
Attack --&amp;gt; Chase: 距离 &amp;gt; 攻击范围
Chase --&amp;gt; Patrol: 玩家丢失
&lt;/code&gt;&lt;/pre&gt;&lt;h3 id="12-架构局限性"&gt;1.2 架构局限性&lt;/h3&gt;
&lt;p&gt;FSM 的最大优势在于&lt;strong&gt;确定性&lt;/strong&gt;与&lt;strong&gt;低计算开销&lt;/strong&gt;。每一时刻 AI 处于且仅处于一个状态，调试路径清晰。&lt;/p&gt;
&lt;p&gt;然而，当 AI 逻辑变得复杂（例如一个角色拥有 20 种状态）时，FSM 面临“转换爆炸”问题。每增加一个新状态，可能需要定义它与现有所有状态的转换关系，导致维护成本呈指数级上升（$O(N^2)$ 的复杂度）。虽然 Unity 的 Animator Controller 本质上是一个可视化 FSM，但在处理纯逻辑（非动画）时，连线过于复杂会导致“面条式”图表，难以阅读。&lt;/p&gt;</description></item></channel></rss>