VC++双人战斗游戏源代码拆解：工程升级、输入与判定

简介：这是一份基于VC++开发的双人对战游戏完整源代码，面向具备C++基础、希望了解Windows游戏项目结构与实现细节的学习者。代码已在VC环境中调试通过，包含玩家控制、战斗判定、地图切换与音效播放等模块，适合用来拆解类设计、对象创建、事件处理及图形渲染流程。压缩包共59个文件，约57KB，以cpp与h源码文件为核心，配合20个map关卡地图、15个bmp位图素材、5个wav音效以及dsp工程和rc资源脚本，构成可编译运行的小型游戏项目。已有407人学习，说明其在入门级游戏开发练习中具有一定参考价值。读者可从中获得完整的双人对战逻辑、多关卡地图组织方式和资源加载思路，对照源码理解游戏循环、碰撞检测与输入响应，并可在现有工程上修改地图、素材或规则，作为C++课程设计和小型游戏实践的基础样例。

1. 双人战斗游戏源代码：一份 VC++ 工程拆开后的真实分量

两个人挤在同一台机器前，一个用 A、D、W、S 加 F、G，另一个用方向键加小键盘，谁的血条先空谁下场。这个场景在任何现代引擎里都属于入门作业，但一份 VC++ 写的双人战斗游戏源代码能给你的东西完全不同：窗口创建、消息循环、贴图、帧动画、判定、血量结算，全都直接摊在明面上，没有引擎在背后帮你处理。它适合两类人：想搞清楚 2D 格斗游戏底层时序和判定到底怎么落地的，以及手上有一堆老 VC 工程要维护、需要一个完整样本照着对照的。下面按「能跑起来、能改得动、能调得准」的顺序拆。

2. 把 VC++ 工程跑起来：从 dsp 到 sln 的升级与四个必改属性

拿到压缩包解压，第一件事不是双击 sln，而是先看工程文件的年代。这一步判断错了，后面两小时的报错都会白费。这类双人战斗游戏源代码流传时间长，工程文件可能是 VC6 的 dsp/dsw，也可能是某个中间版本的 sln/vcxproj，两者在新 IDE 里的处理路径完全不同。

2.1 先认年代：dsp/dsw 与 sln/vcxproj 差的不是后缀

dsp 是 VC6 时代的工程格式，配套的是 MFC 4.2 和单字节字符集；vcxproj 是 MSBuild 体系，从 VS2002 之后逐步定型。用新版 IDE 直接打开 dsp，会弹升级向导，向导能把大部分配置翻译过去，但翻译不完整的地方正好是要命的地方：预处理器定义、附加依赖库、输出目录、资源编译器路径。

判断方法很直接：看目录里有没有.dsw。有 dsw，说明是从 VC6 一路传下来的，基本可以断定源码里到处是char*和sprintf，字符集按多字节处理；没有 dsw 只有 sln，相对省事，但仍要确认平台工具集是不是还指向一个本机没装的版本。

我一般的处理顺序是：先把整个目录复制一份留底，再在副本上升级。老工程一旦被新版 IDE 改过工程文件，想退回原状很麻烦，留一份原样的是最便宜的回退方案。

2.2 升级向导不管的四处工程属性

向导点完「完成」不等于能编译。下面四处必须手工过一遍，缺一处就大概率卡在链接或者运行期。

第一是字符集。VS2015 之后，MFC 的多字节字符集支持变成可选组件，安装时没勾选的话，工程属性里根本选不到「使用多字节字符集」，表现是一堆C2664、C2440，全是CString和const char*转不过去。解决方式是回到安装器补装「用于 MFC 的 MBCS 支持」，不要试图靠改代码逐个加_T()绕过去，那样改到最后会得到一份宽窄字符混用的四不像。

第二是平台工具集和 Windows SDK 版本。工程属性 → 常规 → 平台工具集，选本机装了的那个；SDK 版本选「最新安装的版本」，别锁死某个具体号。

第三是链接器的附加依赖。这类工程常用两个库：winmm.lib（timeGetTime、timeBeginPeriod、PlaySound）和msimg32.lib（TransparentBlt、AlphaBlend）。前者管计时，后者管透明贴图，漏一个就是LNK2019未解析的外部符号。

第四是输出目录和调试工作目录。默认输出在Debug/或x64/Debug/，而资源目录是相对路径，直接从 IDE 启动时工作目录是工程目录，双击 exe 启动时工作目录是 exe 所在目录，两者相差一层，图片就全加载不到。调试 → 工作目录，统一设成$(ProjectDir)，测试双击运行时再把资源一起拷到输出目录。

