Godot 4双人战斗源码拆解：从状态机到判定盒的本地对战实现

简介：基于VC++开发的双人对战游戏完整源代码，面向C++初学者与游戏开发入门者，可用于学习Windows平台上经典小游戏的工程组织与实现逻辑。项目已在VC环境下调试通过，包含20幅对战地图，支持本地双人实时战斗，涵盖地图切换、敌我碰撞、子弹射击、音效反馈等核心机制。压缩包共59个文件，以map地图文件（20个）、bmp图像资源（15个）、C++源文件（6个）与头文件（7个）为主，另含wav音效、工程配置及说明文档，整体仅57KB，目录紧凑、适合逐文件研读。目前已有406人学习下载。通过分析这套源码，可以掌握类与对象的设计、精灵动画渲染、输入处理、音效播放以及双人交互逻辑，同时能直接修改地图和贴图，快速验证自己的游戏创意，是理解C++游戏系统如何从零搭建的优质实践样本。

1. 双人战斗游戏源代码：本地同屏对战，真正值钱的是“输入-状态-判定”这条闭环

有人以为“双人战斗游戏源代码”里最值钱的一定是复杂AI、华丽特效或者深奥的后端同步，真正动手做过一次就会明白：一份能在本地跑起来的同屏对战源码，核心价值是那套小而完整的输入采集、角色状态机、攻击判定和伤害结算闭环。本文就用一个 Godot 4.x 的双人战斗 Demo 源码为例，把它怎么拆、怎么跑、怎么改、坑在哪一次讲透。适合拿到源码却不知道怎么下手的初学者，也适合已经做过单机 Demo、正想把它整理成“能拿得出手”项目的一线开发者。

2. 拆解双人战斗源码：先看核心循环、状态机和帧数据，看懂这三处就能改

拿到一份双人战斗游戏源代码，不要急着双击打开跑起来，也不要先把美术资源翻一遍。先摸清楚它怎么组织一帧：输入从哪里来、逻辑以什么频率跑、渲染和逻辑是不是分离的。这三个问题决定了后面所有改动能不能落地。

2.1 核心循环：逻辑更新必须和渲染分开，否则双人不同步

几乎所有正经的战斗游戏，逻辑循环都长这样：采集输入 → 按固定时间步长更新状态 → 渲染画面。输入可能是键盘、手柄，也可能是 CPU 脚本伪造的输入；逻辑更新就是状态机在跑；渲染只负责把结果画出来。关键在于逻辑更新要用固定频率，比如 60Hz，而不是“每渲染一帧就更新一次”。

在 Godot 4.x 里，这一分工已经替你做好了：_physics_process(delta)默认按 60Hz 调用，适合放角色移动、攻击判定、受击硬直这类对战逻辑；_process(delta)的调用频率跟渲染帧率走，适合放 UI 补间动画、镜头平滑、粒子这类视觉表现。如果你的角色脚本把移动写在_process里，换成 144Hz 显示器后角色会跑得飞快，双人战斗就会变成两个人各玩各的节奏。

这里有个常见的误用：拿到源码后第一件事是把delta删掉，觉得“反正大家显示帧率差不多”。这是典型的翻车点。所有速度、位移、计时都要乘以delta，否则你的“轻拳前摇 5 帧”在不同电脑上就不是同一个时长。后续避坑部分我会专门再讲这个。

2.2 状态机：从站立到攻击，每个状态只允许一个出口

双人战斗角色的行为，本质是一张状态转移图。最基本的格斗状态至少有：站立、走、跳、攻击前摇、攻击活动帧、攻击后摇、受击硬直、倒地。如果你打开源码发现控制角色的是一个巨型if else，而且每个分支里同时在管移动和攻击判定，那这份代码大概率改起来很痛苦。

我的做法是给角色一个枚举状态和一个match分支，每个状态只处理自己该做的事。比如站立和走路时只处理移动输入，攻击时把横向速度清零并播放攻击计时，受击时只处理硬直计时。这样改一个招式时只需要动攻击状态那一段，不会误伤移动逻辑。

