尧图网页设计 
简介基于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 锚点偏到了头顶玩家会觉得“我明明打到他肚子了结果没判定到”。这个我在避坑章节会给出排查方法。帧数据表是这类型源码里的“黑匣子”实际手感全靠它。拿一份常见双人格斗的招式表来说招式伤害前摇帧活动帧后摇帧击退距离轻拳652840px重拳121031690px前踢9831260px前摇是按下按键后到判定出现前的等待活动帧是真正能打出伤害的时间窗口后摇是判定结束后角色不能行动的时间。这三段加起来的时长决定了出招的速度感。如果源码里只有动画没有数字你会发现自己调了半天特效手感还是不对因为问题根本不在特效。理解了这三个模块以后再去读任何双人战斗源码都会快很多。下一步我们就用 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/KP2 用方向键加小键盘数字键。直接在代码里读取按键扫描码当然可以但换手柄或者改键位时就要改动多处所以更合理的做法是定义一套动作名在 InputMap 里绑定具体按键。在 Godot 的项目设置里建议为每个玩家单独建一组动作不要共用同一个动作名。共用动作名的后果是两个人同时按“攻击”时这个动作只会发出一次信号。动作表大概这样动作名P1 按键P2 按键p1_left / p1_rightA / D左方向 / 右方向p1_jumpW上方向p1_attackJ小键盘 1p2_left / p2_right-左 / 右方向p2_attack-小键盘 2这里有个细节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放 GDScriptassets按类型继续拆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 的回放机制跑同一段录像对比两边的血量差额和耗时。数值调多了很容易把伤害和帧数改到失衡先看数据和再看主观感受才能避免把好版本改成坏版本。做到这一步你会发现自己已经不再是被动抄源码了而是真的在调一个双人战斗游戏。无论后面是加角色、做连招还是加网络联机踩过的这些坑都能复用。希望帮到你。本文还有配套的精品资源点击获取 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 锚点偏到了头顶玩家会觉得“我明明打到他肚子了结果没判定到”。这个我在避坑章节会给出排查方法。帧数据表是这类型源码里的“黑匣子”实际手感全靠它。拿一份常见双人格斗的招式表来说招式伤害前摇帧活动帧后摇帧击退距离轻拳652840px重拳121031690px前踢9831260px前摇是按下按键后到判定出现前的等待活动帧是真正能打出伤害的时间窗口后摇是判定结束后角色不能行动的时间。这三段加起来的时长决定了出招的速度感。如果源码里只有动画没有数字你会发现自己调了半天特效手感还是不对因为问题根本不在特效。理解了这三个模块以后再去读任何双人战斗源码都会快很多。下一步我们就用 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/KP2 用方向键加小键盘数字键。直接在代码里读取按键扫描码当然可以但换手柄或者改键位时就要改动多处所以更合理的做法是定义一套动作名在 InputMap 里绑定具体按键。在 Godot 的项目设置里建议为每个玩家单独建一组动作不要共用同一个动作名。共用动作名的后果是两个人同时按“攻击”时这个动作只会发出一次信号。动作表大概这样动作名P1 按键P2 按键p1_left / p1_rightA / D左方向 / 右方向p1_jumpW上方向p1_attackJ小键盘 1p2_left / p2_right-左 / 右方向p2_attack-小键盘 2这里有个细节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放 GDScriptassets按类型继续拆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 的回放机制跑同一段录像对比两边的血量差额和耗时。数值调多了很容易把伤害和帧数改到失衡先看数据和再看主观感受才能避免把好版本改成坏版本。做到这一步你会发现自己已经不再是被动抄源码了而是真的在调一个双人战斗游戏。无论后面是加角色、做连招还是加网络联机踩过的这些坑都能复用。希望帮到你。本文还有配套的精品资源点击获取