简介：这是一套基于VC++编写的双人对战游戏完整源代码，适合正在学习C++与Windows游戏开发的初学者，也便于开发者快速上手一个结构完整的实战项目。代码已在VC环境下调试通过，可直接编译运行，覆盖了精灵类、输入处理、音效播放、地图加载等核心模块，并设计了20幅不同地图与双人对战机制，有助于理解游戏循环和对象协作方式。压缩包共59个文件、约57KB，包含6个cpp、7个h源码文件，以及15个bmp图片、5个wav音效和20个map地图文件，另附工程配置与readme说明，目录清晰，便于按模块查阅。目前已有406人学习下载，对想通过实例掌握游戏框架、图像渲染和双人交互逻辑的开发者来说，是一份可读、可改、可运行的入门级参考资源。
1. 一套能跑的 VC++ 双人战斗游戏：我先拆了这包源码
两个人挤在同一台电脑前，一个按 W/A/S/D、一个按方向键和小键盘，抢着把对方血条打空——这种双人同屏对战小游戏，正好是学完 C++ 之后最想亲手敲出来的东西。这份源码就是一套完整可编译运行的 VC++ 双人战斗游戏工程：两个角色共用一个 Windows 窗口，角色动画、按键输入、打击判定、血条、KO 结算全部齐活。技术栈非常干净，Win32 窗口加 GDI 双缓冲，不依赖第三方库，工程打开编译完就能看到两个角色在 640x480 的舞台里互怼。适合刚把指针搞明白、想看看游戏主循环长什么样的人，也适合课程设计拿来做骨架改。
2. 架构拆解：从工程目录到一帧执行链路
拿到源码先别急着按 F7，先把目录结构摸清楚。这份工程的设计思路是「入口只负责创建窗口，逻辑全在 GameApp 里转，角色和战斗判定分开」，属于典型的单窗口游戏分层：WinMain 注册窗口类、创建窗口，然后一切交给消息循环和定时器驱动，没有 MFC，也不碰 DirectX，所以老编译器和新编译器都能吃下。
2.1 目录结构与模块划分
工程根目录大概是这样的布局：
FighterProject/ ├── Fighter.sln # VS2008+ 用的工程文件 ├── Fighter.dsw # VC6 用的旧工程文件 ├── src/ │ ├── main.cpp # WinMain 入口、窗口注册、消息循环 │ ├── GameApp.cpp # 游戏循环、定时器、整体渲染调度 │ ├── Player.cpp # 角色状态机、帧动画、受击 │ ├── Battle.cpp # 攻击判定、连击计数、局间结算 │ ├── Sprite.cpp # 位图加载、透明绘制、双缓冲 │ └── Input.cpp # 按键状态表、键位映射 ├── res/ │ ├── bg.bmp # 640x480 舞台背景 │ ├── p1_stand.bmp # P1 站立动作图集 │ ├── p1_punch.bmp # P1 出拳动作图集 │ ├── p2_stand.bmp # P2 站立动作图集 │ ├── p2_kick.bmp # P2 踢腿动作图集 │ └── hit.wav # 命中音效 └── readme.txt # 操作说明、键位表src 里六个文件各管一摊：main.cpp 除了 WinMain 之外基本是空壳，窗口过程函数只有十几行；GameApp 是大脑，持有两个 Player 实例和一个 Battle 实例；Player 不关心对方是谁，它只维护自己的状态、坐标和动画帧；Battle 是裁判，判断谁打中谁，改血量，管连击数。资源单独放 res 目录，位图不用代码动态生成，避免把 500 行的绘制函数堆在逻辑文件里。我一般拿到别人的工程先看这种边界划得清不清楚，这决定后面改代码时会不会牵一发动全身。
2.2 从按键到屏幕：一帧的完整执行链路
这份源码没有用 while(1) 死循环去夯 CPU，而是用 SetTimer 挂了 16ms 的定时器，也就是差不多 62 帧的逻辑刷新率。每收到一次 WM_TIMER，GameApp 就推进一帧，一帧里做的事可以拆成四个阶段：
- 输入快照：从 m_keys 状态表里读 P1、P2 当前按住的键，生成两个 int 位掩码。
- 状态推进：两个 Player 拿到各自的输入意图，自己的状态机决定这一帧是站立、移动还是攻击。
- 战斗结算：Battle 检查攻击方有没有亮判定框，判定框和对手受击框是否相交，命中就扣血、加连击、播音效。
- 渲染输出：背景、两个角色、血条依次画进内存 DC，最后整块 BitBlt 到窗口。
这里有个容易被新手问住的地方：为什么不直接在 WM_TIMER 里画？因为定时器消息的触发频率并不严格，窗口拖动、最小化都会让它丢了节奏，Hardcode 绘制代码会跟逻辑帧耦合。这份源码把「逻辑推进」和「画面输出」都放在同一帧里，但内部是函数分开的，Update(dt) 和 RenderScene() 各干各的，后续想做固定步长逻辑帧时把这两段拆开就能直接套。
2.3 全局参数一览
手感参数全部集中在 GameApp.h 头文件里的宏定义，改数值就能调难度和节奏。这是拆这种小游戏工程最该先看的地方：
| 参数 | 值 | 位置 |
|---|---|---|
| 窗口客户区 | 640 x 480 | main.cpp |
| 逻辑刷新间隔 | 16ms（约 62FPS） | GameApp.cpp |
| 角色移动速度 | 220 像素/秒 | GameApp.h |
| 普通拳伤害 | 10 | Battle.cpp |
| 踢腿伤害 | 16 | Battle.cpp |
| 每局限时 | 60 秒 | Battle.cpp |
| 总血量 | 100 | GameApp.h |
| 动画帧间隔 | 90ms | Player.cpp |
| 攻击判定生效帧 | 第 2~3 帧 | Player.cpp |
三局两胜制，单局限时结束按剩余血量判胜负。这些值全是常量宏，不需要做配置界面，想调难度直接改宏然后重新编译一轮就行。
3. 核心模块拆解：输入、状态机、碰撞判定与渲染
这一章是整个工程最有含金量的部分。格斗游戏和普通平台跳跃游戏最大的区别在于：它必须在极短的时间里处理「多键同时按下」「攻击命中瞬间」「连击窗口」这些时序问题，而这些用 Windows 默认的消息模型直接做会处处踩坑。我按代码执行顺序拆开讲。
3.1 按键输入：用状态表替代消息驱动
第一次看到这套输入代码时我愣了一下——WndProc 里几乎没有业务逻辑，所有按键都被塞进一张 bool 数组：
// Input.cpp —— 按键状态表，P1/P2 键位可随时改 #define KEY_P1_LEFT 'A' #define KEY_P1_RIGHT 'D' #define KEY_P1_UP 'W' #define KEY_P1_PUNCH 'J' #define KEY_P1_KICK 'K' // WndProc 里只做一件事：把消息变成状态 case WM_KEYDOWN: m_keys[wParam] = true; // wParam 是虚拟键码 return 0; case WM_KEYUP: m_keys[wParam] = false; return 0;这里的关键是 m_keys 是一个大小为 256 的 bool 数组，下标直接就是虚拟键码。WM_KEYDOWN 每按下一次只会触发一次，如果直接在消息里写「按下 D 就向右移动」，角色会走一小段就停住，因为系统不会持续发这个消息。状态表解决的就是这个问题：消息只负责把开关拨到位，真正判断移动还是在 GameApp::Update 里通过查表完成。
// GameApp.cpp —— 每帧读取输入意图 void GameApp::CollectInput() { m_p1Intent.Left = m_keys['A']; m_p1Intent.Right = m_keys['D']; m_p1Intent.Punch = m_keys['J']; m_p1Intent.Kick = m_keys['K']; m_p2Intent.Left = m_keys[VK_LEFT]; m_p2Intent.Right = m_keys[VK_RIGHT]; m_p2Intent.Punch = m_keys[VK_NUMPAD1]; m_p2Intent.Kick = m_keys[VK_NUMPAD2]; }说明一下这个输入意图结构体：它不是按键本身，而是「这个玩家当前想干什么」的抽象。P1 和 P2 的键位被硬编码在 Input.cpp 里，但意图字段名是统一的，后面 Player 的状态机完全不关心键位差异。参数 VK_NUMPAD1 和 VK_NUMPAD2 是虚拟键码枚举，笔记本没有小键盘的话，直接把这两个宏改成 VK_L 和 VK_SEMICOLON 就能换到主键区，改完不用动别处。
3.2 角色状态机：把一次攻击拆成六个动画帧
Player 内部维护一个简单的状态机，枚举值包括 ST_IDLE、ST_WALK、ST_PUNCH、ST_KICK、ST_HIT、ST_DOWN、ST_WIN。移动只有两种状态，攻击却单独占了两个——因为格斗游戏里攻击动作是个「有前摇、有判定、有收招」的时序过程，不是按下键立刻出伤害。
// Player.cpp —— 攻击状态的帧推进 void Player::Update(float dt, const InputIntent& intent) { if (m_state == ST_IDLE && (intent.Punch || intent.Kick)) { m_state = intent.Punch ? ST_PUNCH : ST_KICK; m_frame = 0; m_frameTimer = 0; m_atkEnabled = false; } if (m_state == ST_PUNCH || m_state == ST_KICK) { m_frameTimer += dt; if (m_frameTimer >= 90) { // 每帧动画持续 90ms m_frameTimer = 0; m_frame++; } m_atkEnabled = (m_frame >= 2 && m_frame <= 3); // 判定窗 if (m_frame >= 6) { // 动作共 6 帧 BackToIdle(); m_frame = 0; } } }这段代码是整套对战的命脉。m_frameTimer 累加超过 90ms 才推进一个动画帧，也就是代表一张位图；m_atkEnabled 在动画的第 2 帧到第 3 帧之间置 true，这之后角色虽然还在挥拳动画里，但已经没有判定了，剩下的帧是纯粹给玩家看的「收招硬直」。这样做有两个意义：第一，玩家不能靠高频连按让每一次点击都变成一次判定，攻击动画期间输入会被忽略；第二，动画结束时 m_frame 归零回到待机，整个时序是自洽的，不会出现「动画播完了状态还在攻击」的幽灵判定。
这里有个手感细节值得说：dt 参数是上一次更新到这次的毫秒差，用它累加计时而不是直接m_frame++是为了让动画速率和帧率解耦，不会因为窗口卡顿导致动画变速。
3.3 打击判定：矩形相交与连击窗口
判定逻辑全部集中在 Battle.cpp，核心函数只有不到二十行：
// Battle.cpp —— 判定一次攻击是否命中 bool Battle::CheckHit(Player* attacker, Player* defender, int& combo) { if (!attacker->IsAttackFrameActive()) return false; // 只有亮框帧才判定 RECT atk = attacker->GetAttackRect(); RECT def = defender->GetBodyRect(); RECT hit; if (IntersectRect(&hit, &atk, &def)) { int dmg = attacker->GetKickFlag() ? 16 : 10; defender->TakeHit(dmg); combo++; // 连击计数 +1 attacker->OnHitSuccess(); // 命中后强制收招，避免一帧多判 return true; } return false; }IntersectRect 是 GDI 自带的矩形求交函数，两个矩形只要有一点重叠就返回非零。GetAttackRect 的关键在于它内部根据角色朝向和当前攻击类型返回一个「往前伸出去」的矩形：出拳时判定框约 60x40，踢腿时约 80x40，方向不同矩形偏移正负号不同。GetBodyRect 是角色躯干所占的区域，比实际位图略小一圈，实战中不容易出现「擦到袖子也算被打中」的体感偏差。
连击窗口由 Battle 层的 comboTimer 管理，只要两次攻击命中间隔不超过 500ms，combo 就一直往上加，超过就清零重置。需要注意 OnHitSuccess 这个函数——它是防止同一帧里出现多次判定的保险：命中后攻击方立刻退出判定帧，再调用 Update 时状态已经进入收招，不会对同一个对手重复算一次伤害。
快速移动时可能会有判定穿越：角色位移速度太快，上一帧和这一帧的矩形之间留出了空隙，直接漏掉了一次本该命中的碰撞。常见做法是拿上一帧和当前帧的矩形求并集，再和对手受击框相交：
// Battle.cpp —— 扫掠检测，防止高速移动穿过判定 RECT sweep; UnionRect(&sweep, &prevRect, &atk); // 合并两帧的矩形 if (IntersectRect(&hit, &sweep, &def)) { // 视为命中 }这个兜底方案不常用到，但一旦角色加了冲刺技能，它就能避免敌人被「穿过去」，属于提前埋好的扩展点。
3.4 双缓冲渲染：解决残影与闪烁
绘制函数集中在 GameApp::RenderScene，双缓冲的骨架代码很典型：
// GameApp.cpp —— 双缓冲渲染一帧 void GameApp::RenderScene() { PAINTSTRUCT ps; HDC hdc = BeginPaint(m_hwnd, &ps); HDC memDC = CreateCompatibleDC(hdc); HBITMAP memBmp = CreateCompatibleBitmap(hdc, 640, 480); HBITMAP oldBmp = (HBITMAP)SelectObject(memDC, memBmp); // 按 Z 序画：背景 → 角色 → 血条 UI DrawBackground(memDC); m_p1.Draw(memDC, true); m_p2.Draw(memDC, false); DrawHUD(memDC); // 整块拷贝到窗口，瞬间呈现 BitBlt(hdc, 0, 0, 640, 480, memDC, 0, 0, SRCCOPY); SelectObject(memDC, oldBmp); DeleteObject(memBmp); DeleteDC(memDC); EndPaint(m_hwnd, &ps); }直接在窗口 DC 上逐张画位图，每画一张都会被用户看到一次，画面闪烁是必然的。双缓冲的思路是先所有内容画进一块内存位图，再把整块结果一次性 BitBlt 到窗口，屏幕上只出现一次完整帧。CreateCompatibleBitmap 创建的位图与窗口 DC 的颜色格式一致，不会出现颜色偏差。注意位图尺寸 640x480 必须和窗口客户区一致，否则输出会被拉伸或者裁切。
这里还有个小坑：角色位图本身是带透明底的，Sprite 绘制时用了两次 BitBlt 的透明方案——先用 AND 把目标区域涂成黑色，再用 OR 把非透明像素叠上去。这比 TransparentBlt 更稳，老编译器不需要额外链接 msimg32.lib。
4. 编译与运行：把这包代码在你机器上跑起来
玩这套工程的正确姿势是：VC6 装老机器上直接开干，新机器用 VS2008 或 VS2010 打开也基本无损。源码没有用任何 MFC 类，也没有依赖 DirectX SDK，全部是 Win32 API 和 GDI，所以现代 Windows 上编译不会有一堆红色波浪线。
4.1 环境选择：VC6 与新版 VS 的取舍
VC6 对应的是 .dsw 工程文件，双击直接打开，按 F7 编译，F5 运行，一条路走通。但 VC6 的编译器至今快 30 年了，对 Windows 新版本的内核有些水土不服，如果编译时报一堆 SDK 头文件冲突，就换 VS2008 以上版本。
新版 VS 打开 .sln 时会弹「工程转换」向导，转一遍就行。转换之后主要检查两点：字符集是否设置为「使用多字节字符集」（工程里用了 TCHAR 和 _T 宏，Unicode 下也能跑，但位图路径拼接最好统一）；链接器里是否有 winmm.lib。这一步做完，代码基本不用改。
4.2 编译步骤与工程设置
我习惯按下面这个顺序走，每一步都留个心眼：
- 用 VS 打开解决方案，确认活动配置是 Win32 Debug。
- 在工程属性里找到「调试 → 工作目录」，设为
$(ProjectDir)，保证资源相对路径有效。 - 直接生成解决方案，输出应该零错误零警告。
- 运行后等窗口出来，按 J/K 和方向键测试。
工作目录是最容易翻车的点。LoadImage 加载位图用的是相对路径，而 VS 默认的工作目录可能指向解决方案目录之外的地方。这位源码里写的是相对res\\路径，所以工作目录设错了就会出现「窗口能开、角色全透明」的画面。
音效加载同理，PlaySound 同样是相对路径：
#pragma comment(lib, "winmm.lib") // PlaySound 对应的库 void PlayHitSound() { PlaySound(_T("res\\hit.wav"), NULL, SND_FILENAME | SND_ASYNC); }SND_FILENAME 表示第一个参数是文件名，SND_ASYNC 表示异步播放、不阻塞游戏逻辑。注意 PlaySound 要求文件路径存在，加载失败时它只是静默返回，排查时可以先用绝对路径测试，确认声音文件没问题再改回相对路径。
4.3 键位调整与资源路径
默认键位表按「P1 在左、P2 在右」设计，两人共用一块键盘：
| 玩家 | 移动 | 上 | 拳 | 踢 |
|---|---|---|---|---|
| P1 | A / D | W | J | K |
| P2 | ← / → | ↑ | 小键盘 1 | 小键盘 2 |
改键位只动 Input.cpp 顶部那几个宏。比如把 P2 的拳从 VK_NUMPAD1 改成 VK_RSHIFT，替换后重新编译即可。图片素材是 24 位 BMP，横排连续帧图集——一张 p1_punch.bmp 里横着放了 6 个等宽的角色帧，Sprite 加载后按 frame 下标用 StretchBlt 裁切绘制。如果你想替换成自己的素材，保持帧宽等分、背景用纯黄（RGB 255,255,0）做透明色就行，透明色常量在 Sprite.cpp 顶部有定义。
5. 避坑清单：编译、按键、判定三类翻车现场
5.1 角色原地抽搐，按住方向键却不往前走
现象：按住 D 想让 P1 向右走，角色却站在原地抖动画帧，松开瞬间又往前蹿一截。
原因：如果直接在 WM_KEYDOWN 里写「按 D 就移动」，Windows 的键盘自动重复会让 WM_KEYDOWN 以几十毫秒的间隔反复触发，每触发一次都把角色重置到第 0 帧，看起来就是抽搐。松开时 WM_KEYUP 到达，位移又叠加了一次。
解决：用第 3.1 小节的按键状态表，消息只改 bool 值，移动逻辑在 Update 里每帧查表。这样按住方向键就是连续走，重复消息根本进不了逻辑层。
5.2 画面满屏闪烁，窗口拖一下就残影
现象：运行后角色动作能看到明显的闪烁，窗口拖动时出现横向撕裂。
原因：直接在窗口 DC 上绘制，每画一张位图都暴露给屏幕一次。GDI 没有硬件同步，画面刷新节奏对不上就闪。
解决：用双缓冲，所有内容画进内存 DC，最后一次性 BitBlt。另外把 WM_ERASEBKGND 消息的返回值设为 TRUE，禁止系统额外擦除背景，能减少一层闪烁。
5.3 出拳贴脸却没伤害，判定框像假的一样
现象：两个角色站得很近，P1 出拳动画正常播放，但 P2 不掉血，连击数也不涨。
原因：攻击判定只在第 2~3 帧亮框，如果角色快速移动导致这两帧恰好错开对手身体矩形，判定就会落空。
解决：先确认 IsAttackFrameActive 在正确帧段返回 true，再把 GetAttackRect 稍微放大，或者用扫掠矩形合并上一帧当前位置。更粗暴的办法是把判定帧区间从 2~3 扩大到 2~4，让命中窗口更宽容。
5.4 编译报链接错误，PlaySound 符号无法解析
现象：链接阶段报 LNK2019，提示 PlaySound 无法解析的外部符号。
原因：PlaySound 属于 winmm.lib，默认工程没有链接这个库。
解决：工程属性里链接器附加依赖项添加 winmm.lib，或者在源文件顶部加#pragma comment(lib, "winmm.lib")。前者改工程，后者随代码走，推荐后者，换环境编译不用再配一次。
5.5 中文输入法抢键盘，出招变成打拼音
现象：切换过中文输入法之后，按 J、K 弹输入框，游戏无论如何收不到按键。
原因：输入法在焦点窗口上拦截了键盘消息，虚拟键码被 IME 吃掉，游戏窗口收不到 WM_KEYDOWN。
解决：窗口初始化时取消输入法关联，调用ImmAssociateContext(m_hwnd, NULL)，或者干脆用 GetAsyncKeyState 直接查物理键状态。这套源码选的是前者——一行代码，从根上杜绝输入法抢键。
6. 二次开发：加招式、调手感
6.1 加一个新动作
想给角色加上勾拳，改动点刚好分布在四个文件里。第一步在 Player.h 的枚举里加 ST_UPPERCUT；第二步准备一张 7 帧连拍图集放进 res 并加载；第三步在 Update 的状态机里补分支：
case ST_UPPERCUT: m_frameTimer += dt; if (m_frameTimer >= 90) { m_frameTimer = 0; m_frame++; } m_atkEnabled = (m_frame >= 2 && m_frame <= 4); if (m_frame >= 7) { m_state = ST_IDLE; m_frame = 0; } break;第四步在 Input 意图里新增按键，把它映射到出招条件。整个流程走完一次，你就掌握了这套源码的扩展节奏：枚举加状态、图集加帧、状态机加分支、判定框调区域，四个地方对齐就能出道新招式。
6.2 打击感微调
手感是格斗游戏的灵魂，这份源码里影响手感的核心参数是动画帧间隔和判定帧区间。默认出拳节奏是前摇 2 帧、判定 2 帧、收招 2 帧，加起来 6 帧共 540ms。想让攻击更「快」可以缩前摇：把条件改成m_frame >= 1 && m_frame <= 2，出拳反应时间直接少 90ms。想让打击更有「重量感」，在 Battle::CheckHit 命中分支里加一个短暂停顿：
defender->TakeHit(dmg); combo++; m_hitStopFrames = 4; // 命中后双方逻辑暂停 4 帧，约 64ms这个 hit-stop 机制是格斗游戏打击感的常见做法，命中瞬间让画面冻结几十毫秒再继续播放动画，玩家会明显觉得这一拳「打实了」。调的时候注意不要超过 6 帧，否则连招衔接会显得卡顿。
现在每次拿到这类键盘输入项目，我都会先画一张按键状态表、把逻辑帧固定下来，再动手写攻击判定，先跑通再谈手感。做过这套双人战斗工程之后，这个习惯帮我少走了不少弯路，希望帮到你。
本文还有配套的精品资源，点击获取