状态机里最容易漏掉的不是“进入”状态，而是“退出”状态。攻击结束以后是谁负责把 Hitbox 关掉？受击硬直结束以后角色会不会卡在受击动画里？这些都要在状态机里显式写清楚。很多源码跑起来感觉“手感黏黏的”，就是因为某个状态结束后没有干净地回到 Idle，而是残留了上一帧的移动速度或者判定盒状态。

2.3 判定盒：Hitbox 和 Hurtbox，手感是表格算出来的

双人战斗的攻击判定，一般不是拿攻击动画的 Sprite 去碰对方 Sprite，而是两个隐藏的碰撞区域：攻击方身上的 Hotbox（攻击判定盒）和受击方身上的 Hurtbox（受击判定盒）。Hitbox 通常在攻击的活动帧才启用，Hurtbox 则常驻。

判定盒的形状、大小、偏移直接决定“这里到底能不能打到”。同一份源码里，如果 Sprite 是 100x120，而 Hurtbox 锚点偏到了头顶，玩家会觉得“我明明打到他肚子了，结果没判定到”。这个我在避坑章节会给出排查方法。

帧数据表是这类型源码里的“黑匣子”，实际手感全靠它。拿一份常见双人格斗的招式表来说：

前摇是按下按键后到判定出现前的等待，活动帧是真正能打出伤害的时间窗口，后摇是判定结束后角色不能行动的时间。这三段加起来的时长决定了出招的速度感。如果源码里只有动画没有数字，你会发现自己调了半天特效，手感还是不对，因为问题根本不在特效。

理解了这三个模块以后，再去读任何双人战斗源码都会快很多。下一步我们就用 Godot 4.x 从零把一个最小可玩的本地双人 Demo 搭起来，每一步都落到代码上。

3. 用 Godot 4 本地跑通最小双人战斗 Demo：从空场景到能打伤

这一章的目标不是做成品游戏，而是把上一个章节的原理落到一个能跑起来的 Demo 上：两个角色在同一张地图上移动、跳跃、出拳、扣血、分出胜负。我一般会用 Godot 4.x 做这类本地双人对战原型，因为它的 InputMap 和节点树非常适合快速验证玩法。

3.1 场景树与节点规划：舞台、角色、UI 三块分家

不要把所有东西挂在一个节点下。工程虽然小，但结构必须干净。我会先把场景树分成舞台、角色、UI 三块，舞台只管地面和镜头，角色管自己的状态机，UI 独立在 CanvasLayer 里，避免画面坐标影响血条。

场景树大概长这样：

Main (Node2D) ├─ Arena (Node2D) │ ├─ Ground (StaticBody2D) │ └─ Camera2D ├─ P1 (CharacterBody2D) │ ├─ Sprite2D │ ├─ Hitbox (Area2D) │ └─ Hurtbox (Area2D) ├─ P2 (CharacterBody2D) │ ├─ Sprite2D │ ├─ Hitbox (Area2D) │ └─ Hurtbox (Area2D) └─ UI (CanvasLayer) ├─ HP_Bar_P1 (ProgressBar) └─ HP_Bar_P2 (ProgressBar)

Hitbox 和 Hurtbox 都挂在角色节点下面，但 Hitbox 默认禁用，只在攻击活动帧开启。很多人会直接把攻击判定放在 Sprite 上，结果 Sprite 翻转后碰撞区域也跟着翻到了背后。更稳的做法是给 Hitbox 单独一个子节点，这样翻转只会影响画面，碰撞区域由你手动控制。

Camera2D 放在 Arena 下面而不是角色身上，是因为本地同屏双人不需要镜头跟随某一个玩家。如果做成追镜头，两个人一旦拉开距离就有人出画。固定镜头配合一个足够大的舞台是更省事的方案。

3.2 输入映射：一张键盘怎么分给两个玩家

本地双人最常见的方案是 P1 用 WASD 加 J/K，P2 用方向键加小键盘数字键。直接在代码里读取按键扫描码当然可以，但换手柄或者改键位时就要改动多处，所以更合理的做法是定义一套动作名，在 InputMap 里绑定具体按键。

