做游戏 AI 时很多人的第一版 NPC 代码是这样的把巡逻、追击、攻击、返回等行为全部塞进同一个_process()用几个布尔变量和 if-else 控制切换。前三个状态还能勉强看清等状态到了五六个逻辑就会变成一团乱麻——改一个判定条件就可能触发连锁问题别人接手代码时也根本不敢动。有限状态机FSM是解决这类问题最经典、也是性价比最高的方案。它之所以值得专门写一篇 Godot 实战教程不是因为“用了设计模式显得高级”而是因为 FSM 能把分散在 if-else 里的行为决策重组为“状态 转换条件”的清晰结构。你不需要理解复杂的行为树理论也不需要引入任何第三方插件用 Godot 自带的 GDScript 就可以从零实现一套可复用的 NPC 行为系统。这篇文章会用 Godot 4.x 从零写一个带巡逻、追击、攻击、返回四个状态的智能 NPC。先给一个最小可运行版本让流程先跑通再用一个工程化状态模式版本重构让代码具备可扩展性。最后补充常见问题排查和工程建议。读完你会理解FSM 真正解决的是行为数量增多时的心智负担而不只是“把 switch 换成类”这种表面变化。1. 这篇文章真正要解决的问题先给一个明确结论如果你的 NPC 只是来回走两步不需要状态机。可一旦 NPC 开始同时具备巡逻、追击、攻击、返回、受伤、释放技能等行为再用 if-else 堆逻辑就是给自己挖坑。FSM 的核心价值可以从三个层面看第一层是行为建模。你可以把 NPC 的每个行为定义成一个独立状态每个状态只关注自己的逻辑。巡逻状态不需要知道攻击技能的 CD 是多少攻击状态也不需要关心巡逻路径怎么生成。第二层是切换管理。状态与状态之间的转换条件被集中在一个地方控制。当玩家进入视野范围巡逻状态切换到追击状态当玩家逃出失去范围追击状态切换到返回状态。这些条件清晰可见不会散落在几十行代码里。第三层是扩展能力。新增一个“受伤”状态不需要修改巡逻、追击、攻击的既有逻辑只需要增加一个新状态脚本并补充几条转换规则即可。这篇文章适合正在用 Godot 做游戏、有 GDScript 基础、想让 NPC 行为更可控的开发者。也适合刚接触游戏 AI 编程、想搞清楚状态机和一坨 if-else 到底差别在哪的初学者。读完你能直接跑通一个完整 NPC 行为系统并且理解背后的设计思路。2. 有限状态机的核心概念与 NPC AI 的对应关系2.1 什么是状态、事件、转换有限状态机由三样东西组成状态某一个时刻行为所处的模式。比如 NPC 正在巡逻这就是一个状态。转换条件触发状态切换的条件。比如“看到玩家”这个条件可以把巡逻切换成追击。动作进入状态、离开状态、状态持续过程中执行的行为。把 NPC 的 AI 拆成“感知 - 决策 - 行动”三段会更容易理解感知负责发现玩家、收集信息决策层决定下一步做什么行动层执行具体的移动、攻击、播放动画。FSM 位于决策层它本身不管移动怎么实现、碰撞怎么处理只负责回答一个问题当前应该处于哪个状态。2.2 一个典型 NPC 的状态迁移规则这篇文章实现的 NPC 包含四个状态完整迁移规则如下当前状态触发条件下一状态巡逻感知到玩家进入警戒范围追击追击玩家进入攻击范围攻击追击玩家持续跑出失去范围返回攻击玩家逃出攻击范围追击返回回到出生点附近巡逻返回返回途中再次感知到玩家追击注意一个细节追击状态使用的是“感知范围”和“失去范围”两个不同阈值。感知范围决定从巡逻切换到追击失去范围决定从追击切回返回。两个阈值之间留出缓冲区可以避免玩家在边界反复横跳导致状态频繁切换。这个设计叫做“滞回”在实际项目中非常常见。2.3 FSM、if-else 与行为树的对比方案特点适合场景if-else / 布尔变量简单直接但状态数量一多就难以维护、难以测试两三个状态以内的极简行为有限状态机状态显式化、切换条件集中管理、扩展性好大多数中小型游戏的 NPC AI、UI 状态、任务流程行为树可配置性强适合复杂决策但前期设计和调试成本高大型游戏 AI、需要组合复用行为的复杂场景不要一上来就拥抱行为树。对多数项目来说FSM 已经足够。状态机设计得不好的情况确实会变复杂但那通常不是因为 FSM 不可用而是因为状态粒度拆得不对或者切换条件被人为分散了。3. Godot 环境准备与前置条件3.1 版本选择本文以 Godot 4.x 标准版为例具体版本号建议以官网当前稳定版为准。Godot 3.x 的 GDScript 语法有一些差异比如随机函数rand_range、获取节点组的方式、move_and_slide的调用方式都不同但 FSM 的设计思路完全一致。Godot 提供标准版和 .NET 版两个版本。这篇文章不涉及 C#直接使用标准版即可。下载后解压到纯英文目录双击可执行文件启动。如果启动没有反应优先排查路径是否包含中文、杀毒软件是否拦截、显卡驱动是否过旧。3.2 创建项目打开 Godot 项目管理器新建项目项目名称GodotFsmNpc渲染器默认选择即可本文示例不依赖复杂渲染特性创建后进入编辑器项目结构建议提前规划好后续会使用如下目录GodotFsmNpc/ ├── scenes/ │ ├── main.tscn │ └── npc_ai.tscn ├── scripts/ │ ├── npc_ai.gd │ ├── player.gd │ ├── state_machine.gd │ └── states/ │ ├── state.gd │ ├── patrol_state.gd │ ├── chase_state.gd │ ├── attack_state.gd │ └── return_state.gd4. 最小可运行版用枚举 Match 写一个简单 NPC 状态机先不要急着上状态模式。用一个最简单、最直观的方式跑通两个状态的切换感受一下状态机的基本结构。创建一个CharacterBody2D节点挂上下面的脚本。为了让它能被看见给它加一个Sprite2D子节点即可。# 文件路径scripts/npc_minimal.gd extends CharacterBody2D enum State { PATROL, CHASE, ATTACK } var state: State State.PATROL var player: Node2D var home_position: Vector2 var next_patrol_target: Vector2 export var notice_range: float 240.0 export var attack_range: float 40.0 export var move_speed: float 120.0 func _ready() - void: home_position global_position player get_tree().get_first_node_in_group(player) next_patrol_target _random_point_near_home() func _physics_process(_delta: float) - void: if player null: return match state: State.PATROL: _patrol() State.CHASE: _chase() State.ATTACK: _attack() func _patrol() - void: if global_position.distance_to(next_patrol_target) 4.0: velocity global_position.direction_to(next_patrol_target) * move_speed move_and_slide() else: next_patrol_target _random_point_near_home() if global_position.distance_to(player.global_position) notice_range: state State.CHASE print(切换到追击) func _chase() - void: velocity global_position.direction_to(player.global_position) * move_speed move_and_slide() if global_position.distance_to(player.global_position) attack_range: state State.ATTACK print(切换到攻击) func _attack() - void: velocity Vector2.ZERO move_and_slide() # 实际项目在这里调用玩家的受伤接口 print(攻击玩家) func _distance_to_player() - float: return global_position.distance_to(player.global_position) func _random_point_near_home() - Vector2: var offset : Vector2( randf_range(-100.0, 100.0), randf_range(-100.0, 100.0) ) return home_position offset这段代码能直接跑。它能实现最基本的巡逻、追击、攻击切换逻辑是 FSM 的概念验证版。为什么还要做工程化重构因为你会发现几个问题状态逻辑全部堆在一个脚本里状态从 3 个涨到 8 个时脚本会迅速膨胀到上千行切换条件直接写在行为逻辑内部想查看完整迁移规则要靠“心里记”没有 enter / exit 生命周期每次进入状态时如果需要初始化数据只能在分支里临时写容易遗漏。5. 工程化版用状态模式重构 Godot NPC 行为系统工程化版本的核心思想是把“状态”也变成节点。每个状态是一个脚本挂在状态机节点下由状态机统一管理。这样做的好处是状态之间的逻辑互不干扰并且可以在场景树中直接看到所有状态节点。5.1 状态基类定义生命周期接口# 文件路径scripts/states/state.gd class_name NpcState extends Node # npc 和 state_machine 使用动态类型 # 避免状态脚本、状态机、NPC 控制器三者之间出现循环类型依赖 var npc null var state_machine null func setup(host, machine) - void: npc host state_machine machine func enter() - void: pass func exit() - void: pass func update(_delta: float) - void: pass每个具体状态只需要关注三个时机进入状态时做什么离开状态时做什么持续更新时做什么。5.2 状态机注册状态并统一切换状态机负责收集所有挂在它下面的NpcState子节点并提供统一的change_state()入口。# 文件路径scripts/state_machine.gd class_name NpcStateMachine extends Node export var initial_state: NpcState var states: Dictionary {} var current_state: NpcState null func _ready() - void: for child in get_children(): if child is NpcState: states[child.name] child child.setup(owner, self) if initial_state: change_state(initial_state.name) func change_state(state_name: String) - void: if not states.has(state_name): push_warning([FSM] 未知状态 state_name) return var new_state states[state_name] if current_state new_state: return if current_state: current_state.exit() current_state new_state current_state.enter() print([FSM] 进入状态 current_state.name) func update(delta: float) - void: if current_state: current_state.update(delta)这里有一个容易踩的坑change_state()里传入的名字必须和状态机子节点的节点名完全一致。等会挂场景时子节点叫什么名字这里就传什么名字。5.3 主 NPC 控制器# 文件路径scripts/npc_ai.gd class_name NpcAI extends CharacterBody2D export var home_position: Vector2 export var notice_range: float 240.0 export var lose_range: float 380.0 export var attack_range: float 40.0 export var move_speed: float 120.0 onready var state_machine: NpcStateMachine $StateMachine func _ready() - void: # 运行时记录出生点作为返回状态的目标坐标 home_position global_position set_physics_process(true) func _physics_process(delta: float) - void: state_machine.update(delta) func find_player() - Node2D: for node in get_tree().get_nodes_in_group(player): if is_instance_valid(node) and node is Node2D: return node return null func can_see_player() - bool: var player : find_player() if player null: return false return global_position.distance_to(player.global_position) notice_range func distance_to_player() - float: var player : find_player() if player null: return INF return global_position.distance_to(player.global_position)注意home_position的赋值逻辑。这里把出生点记录在_ready()中而不是在编辑器里手动设置。这样无论 NPC 拖到场景哪个位置返回逻辑都会自动回到出生位置不用手填坐标。5.4 巡逻状态# 文件路径scripts/states/patrol_state.gd class_name PatrolState extends NpcState export var patrol_radius: float 120.0 export var home_tolerance: float 8.0 export var wait_time: float 1.0 var _target_point: Vector2 Vector2.ZERO var _wait_timer: float 0.0 var _is_waiting: bool false func enter() - void: _target_point _random_point_near_home() _wait_timer 0.0 _is_waiting false func update(delta: float) - void: if npc.can_see_player(): state_machine.change_state(ChaseState) return if _is_waiting: _wait_timer - delta if _wait_timer 0.0: _is_waiting false _pick_next_target() return if npc.global_position.distance_to(_target_point) home_tolerance: _is_waiting true _wait_timer wait_time return npc.velocity npc.global_position.direction_to(_target_point) * npc.move_speed npc.move_and_slide() func _random_point_near_home() - Vector2: var offset : Vector2( randf_range(-patrol_radius, patrol_radius), randf_range(-patrol_radius, patrol_radius) ) return npc.home_position offset func _pick_next_target() - void: _target_point _random_point_near_home()巡逻状态增加了“到达目标点后等待一秒再选下一个点”的行为。这个细节能让 NPC 看起来更像在进行有节奏的巡逻而不是像一个停不下来的永动机。5.5 追击状态# 文件路径scripts/states/chase_state.gd class_name ChaseState extends NpcState func enter() - void: pass func update(_delta: float) - void: var distance : npc.distance_to_player() if distance INF: state_machine.change_state(ReturnState) return if distance npc.lose_range: state_machine.change_state(ReturnState) return if distance npc.attack_range: state_machine.change_state(AttackState) return var player : npc.find_player() if player: npc.velocity npc.global_position.direction_to(player.global_position) * npc.move_speed * 1.3 npc.move_and_slide()追击状态只做判断。玩家进入攻击范围就切攻击玩家跑出失去范围就切返回否则继续追。追击速度比巡逻速度快一点这是合理的节奏设计。5.6 攻击状态与返回状态# 文件路径scripts/states/attack_state.gd class_name AttackState extends NpcState export var attack_interval: float 1.0 export var attack_damage: int 10 var _timer: float 0.0 func enter() - void: _timer 0.0 func update(delta: float) - void: if npc.distance_to_player() npc.attack_range: state_machine.change_state(ChaseState) return npc.velocity Vector2.ZERO npc.move_and_slide() _timer - delta if _timer 0.0: _timer attack_interval _do_attack() func _do_attack() - void: var player : npc.find_player() if player and is_instance_valid(player): # 实际项目中在这里调用玩家的受伤接口同时播放攻击动画 print([NPC] 对玩家造成 , attack_damage, 点伤害)# 文件路径scripts/states/return_state.gd class_name ReturnState extends NpcState export var return_speed_ratio: float 1.0 export var arrival_tolerance: float 8.0 func enter() - void: pass func update(_delta: float) - void: # 返回途中重新发现玩家则中断返回并进入追击 if npc.can_see_player(): state_machine.change_state(ChaseState) return var home : npc.home_position var distance_to_home : npc.global_position.distance_to(home) if distance_to_home arrival_tolerance: state_machine.change_state(PatrolState) return npc.velocity npc.global_position.direction_to(home) * npc.move_speed * return_speed_ratio npc.move_and_slide()攻击状态里用_timer控制攻击频率避免每帧打印攻击信息。返回状态的判定逻辑也值得注意返回途中如果重新发现玩家立即中断返回进入追击。这符合直觉——已经被惊动的 NPC 不应该因为“我正在回家”就无视眼前的敌人。6. 运行结果与效果验证6.1 搭建测试场景创建一个主场景main.tscn结构如下Main (Node2D) ├── NpcAI (CharacterBody2D挂 npc_ai.gd) │ ├── Sprite2D │ ├── CollisionShape2D │ └── StateMachine (NpcStateMachine) │ ├── PatrolState (PatrolState) │ ├── ChaseState (ChaseState) │ ├── AttackState (AttackState) │ └── ReturnState (ReturnState) └── Player (CharacterBody2D挂 player.gd) ├── Sprite2D └── CollisionShape2DStateMachine 节点需要把initial_state导出属性指向PatrolState。四个状态节点建议按上面名字命名因为change_state()依赖节点名进行切换。给玩家挂一个最小控制脚本# 文件路径scripts/player.gd extends CharacterBody2D export var speed: float 200.0 func _physics_process(_delta: float) - void: var input : Vector2( Input.get_axis(ui_left, ui_right), Input.get_axis(ui_up, ui_down) ) velocity input * speed move_and_slide()回到编辑器点击F5运行场景或者通过命令行进入项目根目录godot --path .6.2 通过日志观察状态切换运行后可以在 Output 面板看到状态机日志[FSM] 进入状态PatrolState [FSM] 进入状态ChaseState [FSM] 进入状态AttackState [FSM] 进入状态ChaseState [FSM] 进入状态ReturnState [FSM] 进入状态PatrolState验证要点玩家站在警戒范围内NPC 从巡逻切换到追击玩家靠近到攻击范围NPC 切入攻击并周期性打印伤害玩家远离到失去范围NPC 切回返回走回出生点后重新进入巡逻返回途中突然靠近玩家NPC 应该能重新进入追击状态。如果某个切换没发生先看[FSM]日志停在哪里再对照状态迁移表检查是条件不满足还是状态名不匹配。7. 常见问题与排查思路问题现象可能原因排查方式解决方案状态一直停在巡逻切不到追击玩家节点没有加入 group player在场景中选中玩家节点查看 Node 面板的 Groups或运行时检查find_player()返回值给玩家节点添加 groupplayer状态切换频繁闪烁警戒范围和失去范围距离太近玩家在边界反复触发观察日志里是否出现连续来回切换把notice_range和lose_range拉开差距形成滞回区间NPC 处于追击状态但不移动没有调用move_and_slide()或者 velocity 被外部覆盖在 ChaseState 的 update 中加打印确认每个需要移动的状态都要设置 velocity 并调用move_and_slide()提示未知状态change_state()传入的状态名和状态机子节点名不一致在状态机脚本里打印states.keys()统一节点名或改用节点引用传参攻击一直刷屏攻击逻辑写在_physics_process的 update 中且没有冷却检查攻击频率使用冷却计时器控制攻击节奏Godot 启动没反应解压路径含中文、杀毒软件拦截、显卡驱动过旧查看系统日志、杀毒软件隔离记录重新解压到纯英文目录关闭拦截后再试还有一个常见误解和节点生命周期有关。StateMachine._ready()中会遍历子节点并调用setup()所以状态节点必须作为状态机的子节点挂在场景树中。如果把状态脚本单独放在某个角落节点下面它永远不会被注册也就无法切换。8. 最佳实践与工程建议8.1 让 FSM 只管决策不要塞入所有实现细节如果状态机里既有移动逻辑、又有动画播放、还有音效触发它又会变成一个“大泥球”。更好的做法是状态机只负责决策移动、动画、表现层通过信号或独立组件去完成。比如攻击状态决定“我应该攻击”至于攻击动画怎么播、伤害怎么计算、声音怎么放由其他模块处理。8.2 状态切换日志是刚需不是可选进入状态、离开状态时打印日志是排查 AI 问题最直接的抓手。上面的代码已经在change_state()里打印了状态切换实际项目中还可以把日志输出到文件方便追溯“为什么 NPC 刚才一直在反复切换”。给每个状态追加push_warning()或print()成本很低收益却非常大。8.3 阈值参数全部导出不要硬编码警戒范围、失去范围、攻击范围、移动速度这些参数尽量不要散落在代码里。把它们定义成export变量策划或你自己调数值时根本不需要碰代码。这听起来是老生常谈但我在很多 Godot 项目里见过把魔法数字写在状态脚本里的情况一旦需要修改就得在多个文件里搜索。8.4 警惕状态数量膨胀FSM 最舒服的区间是状态数量在 5 到 10 个左右。如果你的 NPC 有 20 个以上行为并且行为之间存在大量组合关系那就说明项目复杂度已经超出了轻量 FSM 的承受范围。此时可以看看行为树或层级状态机。不要迷信某一种方案根据项目复杂程度选择才是正路。8.5 引擎选型不要靠“听说”有些开发者会纠结“只用上线微信小游戏容器选 Godot 还是 Cocos”。这类问题的答案取决于你的具体目标平台、团队熟悉度、包体要求和性能预算不存在一个普适答案。稳妥的做法是拿核心玩法做一个 3 到 5 天的可玩原型分别导出到目标平台验证。Godot 场景树清晰、GDScript 上手快、开源免费Cocos 在小游戏生态和渠道适配方面经验积累更深。最终决策应该建立在原型验证上而不是论坛争论上。9. 总结与后续学习方向从枚举 Match 的最小版本到 Node 状态模式版本你看到的是同一个思路的两种落地方式。最小版本验证了 FSM 的基本结构工程化版本让状态可以独立扩展、独立维护。这套结构并不绑定 Godot——你把它迁移到 Unity、Cocos 甚至纯前端游戏项目设计思路依然成立。下一步值得探索的方向有三个第一给 NPC 接入NavigationAgent2D。当前示例里的追击是直接朝玩家方向移动遇到障碍物会卡住。接上导航寻路之后追击和巡逻状态仍不需要改动只需要把移动部分替换成导航代理驱动状态机负责决策的优势就体现出来了。第二加入更丰富的感知方式。当前只有距离检测你可以尝试增加视线遮挡检测从 NPC 到玩家做射线检测被阻挡时即使距离很近也不会触发追击。第三尝试把动画树和 FSM 做联动。状态机决定当前行为动画树根据状态播放对应动画两者通过状态名或枚举值关联。这是把 NPC AI 从“能跑”推向“看起来像一个角色”的关键一步。建议你先把这个四状态 NPC 跑通然后改一改警戒范围和失去范围感受滞回区间的效果再给它加一个“受伤”状态观察新增状态对既有逻辑的影响。这套练习做完你对有限状态机的理解会比只看概念深刻得多。如果这篇文章对你有帮助建议收藏备用。下一次做 NPC 行为系统时直接从这里的代码结构开始改比重新从 if-else 开始写要快得多。