改完先别开 IDE，用命令行编一遍，报错信息比 IDE 的输出窗口干净：

# 在 VS 的开发人员命令提示符里执行，路径按自己解压位置改 cd /d D:\work\fight2p msbuild Game.sln /p:Configuration=Debug /p:Platform=Win32 /v:m /nologo

/p:Platform=Win32不能省。很多老工程只有 Win32 配置，用默认的 Any CPU 或者 x64 会直接提示找不到配置。/v:m是精简输出，真正需要看细节时改成/v:n。编译通过再看警告，C4996（fopen、sprintf、strcpy被标记为不安全）可以暂时用_CRT_SECURE_NO_WARNINGS压掉，但C4244（截断）和C4101（未使用变量）建议一条条看，老工程里的数值截断经常就是后面判定错位的根源。

2.3 第一次运行：窗口起来了但画面全黑，按这个顺序查

最典型的场景是：编译零错误，双击运行，窗口出来了，标题栏正常，客户区一片黑或者一片灰，程序不崩，键盘也没反应。这不是代码逻辑的问题，九成在资源加载。

按这个顺序查，基本一次定位：

先确认资源到底在不在。解压后的目录里应该有 bmp 或者 png，看它们相对于 exe 的位置；再看代码里加载路径是硬编码的绝对路径（D:\...）还是相对路径。硬编码绝对路径是老工程最常见的坑，换台机器就废。

再确认加载函数的返回值有没有被检查。很多示例代码是LoadBitmap或者LoadImage直接甩给CDC::SelectObject，失败了也不报，选进去的是空句柄，画出来就是一片背景色。把返回值打出来，GetLastError会告诉你是路径不对还是文件格式不对。

// 加载失败必须有声音，否则就是一片黑屏让你猜 HBITMAP LoadBmpChecked(LPCTSTR path) { HBITMAP h = (HBITMAP)::LoadImage(NULL, path, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION); if (h == NULL) { // 常见错误码：2=找不到文件，87=参数错（多半是文件不是标准 bmp） TRACE(_T("[res] load failed: %s, err=%lu\n"), path, ::GetLastError()); } return h; }

LR_LOADFROMFILE表示从磁盘文件加载而不是从资源段，LR_CREATEDIBSECTION保证拿到的是 DIB 而不是设备相关位图，后面做透明色处理时必须有它。IMAGE_BITMAP加上宽高传 0，表示按文件自带尺寸加载。

如果资源正常、加载也成功，画面还是不刷新，那就去看OnPaint和OnTimer有没有真的被调用。加一行TRACE或者直接OutputDebugString，用调试器挂上去看输出窗口。定时器没起来最常见的原因是SetTimer的返回值没检查，ID 冲突导致第二次设置直接失败，游戏逻辑一步都不走。

3. 主循环与双人输入：定时器精度、消息泵和同时按下的三个键

格斗游戏的手感，一半在帧数据，另一半在输入采样。这两个东西在这类老工程里通常都是最粗糙的实现：SetTimer按 30ms 或 50ms 触发一次，OnKeyDown里改一个布尔值。单人对战勉强能玩，一上双人、一上连招，立刻暴露问题。

3.1 SetTimer 驱动与固定步长：为什么不能直接在 OnTimer 里写逻辑

SetTimer的精度受系统时钟粒度限制，默认最小间隔大约 15.6ms，实际触发还会被消息队列里的其他消息挤后。直接把游戏逻辑写在OnTimer里，意味着逻辑步长是「不定长」的：系统忙的时候一帧 40ms，闲的时候 16ms，角色移动速度跟着抖动，动画播放忽快忽慢。

更麻烦的是调试。断点停两秒再继续，OnTimer会攒一堆消息一次性灌进来，角色瞬移一大段。这个现象在开发期几乎每个新人都会遇到一次，然后怀疑自己写错了移动公式。

正确做法是把「定时器触发」和「逻辑步进」分开：定时器只负责唤醒，醒来后用timeGetTime算真实经过的毫秒数，累加到一个累加器里，按固定步长（比如 16ms 一格）消费掉，剩下的留到下次。