在 Godot 的项目设置里，建议为每个玩家单独建一组动作，不要共用同一个动作名。共用动作名的后果是两个人同时按“攻击”时，这个动作只会发出一次信号。动作表大概这样：

这里有个细节：P1 和 P2 的左右移动如果用同一个动作名，那么两人无法同时向相反方向走，因为get_axis会认为你在用一个摇杆。所以动作名必须带前缀p1_和p2_。这是很多本地双人源码第一次跑起来会遇到的隐性 bug。

3.3 角色脚本：移动、跳跃、攻击三分段判定

下面这段player.gd是角色脚本的基础骨架，一个角色实例挂到 P1，另一个挂到 P2，通过input_prefix区分谁操作谁。

extends CharacterBody2D ## 本地双人角色：用 input_prefix 区分 P1/P2 的输入动作 @export var input_prefix: String = "p1" @export var max_hp := 100 const SPEED := 240.0 const JUMP_VELOCITY := -420.0 enum State { IDLE, WALK, JUMP, ATTACK, HIT } var state := State.IDLE var attack_timer := 0.0 var hit_timer := 0.0 var hp := max_hp func _physics_process(delta: float) -> void: match state: State.IDLE, State.WALK: _handle_walk_input() if Input.is_action_just_pressed(input_prefix + "_jump") and is_on_floor(): velocity.y = JUMP_VELOCITY state = State.JUMP if Input.is_action_just_pressed(input_prefix + "_attack"): _start_attack() State.JUMP: # 空中仍然保留左右移动，但不能二段跳 var dir := Input.get_axis(input_prefix + "_left", input_prefix + "_right") velocity.x = dir * SPEED if is_on_floor(): state = State.IDLE State.ATTACK: velocity.x = 0 attack_timer -= delta if attack_timer <= 0.0: _end_attack() State.HIT: velocity.x = 0 hit_timer -= delta if hit_timer <= 0.0: state = State.IDLE move_and_slide() func _handle_walk_input() -> void: var dir := Input.get_axis(input_prefix + "_left", input_prefix + "_right") velocity.x = dir * SPEED if dir == 0: state = State.IDLE else: state = State.WALK func _start_attack() -> void: state = State.ATTACK attack_timer = 0.12 # 0.12 秒，约 7 帧的活动时长 $Hitbox.monitoring = true $Hitbox.visible = true func _end_attack() -> void: $Hitbox.monitoring = false $Hitbox.visible = false state = State.IDLE func take_damage(dmg: int, hitstun: float) -> void: if state == State.HIT: return hp = maxi(hp - dmg, 0) state = State.HIT hit_timer = hitstun $Hitbox.monitoring = false $Hitbox.visible = false

这个脚本里有两个值得注意的参数。第一个是attack_timer = 0.12，它代表攻击活动帧持续时长，在 60Hz 物理帧下就是 7 帧左右。想让轻拳“快出快收”，就把这个值调小，同时前摇由玩家按下攻击时到进入 Attack 状态之间的延迟来体现，更完整的做法是用一个独立的前摇计时器，但最小 Demo 先把活动帧管住即可。第二个是take_damage里的hitstun参数，它决定被打后角色硬直多久，0.18 秒是格斗游戏里比较轻的受击硬直，适合新手 Demo。

玩家输入用的是is_action_just_pressed而不是is_action_pressed，这一点对战斗手感非常关键。前者只在按下那一帧触发一次，后者会跟随物理帧反复触发，导致按住攻击键时角色不停出招。如果你拿到的源码里攻击是用is_action_pressed写的，这就是手感发飘的直接原因。

3.4 伤害结算：攻击框检测到受击框之后做什么

角色脚本只负责发起攻击和接收伤害，真正的碰撞检测交给 Hitbox 这个 Area2D。下面这段hitbox.gd挂在角色的 Hitbox 节点上：

extends Area2D ## 攻击判定盒：检测到对方的 Hurtbox，就调用目标身上的 take_damage @export var damage := 8 @export var hitstun := 0.18 var _already_hit: Node2D = null func _on_body_entered(body: Node2D) -> void: # 同一个攻击帧只结算一次，防止连续扣血 if _already_hit == body: return if body.has_method("take_damage"): body.take_damage(damage, hitstun) _already_hit = body

