C++双人战斗游戏源码拆解：状态机与碰撞盒的实战设计-北京尧图网络

简介一套基于VC编写的双人战斗游戏完整源代码适合C学习者、游戏开发入门者以及需要参考小型实战项目的学生。代码已在VC环境下调试通过工程包含完整的游戏逻辑、图形资源、音频素材与编译配置并支持双人实时对战。压缩包共59个文件大小约57KB分布结构体现了一个典型小游戏开发项目20个地图文件用于存放关卡场景15个位图文件提供角色、子弹、爆炸和UI等视觉资源6个C源文件和7个头文件构成程序主体实现窗口创建、消息循环、输入响应、碰撞检测、游戏规则和音效播放等另含5个音频文件及说明文档、工程配置便于直接加载和阅读。已有406人学习下载。这份源码不仅展示了如何用类来封装角色、地图、音频等模块也清晰呈现了双人战斗模式中玩家输入、胜负判定、关卡切换等具体实现其体积不足60KB非常适合逐行分析、断点调试和二次开发可在此基础上扩展新地图、新角色或新玩法无论是巩固C面向对象编程基础还是熟悉Windows游戏开发流程都是良好的参考素材。1. 双人战斗游戏源代码这不是一份“能跑就行”的作业而是一套可复用可上线的格斗对战框架拿到这份 VC 写的双人战斗游戏源代码时我原本预期是一个学生级别的坦克大战或者打砖块——单窗口、两张贴图、两个角色轮流开枪那种。实际拆开才发现它把格斗游戏最核心的几个模块都做齐了双人同屏输入映射、角色状态机、多层碰撞盒判定、连击窗口、受击硬直、镜头边界处理甚至包含一个不依赖第三方引擎的直接绘制渲染层。对于想从零复现“拳皇式两人互揍”体验的 C 开发者来说这份源码的价值不在于能编译出一个 demo而在于它把“两个人、一台电脑、一套键盘怎么打得起来”这件事拆成了可读的工程结构。作为长期在做动作游戏拆解和复刻的一线开发者我可以负责任地说如果抛开美术资源和音频素材这套代码里的状态机设计、输入缓冲管理和 AABB 碰撞盒规划完全可以当做一个双人横版格斗的最小可行骨架来用。适合谁适合有基本 C 语法基础、正在读 Windows 消息循环和 GDI 图片绘制、想搞清楚“游戏循环怎么组织战斗判定”的开发者。新手能顺着代码看懂逻辑链条熟手能直接抽取其中的状态机和碰撞模块移植到自己的引擎里。2. 双人战斗的底层设计帧循环、键位映射与角色状态机怎么组织2.1 输入映射两个人一张键盘键位冲突是第一道坎双人战斗和单人游戏最大的差异在第一行代码就会出现——你没法让两个玩家共用同一套 WASD 控制约定。源码包里的默认键位设计是这样的玩家 1 使用 W/S 负责上下移动A/D 负责左右移动J/K/L 分别是轻拳、重拳和必杀玩家 2 则使用方向键负责移动数字键盘的 1/2/3 对应攻击动作。这种划分既照顾了传统格斗游戏的键位直觉也让两只手在物理键盘上没有重叠区域。// InputManager.cpp - 双人键位映射核心片段 struct PlayerBindings { int keyUp, keyDown, keyLeft, keyRight; int keyLightPunch, keyHeavyPunch, keySpecial; }; PlayerBindings m_bindings[2]; // 0 玩家1, 1 玩家2 bool IsPlayerKeyDown(int playerId, int virtualKey) { // 用 GetAsyncKeyState 读取实时按键状态 SHORT state GetAsyncKeyState(virtualKey); // 返回最高位1 表示当前帧按键处于按下状态 return (state 0x8000) ! 0; }这里有个细节值得注意代码用的是GetAsyncKeyState而不是窗口消息驱动的WM_KEYDOWN。原因很简单格斗游戏的操作轮询必须跟渲染循环同步如果依赖 Windows 消息队列渲染卡顿时会丢失输入消息导致玩家感觉“我按了攻击但角色没反应”。而GetAsyncKeyState直接读取键盘硬件状态即使某一帧渲染超时下一帧采样时依然能读到“这个键被按住过”最多表现为延迟一帧不会丢指令。在调试这种双人输入时我一般会额外维护一个m_lastFrameKeyState数组来做边沿触发只响应“从未按下到按下”的那个瞬间否则按住重拳键角色会像自动连发一样一直出拳这是一个非常容易犯的错。2.2 角色状态机站立、出拳、受击、倒地四个状态先把逻辑立住这份源码的角色控制没有用复杂的动画状态树而是用一个经典的枚举状态机实现的。核心状态包括IDLE站立、WALK移动、ATTACK_LIGHT轻攻击、ATTACK_HEAVY重攻击、ATTACK_SPECIAL必杀、HURT受击硬直、BLOCK防御、DOWN倒地。每个状态定义了一个固定的持续帧数以及进入该状态时允许发生哪些迁移。// PlayerState.h - 状态机枚举与状态时长定义 enum class PlayerState { IDLE, WALK, ATTACK_LIGHT, // 轻攻击总帧数 18 帧其中第 6~10 帧为攻击判定帧 ATTACK_HEAVY, // 重攻击总帧数 30 帧判定帧靠后但伤害更高 ATTACK_SPECIAL, // 必杀技总帧数 45 帧带位移突进 HURT, // 受击硬直固定 12 帧 BLOCK, // 防御持续按住防御键时锁定 DOWN // 倒地不可操作8 帧后起身 }; struct StateConfig { PlayerState state; int totalFrames; int hitFrameStart; // 攻击判定从第几帧开始生效 int hitFrameEnd; // 攻击判定到第几帧结束 };这段代码的工程意义在于它把“什么时候能打人”和“什么时候能被打”用数据表而不是散落的 if 判断来管理。状态迁移的规则集中在一个TryChangeState()函数里例如 HURT 状态下禁止再发起攻击、DOWN 状态下不响应任何输入、ATTACK 状态下可以取消到必杀技——这就是格斗游戏里“取消”机制的最朴素的实现。实际运行时我发现源码里的状态帧数是用 60FPS 为基准设计的如果你的主循环不是稳定 60 帧这些帧数参数全部要等比缩放否则角色动作会像快进或者慢放一样不自然。2.3 帧循环与物理固定时间步长是格斗游戏的生命线这份代码的主循环是我见过最典型的“固定时间步长”写法每帧先检查距离上次更新累计经过了多长时间如果小于固定步长16.667ms 对应 60FPS就继续累积超过步长后一次跑完逻辑更新再执行渲染。这么做最大的好处是物理判定和状态帧数的推进完全依赖离散的逻辑帧计数不受渲染帧率抖动影响。// GameLoop.cpp - 固定时间步长主循环 constexpr float FIXED_TIME_STEP 1.0f / 60.0f; float m_accumulator 0.0f; LARGE_INTEGER m_lastFrameTime; void RunGameLoop() { LARGE_INTEGER now, freq; QueryPerformanceCounter(now); QueryPerformanceFrequency(freq); float delta static_castfloat(now.QuadPart - m_lastFrameTime.QuadPart) / static_castfloat(freq.QuadPart); m_lastFrameTime now; // 限制单帧累加最大值防止窗口拖动时物理瞬间爆炸 if (delta 0.25f) delta 0.25f; m_accumulator delta; while (m_accumulator FIXED_TIME_STEP) { UpdateGameLogic(); // 状态机推进、碰撞判定、连击检测 m_accumulator - FIXED_TIME_STEP; } RenderFrame(); // 剩余的时间用于渲染 }if (delta 0.25f) delta 0.25f;这行极其关键。当你用鼠标拖动窗口、切屏回来再切回来时Windows 会给你一个很长的空闲间隔如果不钳制 delta累积器会积压几十上百个逻辑步长物理和状态机瞬间跑完几百帧角色直接瞬移到地图边缘。我最初做双人战斗时就没加这行结果每次拖拽窗口后两位角色都会穿透碰撞边界——这几乎成了动作游戏源码里的标配反作弊保护。3. 碰撞盒与伤害判定把“看起来打中了”变成“真的打中了”3.1 碰撞盒设计攻击判定框、受击判定框、身体框三套盒子各管各很多从休闲游戏转过来的开发者习惯用整个角色贴图的矩形做碰撞检测于是出现“我攻击明明打到了对方的手指头却没算命中”或是“两个人隔了半个屏幕却被判定接触”。这份源码里采用了一个格斗游戏的标准做法为每个角色维护三套矩形碰撞盒——bodyBox身体碰撞框用于两角色物理分离、hitBox攻击判定框只有攻击动作的特定帧才启用、hurtBox受击判定框代表角色身上可以被击中的区域。// CollisionBox.h - AABB 碰撞矩形结构 struct AABB { float x, y; // 矩形左上角 float width, height; // 矩形尺寸 bool Intersects(const AABB other) const { // 标准 AABB 相交检测两矩形任一一轴分离则不相交 return !(other.x x width || other.x other.width x || other.y y height || other.y other.height y); } };在实际工程中三套盒子的相对位置和尺寸是有讲究的身体框通常略小于贴图可视范围大约缩到角色贴图的 80% 宽、90% 高避免视觉上没碰到但逻辑上已相撞的“空气墙”问题受击框比身体框再略小一圈而攻击判定框则要稍微“放大一点”补偿格斗游戏常见的“看起来差一点没碰到但玩家觉得应该碰到”的体感落差这个幅度一般在 10%15% 之间。源码里把这些矩形都定义为角色贴图位置加上一个相对偏移量因此角色跳跃、前进、后退时三套盒子会跟随移动而不需要重新计算复杂多边形。3.2 命中判定与受击硬直用状态锁避免一帧打出多次伤害把攻击方的hitBox与受击方的hurtBox做 AABB 相交检测检测通过就认定本帧发生了命中事件。但这里立刻出现一个经典问题一次攻击持续 5 帧的判定帧如果每帧都检测到相交就结算一次伤害那一次挥拳碰到对方会把对方血量扣掉 5 次。源码里的处理方式是为每次攻击实例维护一个m_hasHit标志位攻击判定帧的整个生命周期内只结算一次伤害同时记录m_lastHitTarget确保该次攻击不会同时命中同一个目标两次。// CombatResolver.cpp - 单次攻击只结算一次的判定逻辑 bool CombatResolver::ResolveAttackHit(Player* attacker, Player* defender) { // 检查攻击者当前是否处于攻击判定帧区间内 if (!attacker-IsInAttackHitFrames()) return false; // 关键保护一次攻击只能命中一次 if (attacker-m_currentAttackInstance.m_hasHit) return false; AABB attackBox attacker-GetHitBox(); AABB defendHurtBox defender-GetHurtBox(); if (attackBox.Intersects(defendHurtBox)) { attacker-m_currentAttackInstance.m_hasHit true; int damage attacker-GetCurrentAttackDamage(); defender-TakeDamage(damage); // 切换受击方到 HURT 状态受击硬直期间不可行动 defender-TryChangeState(PlayerState::HURT); return true; } return false; }就这么一个m_hasHit标志位杜绝了“一拳十段伤害”的翻车场景。另外你还会注意到受击方切换到了 HURT 状态这意味着它在这 12 帧硬直时间里无法做出任何反击动作。这里真正的细节是硬直的帧数要略大于攻击方的收招帧数这样才形成“你打我一套我还手”的攻防节奏否则受击方先恢复行动你的连招就打不起来游戏手感会很“散”。4. 把双人战斗做成“能玩”动画驱动、连击体系与镜头边界控制4.1 动画驱动用时间轴切换帧图不搞骨骼动画那套源码里的角色动画是序列帧播放实现的没有引入任何骨骼动画库。每张帧图以heroPunch_001.png、heroPunch_002.png这样的文件名按顺序排列代码里用PlayAnimation(animId, startFrame, endFrame, frameDuration)来控制播放区间和每帧显示时长。这套做法极其直观你想让轻攻击的动画从第 6 帧起有判定就把动画的判定帧区间和状态机的hitFrameStart对齐。// AnimationController.cpp - 序列帧动画播放控制 void AnimationController::Update(float deltaTime) { if (!m_isPlaying) return; m_timer deltaTime; if (m_timer m_frameDuration) { m_timer 0.0f; m_currentFrame; if (m_currentFrame m_endFrame) { // 到达动画末帧根据动画类型决定是否循环 if (m_isLooping) { m_currentFrame m_startFrame; } else { m_isPlaying false; m_currentFrame m_endFrame; // 停在最后一帧 } } } }这里一个隐蔽的坑出现在“动画末帧”和“状态机帧数”的不同步上。如果动画资源只有 12 张帧图但状态机里轻攻击定义为 18 帧逻辑时间那么动画播完最后一帧就会僵住而状态机还有 6 帧没跑完角色会保持出拳姿态原地罚站。源码的解决方案是在StateConfig里让逻辑帧数和动画帧数保持一致的设计约定——推荐你也这么做把动画帧数和状态帧数在配置表里存同一份数据不要让两个数值各写各的。4.2 连击系统输入缓冲与取消窗口双人战斗的“手感”全在这里连击系统是格斗游戏的灵魂也是这份源码里最考究的地方。它的实现分两层输入缓冲和取消窗口。输入缓冲解决的是“玩家出招太快导致系统漏读”的问题——你刚按完轻拳还没等到前一个动作结束又按下重拳如果没有缓冲后者被直接丢弃。源码里用std::dequeInputCommand存储最近 5 帧内玩家的输入一帧只弹出一个命令超龄命令自动过期。// InputBuffer.cpp - 指令缓冲队列最多缓存最近 5 帧的按键 constexpr int MAX_BUFFER_SIZE 5; std::dequeInputCommand m_buffer; void InputBuffer::PushCommand(InputCommand cmd) { // 队列至多保留最近 5 帧的输入防止旧指令积压导致动作堆积 if (m_buffer.size() MAX_BUFFER_SIZE) { m_buffer.pop_front(); } m_buffer.push_back(cmd); } InputCommand InputBuffer::PopCommand() { if (m_buffer.empty()) return InputCommand::NONE; InputCommand cmd m_buffer.front(); m_buffer.pop_front(); return cmd; }取消窗口则定义了“当前动作执行的哪个区间允许被下一个动作打断”。源码给普通攻击预留了后 3 帧作为取消窗口而必杀技的取消窗口放宽到后 8 帧。这个数值直接影响手感取消窗口太短连招收招难新手玩家会很不爽取消窗口太长人人都能无限连游戏就失衡。我见过不少双人战斗源码把窗口设在 5~6 帧作为参考建议你从 4 帧起步慢慢试。另外连击数并不是代码里加个计数器就完事的它需要和 HURT 状态的硬直时间联动——只有当受击方仍处于硬直中且攻击方再次命中时连击数才能累计否则重置为 1。4.3 镜头与舞台边界固定镜头下双人同屏的位移约束怎么处理这份源码选择了固定镜头的实现正视双人同屏的直接难题如果一名角色把另一名角色打到屏幕最左边出屏后玩家看不到自己的角色整个游戏就“瞎”了。代码的处理是在角色移动逻辑里加入“边界软限制”作用于角色位置之前先检查目标位置是否落在stageLeft和stageRight的范围之内超出则把速度直接置零。// PlayerMovement.cpp - 舞台边界限制角色不允许被推出屏幕外 constexpr float STAGE_LEFT 40.0f; constexpr float STAGE_RIGHT 760.0f; // 假设窗口宽 800留出 40px 安全边距 void Player::UpdatePosition(float velocityX, float velocityY) { float newX m_position.x velocityX; float newY m_position.y velocityY; // 边界钳制横向不允许超出舞台范围 if (newX STAGE_LEFT) newX STAGE_LEFT; if (newX m_bodyBox.width STAGE_RIGHT) { newX STAGE_RIGHT - m_bodyBox.width; } m_position.Set(newX, newY); }这里的STAGE_LEFT和STAGE_RIGHT其实只解决了一半问题——双方都在边界内但如果两人同时追击到一个角落处于角落里的角色被连招黏住无法脱身就成了“角落无限连死”的困局。源码里没有处理这个情况我一般会额外加一个“起身无敌帧”机制角色从 DOWN 状态恢复时提供 3~5 帧的免伤并强制将其位移拉向场景中线。这是格斗游戏里的常见防守补救不破坏整体平衡。5. 双人战斗源码避坑十次翻车里最常见的七个问题5.1 现象一角色出拳后突然瞬移到地图另一边这是我在复现这份源码时遇到的第一个“灵异事件”。攻方明明站在原地打拳动画刚播到一半人却闪到了受击方身后。原因源码在更新攻击动画时同时叠加了一段攻击位移值到m_position上。攻击动作本身带突进效果是合理的但位移值是在每一帧都累加而不是在攻击开始时一次性设置。于是攻击的十几帧动画里位移被叠加了十几倍。解决在攻击实例创建时记录一次“发起攻击时的位置基准”攻击位移作用在基准位置上而不是当前累计位置上或者把位移值改为只在攻击动画的前 3 帧生效且每帧重新计算偏移量。5.2 现象二按住攻击键角色像机关枪一样连发玩家按住轻拳不松手角色每 18 帧打一拳毫无停顿地连续出拳动作之间没有衔接看起来就像抽搐。原因输入处理没有做“按下沿触发”只检查了IsPlayerKeyDown的按住状态攻击状态结束后立刻又检测到按键仍被按住于是再次进入攻击状态。解决为每个动作键增加m_keyPressedThisFrame边沿检测只有“从抬起变为按下”的那个瞬时才触发输入命令或者使用 2.2 节提到的输入缓冲队列由队列弹出节奏控制出招。5.3 现象三双人同屏按键互相乱串玩家 1 按攻击键玩家 2 的角色也跟着出拳。原因这套代码没有为两个玩家做独立的输入状态对象而是把两组键位混在一个函数里读有某处GetAsyncKeyState的虚拟键码映射写错或者两个玩家的攻击键都在同一个if块中检测。解决建议把输入读取过程拆成完全独立的两个函数每个函数只读自己绑定的键位数组。最稳妥的做法是定义一个PollPlayerInput(playerId)函数内部只访问m_bindings[playerId]保证两组键位零交叉。5.4 现象四角色下坠穿过地板角色受击倒地后下一帧起身时直接掉到了地面以下再也回不来碰撞检测彻底失效。原因倒地和起身的状态切换过程中有一帧的位置更新没有经过物理碰撞检测——状态机从 DOWN 切换到 IDLE 时直接强制设置了一个姿势位置而这个位置所在的高度没被重力模块重新校验。解决在状态迁移后强制追加一次“位置合法性校验”检查角色的脚底点是否低于地面高度如果低于则主动修正回地面高度。不要依赖碰撞检测来做位置修正碰撞检测只负责“阻止穿透”不负责“拉回地面”。5.5 现象五窗口最小化再恢复后整个游戏像加速了一样狂飙我最初把窗口最小化了一会儿回来发现两个角色已经自己打完了好几局。原因最小化时渲染循环暂停但计时器仍在运行恢复时积累了一个很大的delta值。代码里虽然写了if (delta 0.25f) delta 0.25f;但是逻辑更新用的是固定步长循环仍然会把这 0.25 秒切成 15 帧补跑完。解决将钳制值从 0.25 秒调低到 0.1 秒约 6 帧当窗口失焦或最小化时直接清空累积器不做任何补帧。最干脆的办法是检测到窗口最小化时停止逻辑更新恢复时重新初始化m_lastFrameTime。5.6 现象六双人角色相互重叠物理分离失灵两个角色面对面时直接重叠在了一起身体框形同虚设。原因源码里身体框只做了静态检测没有在角色移动后进行“重叠推开”响应。AABB 相交检测返回结果后代码只是记录了一个“碰撞了”的布尔值没有据此修正位置。解决在移动逻辑之后加入分离轴修正——当身体框相交时沿横向把两名角色向相反方向各推开重叠宽度的一半 1像素的距离。这个 1 像素是为了避免下一帧因为边界紧贴再次被判定为相交而产生抖动。6. 进阶验证把状态机跑在测试框架里不启动窗口也能验证战斗逻辑这份源码最后值得一做的升级就是给状态机写自动化测试让战斗逻辑脱离 Windows 窗口也能被验证。我在复现时采用的方法是把Player类和CombatResolver类的核心逻辑抽到一个不依赖任何 Win32 API 的独立模块中用控制台测试程序直接实例化两个角色模拟按键输入推进帧数然后断言状态和血量的预期值。// test_combat.cpp - 战斗逻辑自动化验证示例 #include cassert #include Player.h #include CombatResolver.h void TestLightPunchCausesHurt() { Player player1(0), player2(1); CombatResolver resolver; // 让玩家1对玩家2发起轻攻击 player1.StartAttack(PlayerState::ATTACK_LIGHT); // 推进 8 帧让攻击进入有效判定帧 for (int i 0; i 8; i) { resolver.ResolveAttackHit(player1, player2); player1.UpdateFrame(); } // 验证受击方进入硬直状态且血量被扣除 assert(player2.GetState() PlayerState::HURT); assert(player2.GetHealth() player1.GetAttackDamage() * 2); std::cout PASS: 轻攻击命中验证通过\n; }这里有个容易忽略的前提被测试的Player类内部调用GetAsyncKeyState的部分必须用开关依赖反转切走否则测试程序一读按键就报错。我一般会定义一个IInputProvider接口游戏运行时用Win32InputProvider实现测试用FakeInputProvider注入预设按键序列。为了便于验证我还会额外加一行调试宏来开启碰撞盒绘制——在渲染循环中用矩形线框把三套碰撞盒画出来观察攻击判定帧和受击框的实际位置是否匹配。别小看这套调试绘制它在你调整攻击判定框大小时是最直观的反馈工具。从那以后我每次拿到新的战斗/格斗类源码都会强制走一遍同样的流程先抽状态机测试、再描碰撞盒、最后跑帧稳定性测试。很多程序上所谓的“手感差”“判定飘”根本不玄学就是这几个数字没对齐而已。这份双人战斗游戏源代码最值得你花时间研究的也正是这套状态机和碰撞盒的组合关系——把这两块读懂后续接 UI、接联网、接新角色都只是时间问题希望帮到你。本文还有配套的精品资源点击获取

C++双人战斗游戏源码拆解：状态机与碰撞盒的实战设计

相关推荐

YOLOv8纸箱检测实战：从模型部署到PyQt界面落地

新消费品牌势能增长：可落地的分析框架与Python实战

如何在不破坏数字签名的情况下更新PDF：LibPDF增量保存深度解析

更多资讯

从源码构建HaleHound-CYD：PlatformIO多环境编译、OTA升级与Python版本陷阱完整指南

Agent基础——HTTP API

基于YOLOv5的猪脸目标检测实战：数据采集、模型训练到TensorRT部署

Python利用支持向量机SVM进行时间序列预测：数据+源码实战

AI Toolbox Skills 技能管理完整教程：从 Git 安装到按工具同步，一键搞定

Postgres主从流复制+pgpool高可用方案：从WAL原理到Failover实操

今日更新

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？