// 固定步长：定时器只负责唤醒，逻辑按 16ms 一格补，掉帧也不会让动画变慢 static DWORD s_lastTick = 0; static int s_accumMs = 0; const int kStepMs = 16; // 逻辑帧率 1000/16 ≈ 62Hz，想跑 30Hz 就改成 33 void CGameView::OnTimer(UINT_PTR nIDEvent) { DWORD now = timeGetTime(); if (s_lastTick == 0) s_lastTick = now; s_accumMs += (int)(now - s_lastTick); s_lastTick = now; if (s_accumMs > 200) s_accumMs = 200; // 断点或切窗口回来会攒一大坨，必须钳住 while (s_accumMs >= kStepMs) { StepLogic(kStepMs); // 输入采样、状态机、判定、结算都在这里 s_accumMs -= kStepMs; } Invalidate(FALSE); // 只标脏，真正的绘制放到 OnPaint }

三个参数要理解清楚。kStepMs是逻辑帧长，它决定所有帧数据的单位，改它等于改整个游戏的节奏，后期不要随便动。s_accumMs > 200这个上限是必须加的限制，作用是把「暂停后一次性补几百帧」变成「最多补 12 帧」，否则从断点回来角色会直接飞到屏幕外。Invalidate(FALSE)传FALSE表示不擦背景，配合双缓冲才能不闪。

另外，如果工程里用了timeGetTime，启动时最好调一次timeBeginPeriod(1)，把系统定时器分辨率提到 1ms，退出时timeEndPeriod(1)还原。不调也能跑，但 60Hz 的逻辑配上 15.6ms 的唤醒粒度，抖动肉眼可见。

3.2 双人同屏按键：WM_KEYDOWN 的问题与 GetAsyncKeyState 的取舍

单人游戏用WM_KEYDOWN/WM_KEYUP完全够，双人立刻不行。原因有三个：

一是自动重复。按住一个键不放，Windows 会持续发WM_KEYDOWN，lParam第 30 位标记这是重复消息。如果不判断这一位，按住方向键会变成每秒触发几十次「开始移动」。

二是同时按键的语义。两个玩家同时按下各自的攻击键，消息队列里会有两条WM_KEYDOWN，顺序有先后。如果逻辑是「收到攻击消息就立刻结算一次伤害」，那么这一帧里会结算两次，两个人同时掉血，判定就变成了先按先赢。

三是焦点与硬件。窗口失去焦点后消息不再进来，但玩家可能还按着键，回来时状态错位；普通薄膜键盘还有鬼键问题，某些三键组合在硬件层就被吞掉了，代码救不回来。

常见做法是放弃消息驱动，改成每逻辑帧轮询一次键盘状态，用位掩码存：