在实际编辑器中，你需要把 Hitbox 的body_entered信号连接到这个_on_body_entered方法。_already_hit是一个很必要的细节：Area2D 的body_entered在一帧里可能被触发多次，如果不去重，一个轻拳能瞬间打成丝血。角色进入受击状态后，还要把 Hitbox 关闭，否则对方恢复动作后碰撞区域仍开着，伤害会继续结算。

到这里，一个能跑的最小双人战斗已经成立了。两个角色可以移动、跳跃、出拳、挨打，下一步需要处理的是血条和胜负判定。血条更新我一般放在 UI 节点里用take_damage发出的信号驱动，而不是在角色脚本里直接改 UI，具体原因放到避坑部分细说。

4. 双人战斗源代码避坑：本地双人最容易翻车的 5 个问题

这一章是血泪经验。以下五个问题几乎在每个从零开始做双人战斗的人身上都发生过，而且最后都能归到输入、状态机、物理层或者 UI 更新这四类原因上。

4.1 现象：脸都还没碰到，血条就开始掉

原因通常是碰撞盒锚点没有和角色贴图对齐。Sprite 的纹理中心默认在节点原点，而 Area2D 的碰撞形状也是以它自己节点为原点，一旦两个原点不在同一位置，Hitbox 或 Hurtbox 就会偏到角色前方半身位置。结果就是两个人还没靠近，身体边缘的“空气墙”已经发生碰撞，开始扣血。

解决的方法是先打开 Godot 的 Debug 绘制碰撞层，确认碰撞形状和贴图是否重叠，再手动调整 Area2D 子节点的position。更稳妥的做法不是去调 Sprite，而是给角色底部单独一个 Origin 标记节点，让 Hurtbox 挂在这个标记上。只要标记对齐角色脚底中心，后续换动画贴图也不会重新导致错位。

4.2 现象：攻击键被按住就自动连打，角色像在抽筋

原因是没有区分“按下”和“按住”。如果攻击触发条件写的是Input.is_action_pressed("p1_attack")，那么每帧物理更新都会进入攻击分支，攻击刚结束又立刻重新开始，看起来就像自动连打。另一个隐蔽原因是状态机里没有做“当前状态是否允许攻击”的判断，攻击状态结束后没有回到 Idle，而是直接又触发了新的攻击。

解决方法是把攻击触发换成is_action_just_pressed，同时在_start_attack开头加一个状态保护：只有state == State.IDLE or state == State.WALK时才允许进入攻击。若是想实现“按住连打”，也应该单独写一个连击输入模块，而不是靠物理帧自动重复触发。这样出招节奏才会受你的按压力度控制。

4.3 现象：同一份代码，换一台电脑跑速度就不一样

原因是用渲染帧_process驱动逻辑，或者位移不乘delta。双人战斗的逻辑必须跑在固定频率上，Godot 的_physics_process默认 60Hz，而_process取决于显示器的刷新率。你把角色移动写在_process里并且速度直接用position += Vector2(1, 0)，60Hz 的电脑和 144Hz 的电脑会跑出完全不同的手感。

解决方法是把逻辑移动全部挪到_physics_process，所有速度量乘上delta。另外还要在项目设置里确认Engine.physics_ticks_per_second是 60，不要因为某些教程推荐 120 就随意改，除非你同时把帧数据表里的帧数字全部重算一遍。格斗游戏的帧数单位默认就是 1/60 秒，帧数据和物理频率必须一致。

4.4 现象：手柄玩家插上以后按键错位，十字键没反应

原因是在 InputMap 里只绑定了键盘按键，手柄的轴没有做抽象映射。手柄的左右移动通常是一个模拟轴，不是两个按钮，直接读到的是连续值而不是 0 或 1。Godot 里如果没有为动作绑定手柄轴，玩家拔掉键盘后整个角色就会失灵。

解决方法是先把手柄按钮和轴都绑定到对应的p1_、p2_动作上，然后在读轴时加一个死区处理：

var axis := Input.get_axis(input_prefix + "_left", input_prefix + "_right") if absf(axis) < 0.15: axis = 0.0 velocity.x = axis * SPEED

死区数值 0.15 是手柄模拟轴的常见阈值。低于这个值的抖动会被过滤掉，避免角色在静止时左右轻微晃动。不同手柄的摇杆回中偏移不一样，如果发现角色自己慢慢向左走，就把这个阈值往上调到 0.2。

4.5 现象：血条掉血像“抽风”，有时候掉了一块又弹回去

原因有两层：一是角色脚本里直接修改 UI 节点，而 UI 又通过另一个地方的信号再次更新，两个写入口的顺序不确定；二是血条数值没有做clamp，伤害超过当前血量后 ProgressBar 的 value 变成负数或超过最大值。角色状态机里如果受击硬直结束后又把 hp 恢复成了之前的值，也会造成弹回。

解决方法是只保留一个修改血条数值的入口。角色受伤时发出信号，UI 节点监听信号并更新 ProgressBar，同时用clampf(hp, 0, max_hp)包住血量值。血条动画用Tween做延迟跟随，这样视觉上不是瞬间掉血，而是一段平滑的移动，看起来更像正经格斗游戏。

5. 把 Demo 变成“拿得出手”的项目：CPU 对手、回放和源代码管理

“能打”和“能拿得出手”中间还差着很大一段。体验过本地双人源码的人都知道，一个人测试的时候根本测不出攻击判定准不准，因为没人跟你配合。加一个最低限度的 CPU 对手、一份输入回放机制、一套干净的源代码管理约定，会比继续堆角色和招式更快让这个项目变得完整。

5.1 加一个 CPU 对手：出招不是复杂 AI，而是“距离 + 冷却 + 随机表”

很多人一听 AI 就紧张，其实格斗游戏里的 CPU 对手，多数情况根本不需要多聪明。一个能让新手练招的 CPU，只需要做三件事：和玩家保持距离、根据距离决定出什么招、在出招后冷却一段时间再行动。与其上行为树，不如先用一个带冷却的随机出招脚本。

extends CharacterBody2D ## 极简 CPU 对手：根据距离和冷却时间随机出招 @export var attack_cooldown := 1.2 @export var react_min := 0.3 @export var react_max := 0.8 var _cooldown := 0.0 func _physics_process(delta: float) -> void: _cooldown -= delta var dist := _distance_to_player() if _cooldown <= 0.0: if dist < 100.0: # 近距离出轻拳，概率高，给玩家足够反应时间 if randf() < 0.6: _start_attack("light") else: _start_attack("heavy") _cooldown = randf_range(react_min, react_max) elif dist < 220.0: # 中距离概率出踢 _start_attack("kick") _cooldown = attack_cooldown func _distance_to_player() -> float: var player = get_tree().get_first_node_in_group("player") if player == null: return 99999.0 return global_position.distance_to(player.global_position)

这个脚本里的attack_cooldown和react_min/react_max就是要调的参数。attack_cooldown控制 CPU 的整体进攻频率，设大了它会变成“木桩”，设小了玩家会被压制到没法反击。react_min和react_max是一段随机范围，模拟人的反应不是每次一样快，而不是按固定间隔出招，这样才不会让玩家背板。

我曾见过有人把 CPU 做成“玩家一抬手就被读指令”，然后调了一晚上代码都没修好，最后发现是随机种子没重置，每一次测试 AI 都走同一条路径。如果你的 CPU 对手也出现“每次打都是同样玩法”，就检查一下随机种子是不是被写死成了固定值。

5.2 录制回放：把输入序列存下来，比录屏更有说服力

双人战斗里很多 bug 是偶发的，比如“这一拳明明打中了却没扣血”。这种问题靠录屏很难定位，因为录屏只能看到画面，看不到判定盒和按键时序。我一般会给角色输入模块加一个回放日志：每帧把按键状态写进一个数组，并保存一份到本地文件，事后用同一份输入序列重新驱动物理逻辑。