struct KeyMap { int vk; unsigned bit; }; static const KeyMap kP1Keys[] = { { 'A', 0x01 }, { 'D', 0x02 }, { 'W', 0x04 }, { 'S', 0x08 }, { 'F', 0x10 }, { 'G', 0x20 }, // 轻攻击 / 重攻击 }; static const KeyMap kP2Keys[] = { { VK_LEFT, 0x01 }, { VK_RIGHT, 0x02 }, { VK_UP, 0x04 }, { VK_DOWN, 0x08 }, { VK_NUMPAD0, 0x10 }, { VK_NUMPAD1, 0x20 }, }; unsigned SampleKeys(const KeyMap* map, int n) { unsigned mask = 0; for (int i = 0; i < n; ++i) if (::GetAsyncKeyState(map[i].vk) & 0x8000) // 只认最高位：当前是否按住 mask |= map[i].bit; return mask; } // 每个逻辑帧调一次：cur 是本帧掩码，prev 是上一帧掩码 unsigned pressed = cur & ~prev; // 上升沿：这一帧刚按下，用于触发一次性出招 prev = cur;

GetAsyncKeyState返回short，最高位0x8000表示当前物理按下，这是唯一可靠的位；最低位0x0001在文档里表示「自上次调用以来按下过」，但在现代系统上行为并不稳定，不要依赖它做边沿检测，自己存prev更稳。

pressed = cur & ~prev这一行是整个输入系统的核心：按住不放只有第一帧算「按下」，之后都算「保持」。移动用cur判断，出招用pressed判断，两者分开，才能做出「按住防御 + 单次按下攻击」这种组合。

一个必须补的判断：GetAsyncKeyState是全局键盘状态，窗口在后台也会返回真实按键。在SampleKeys之前加一句if (::GetForegroundWindow() != m_hWnd) return 0;，否则切出去回个消息，回来发现角色已经走到墙角了。

3.3 从按键到动作：映射表、优先级和输入缓冲

拿到掩码之后不能直接if (mask & 0x10) Attack();，那样写出来的东西没法扩展。做法是中间加一层映射表，把「方向 + 按键」翻译成动作 ID。

优先级的作用是解决同帧多输入冲突：同一逻辑帧里既满足「前 + 轻」又满足「同时轻重」，取优先级高的那个，不要两条都执行。

输入缓冲是另一个容易被忽略的细节。玩家在受击硬直结束前 3～4 帧按下的攻击，如果直接丢弃，玩起来会觉得「我明明按了」。做法是维护一个最近 N 帧的输入队列，状态机切回可行动状态的瞬间，去队列里找最近一次未被消费的攻击输入，找到就执行。缓冲窗口给 4 帧左右，太大就变成误触，太小等于没有。

// 输入缓冲：只存最近 6 帧，状态机可行动时再消费，避免"我明明按了"的挫败感 struct InputBuffer { unsigned hist[6] = {0}; int head = 0; void Push(unsigned pressedMask) { hist[head] = pressedMask; head = (head + 1) % 6; } // 从最近往最老找，找到就清掉，保证一次输入只触发一次 unsigned ConsumeRecent(unsigned wantMask) { for (int i = 1; i <= 6; ++i) { int idx = (head - i + 6) % 6; if (hist[idx] & wantMask) { hist[idx] &= ~wantMask; return wantMask; } } return 0; } };

head指向下一个写入位置，(head - i + 6) % 6往回走，i = 1是最近一帧。消费后按位取反清掉，防止同一输入被连续消费两帧。这套东西二十行代码，对手感的提升比调十个伤害数值都明显。

4. 帧动画与判定框：状态机、活动帧与「打中了」的严格定义

资源和输入通了之后，剩下的就是这类游戏真正的核心：一帧一帧地决定谁打到谁。老工程在这块通常写得很随意——角色位置用一个CPoint，判断打中用两个矩形相交，相交就掉血。单人打木桩看不出问题，双人对战立刻乱套：一次挥拳扣三段血、两个人同时出招互相穿过、被打的人血条见底还在原地站着。

4.1 帧序列的三种组织方式

先把动画数据组织好，后面才好谈判定。

流传的这类工程大多用第一种，因为最容易手工拼。实际改造时我倾向于往第三种迁移：动作数量一多，第一种方案的「等宽等高」约束会让美术很难受，而且每加一个动作就多一张位图句柄，GDI 对象数上去之后容易触发上限。

透明贴图用TransparentBlt，把位图里的品红或者纯黑当透明色。要注意它只能处理单一颜色透明，边缘会有锯齿；想要好一点的边缘就得用 32 位带 alpha 的位图配AlphaBlend，代价是老工程里的位图多半是 24 位，得先转一遍。

4.2 状态机的最小实现

状态不需要多，六个够用：待机、行走、攻击、受击、硬直、倒地。关键不是状态数量，而是每个状态必须明确三件事——播到第几帧、这一帧停了多久、什么时候可以被别的状态打断。

enum class ActorState { Idle, Walk, Attack, Hit, Stun, Down }; struct FrameDesc { // 帧数据表的行，后面所有调整都在这上面做 int left, top, w, h; // 在图集里的矩形 int holdMs; // 这一帧停留多久，60Hz 下 16ms 约等于 1 帧 RECT hitBox; // 攻击判定框，相对角色左上角 RECT hurtBox; // 受击框 bool active; // 这一帧是否开判定 }; void UpdateActor(Actor& a, int elapsedMs) { if (a.state == ActorState::Stun) { // 硬直只倒计时，不接受输入 a.stunMs -= elapsedMs; if (a.stunMs <= 0) a.state = ActorState::Idle; return; } a.frameTimer += elapsedMs; const FrameDesc& f = a.frames[a.frameIndex]; if (a.frameTimer >= f.holdMs) { // 用 while 而不是 if，掉帧时不会卡动画 a.frameTimer -= f.holdMs; if (++a.frameIndex >= a.frameCount) { a.frameIndex = 0; a.OnAnimationEnd(); // 攻击动画放完在这里切回 Idle } } }

holdMs是帧数据的基本单位，60Hz 逻辑下一帧约 16ms，一个 6 帧的前摇就是 96ms。用毫秒而不是帧计数，好处是将来换逻辑帧率时数据不用重算，坏处是容易出现除不尽的余数，所以换帧那里必须用while配合减法，不能用if加归零。

OnAnimationEnd是状态机的收口。攻击动作播完自动回待机、受击动作播完自动回待机、倒地动作播完进入起身无敌，这些转移全放在这一个回调里，比在UpdateActor里塞一堆if (a.state == ...)好维护得多。

4.3 判定框与前摇后摇：RECT 相交根本不等于打中

这是整份代码里最容易写错的一处。正确的判定要同时满足四个条件：

第一，只在活动帧开判定。攻击动画 12 帧，真正能打到人的可能只有第 5 到第 7 帧，其余帧active都是false。前摇给对手反应时间，后摇给对手惩罚机会，这两个窗口就是格斗游戏的节奏来源。

第二，一次攻击只结算一次。活动帧有 3 帧，如果每帧都做相交检测，一次挥拳会扣三次血。必须有一个hasHitThisAttack标志，出招时清零，结算后置位，动画播完再清。

第三，受击方要有无敌帧。倒地起身、受击硬直刚结束的几帧，如果不禁判定，会被无限连。

第四，推挤框和受击框分开。两个角色走路撞在一起不能穿模，靠的是推挤框；能不能被打到，看的是受击框。很多老工程把这两者合成一个矩形，结果就是「贴身站着打不到人」或者「隔着一个身位被打飞」。

// 判定只在 active 帧打开，且一次攻击只结算一次 bool TryHit(const Actor& atk, Actor& def) { const FrameDesc& f = atk.frames[atk.frameIndex]; if (!f.active || atk.hasHitThisAttack) return false; if (def.state == ActorState::Down || def.invincibleFrames > 0) return false; RECT a = OffsetRectCopy(f.hitBox, atk.x, atk.y); RECT b = OffsetRectCopy(def.frames[def.frameIndex].hurtBox, def.x, def.y); RECT tmp; if (!::IntersectRect(&tmp, &a, &b)) return false; atk.hasHitThisAttack = true; // 少了这行，一次挥拳能扣掉对方半管血 def.hp -= atk.attackDamage; def.state = ActorState::Hit; def.stunMs = atk.hitStunMs; def.vx = atk.facing * atk.knockback; // 击退方向跟朝向走，不跟按键方向走 return true; }

OffsetRectCopy是把相对坐标转成屏幕坐标的小工具，判定框在数据表里存的是相对角色左上角的偏移，这样同一个动作左右朝向都能复用，翻转时只需要把hitBox.left/right相对角色宽度镜像一下。

def.vx = atk.facing * atk.knockback这一行值得单独说。击退方向必须由攻击方的朝向决定，不能由受击方当前按的方向决定，否则会出现「被打的人往后按，结果往前飞」的问题。facing用 +1/-1 表示。

5. 避坑与排查：编译、GDI 泄漏与打不着人的五条记录

这一节的五条都是我在不同机器、不同版本 IDE 上真实碰到过的，按出现频率排序。

5.1 编译与链接：两个能耗掉一上午的坑

现象：链接阶段报LNK2005: xxx 已经在 mfc42.lib 中定义，或者反过来一堆LNK2019找不到_main、_WinMain@16。

原因：运行库配置不一致。工程里一部分文件按/MT（静态链接 CRT）编译，一部分按/MD（动态链接），或者 MFC 用了静态库而 CRT 用了动态库。老工程被多人改过之后，这种不一致非常常见。

解决：项目属性 → C/C++ → 代码生成 → 运行库，全部统一成/MDd（调试）和/MD（发布）；同时在常规页确认「使用 MFC」是「在共享 DLL 中使用 MFC」还是「在静态库中使用 MFC」，两者必须和运行库配套。最省事的判断方法是看报错里出现的是mfc42.lib还是mfc42d.lib，带 d 的是调试版，混用就报重复定义。

现象：error C2664: 无法将参数 1 从 const char[12] 转换为 LPCTSTR，或者CString转const char*报错，一次几十条。

原因：工程被设成了 Unicode 字符集，而源码里全是窄字符串字面量。VC6 时代默认多字节，升级过程中向导可能把字符集改成了 Unicode。

解决：优先改回多字节（项目属性 → 高级 → 字符集 → 使用多字节字符集），前提是安装时勾了 MFC 的 MBCS 组件。如果环境不允许，那就得系统性改造：所有字面量加_T()，所有sprintf换_stprintf，所有strcpy换_tcscpy。这种事不要零散改，改一半的工程比不改更难维护。

5.2 运行期：闪烁和 GDI 对象数

现象：画面剧烈闪烁，尤其是角色移动或者背景有动画的时候；把窗口拖到屏幕外再拖回来，闪烁更明显。

原因：所有绘制直接画在窗口 DC 上，每一帧先擦背景再画内容，擦和画之间被系统合成了一次，人眼就看到白闪。

解决：双缓冲。建一个内存 DC 和一张兼容位图，所有绘制先落到内存 DC，最后一次性BitBlt到屏幕。

void CGameView::OnDraw(CDC* pDC) { CRect rc; GetClientRect(&rc); CDC mem; mem.CreateCompatibleDC(pDC); CBitmap bmp; bmp.CreateCompatibleBitmap(pDC, rc.Width(), rc.Height()); CBitmap* pOld = mem.SelectObject(&bmp); // 必须保存旧对象，后面要还回去 DrawBackground(&mem); // 背景、角色、血条全往 mem 上画 DrawActors(&mem); DrawHud(&mem); pDC->BitBlt(0, 0, rc.Width(), rc.Height(), &mem, 0, 0, SRCCOPY); mem.SelectObject(pOld); // 顺序别反：先还原再析构 }

这段代码每帧创建一次内存 DC 和位图，严格说是浪费的，正确做法是把mem和bmp做成成员变量，在OnSize里重建。但先跑通再优化，一开始就上缓存反而容易在窗口尺寸变化时崩。

现象：程序跑十几分钟之后开始卡顿，任务管理器里进程的 GDI 对象数一路涨到几千。

原因：CreateCompatibleBitmap、CreatePen、CreateFont这些创建的 GDI 对象没有DeleteObject。每个进程的 GDI 对象默认上限是一万个，到顶之后所有绘制调用全部失败，表现为界面一片白。

解决：凡是Create*出来的句柄都要配对释放，SelectObject换下来的旧对象也要还原。检测方法很直接：任务管理器 → 详细信息 → 右键列标题 → 添加「GDI 对象」，跑起来盯着这个数字，正常情况下应该稳定在一个小数值，一直涨就是漏了。用SelectObject保存返回值这个习惯，能挡掉一大半这类问题。

5.3 玩法逻辑：打不着人和掉血异常

现象：两个角色贴身站着，攻击动作播了，音效也响了，对方血条不动；或者反过来，隔着半个屏幕被打中。

原因：判定框和角色坐标的参照系不一致。角色坐标可能记录的是图片左上角，而判定框是按角色中心点算的；或者朝向翻转时只翻了图片没翻判定框，导致朝左时判定框跑到身后去了。

解决：在屏幕上把判定框画出来。加一个调试开关，active帧用红框画hitBox、蓝框画hurtBox、绿框画推挤框，跑一局就能一眼看出偏移。这个调试渲染我建议一直留着，用#ifdef _DEBUG包起来，后面调任何数值都要靠它。

现象：一次轻攻击扣了对方三段血，血条一下子掉一大截；或者双方同时出招，两个人都没掉血，直接穿过去了。

原因：前者是活动帧每帧都结算，缺hasHitThisAttack标志；后者是判定顺序写成了「先算 A 打 B，再算 B 打 A」，而 A 打中 B 之后把 B 的状态改成了受击，B 的攻击在这次结算里被跳过了。

解决：判定分两阶段。第一阶段把所有角色的攻击意图收集到一个列表里，不改任何状态；第二阶段统一结算，同时命中就同时生效，做成「相杀」。这个改动只有几十行，但对战体验完全是两回事。

6. 打击手感调优：把参数抽成一张可回滚的帧数据表

手感不是玄学，是一堆数字的组合，而且这些数字必须能改、能回退。工程里最常见的写法是把前摇帧数、伤害、击退直接写成字面量散落在switch分支里，改一次要翻五个文件。我的做法是全部抽到一张表里，逻辑代码只读表。

改表之后怎么验证改动是对的，这一步比调数值本身更重要。我的习惯是开一个帧日志：每逻辑帧把双方的状态、帧索引、active标志、血量打一行到文件，然后打同一段固定连招，对比改动前后的日志。重点看两件事——active为真的帧数是不是正好等于activeFrames，以及一次攻击在日志里是不是只出现一次扣血记录。这两个对上了，剩下的才是手感问题，对不上就是逻辑 bug，再调数值也没用。

血泪经验是：一次只改一个参数，改完立刻打同一段连招。同时改三个数值，最后觉得手感变好了，你根本不知道是哪个起的作用，想回退都无从下手。从那以后我每次动这张表之前都先复制一份带日期的备份，改崩了直接换回来，比在版本控制里翻历史快得多。希望帮到你。

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