最简单的回放方案是记录每一帧的“左右轴 + 跳跃 + 攻击”这几个布尔量，回放时不再读取 InputMap，而是从数组里取这一帧的输入。注意：回放时必须保证“输入序列”和“逻辑更新频率”一一对应。如果你在 60Hz 物理帧里记录输入，回放也必须让物理帧跑在 60Hz，否则节奏会偏移。如果角色行为里用了randf()，还要把随机种子也存下来，才能保证回放结果完全一致。

这个机制也能拿来证明一个调整有效，我通常在调完一段手感后，用同一段输入序列跑前后两个版本，直接对比双方血量变化，比单纯靠手感判断更可靠。

5.3 源代码管理：目录怎么分，提交信息怎么写

双人战斗项目的源代码管理，重点不是分支策略，而是别把不该提交的东西塞进去。Godot 4 项目的缓存目录.godot/里存着导入缓存和资源索引，每个人本地都会重新生成，提交进去只会让合并冲突莫名其妙变多。export_presets.cfg如果每个成员本地的导出路径不一样，也容易冲突。

建议的目录结构是：

project.godot scenes/ scripts/ assets/ sprites/ audio/ tests/ docs/

scenes只放场景文件，scripts放 GDScript，assets按类型继续拆，tests放自动测试脚本，docs放帧数据表、招式表这类设计文档。提交信息不要写“update”或者“fix bug”，而是写清楚改的是哪一层：例如“balance: 降低重拳击退距离”、“fix: 受击后 HP 在低血量时被错误恢复”。一次提交只动一个模块，不要让移动逻辑和 UI 更新混在同一个提交里，这样后面想回滚某个手感调整时才不会拉上无关改动。

6. 手感调优的最后一块：输入缓冲、延迟补偿和验收习惯

双人战斗源码做到能跑、能打、能回放以后，剩下的就是手感。手感里最影响最终体验的，不是数值本身，而是“输入是否被及时响应”。你按下轻拳时，如果正好还在上一招的后摇里，这个按键会被吞掉，玩家会觉得自己明显按了却不出招。这其实是对战游戏里最常见的负反馈。

解决方法是加一个输入缓冲：把玩家最近几帧的按键记录到一个队列里，当前状态不允许出招时，先不丢弃这个按键，而是等后摇结束的瞬间立刻执行。窗口通常取 3 到 5 帧，也就是 0.05 到 0.083 秒。窗口太短救不了手快的玩家，太长又会让人觉得招式像延迟了半拍。

var input_buffer: Array = [] func _physics_process(delta: float) -> void: # 每次物理帧把自己想要执行的攻击意图写进缓冲 if Input.is_action_just_pressed(input_prefix + "_attack"): input_buffer.append("attack") # 只在当前状态允许攻击时消费缓冲，否则保留几帧 if not input_buffer.is_empty(): if state in [State.IDLE, State.WALK]: _start_attack(input_buffer.pop_front())

这个缓冲队列会引入一个新的矛盾：如果玩家在攻击结束前狂按了一串按键，是不是都要执行？我一般只保留最近一个输入意图，并在状态转移后清空旧记录，否则它会在后摇结束后连续出招，反而破坏节奏。调这个参数时不要只看数值，你要亲自玩一局，记住哪个时刻出招“感觉像没按出来”，然后去回放文件里看那几帧的输入状态。

手感这事的另一个坑是“自己测永远测不出问题”。双人战斗是交互型玩法，一个人用键盘左右互搏，精力被分裂，不可能准确判断招式有没有节奏问题。我养成的习惯是至少十分钟的连续循环测伤害流程：每隔一阵子把速度、攻击帧、硬直改成两个候选值，用 5.2 的回放机制跑同一段录像，对比两边的血量差额和耗时。数值调多了很容易把伤害和帧数改到失衡，先看数据和再看主观感受，才能避免把好版本改成坏版本。

做到这一步，你会发现自己已经不再是被动抄源码了，而是真的在调一个双人战斗游戏。无论后面是加角色、做连招还是加网络联机，踩过的这些坑都能复用。希望帮到你。

本文还有配套的精品资源，点击获取