从“能跑”到“能改”：C++寻宝猎人2.0重构实战复盘

刚把寻宝猎人2.0的源码在 GitHub 上开源那会儿，一个朋友跑来问我：一个用 C++ 写的小型寻宝游戏，代码量不到三千行，凭什么敢标 2.0？这个问题其实问到了点子上。1.0 版是我早先用控制台字符硬拼出来的，能跑，但每想加一个新功能，都得到那个膨胀到六百行的 main 函数里翻半天，改完一处又怕碰坏另一处。2.0 并不是简单加了几张地图、多几种怪物，而是把整个项目从“能跑”重构成“能改”。整个过程踩了不少坑，也积累了很多值得沉淀的经验，这篇博文就当一次开源项目的完整技术复盘。如果你是刚学完 C++ 语法、背了不少八股却不知道怎么落地的人，或者写完过小游戏但总觉得代码改不动，这篇文章应该会给你一些实在的参考。

1. 为什么做2.0：1.0版本的痛点复盘

1.1 控制台版的“能跑”与“难改”

1.0 版本是典型的“能跑”项目。整个游戏用 std::cout 输出字符画地图，_getch() 接收键盘输入，while 循环里包一个巨大的 switch，从移动、踩怪、捡宝箱到胜利判定全塞在一个 main 函数里。玩家控制的 @ 在地图上移动，碰到 T 就能捡到宝藏，走到 X 就算通关。听上去很完整，但代码结构是灾难级的。

当时最容易出问题的就是“状态”和“数据”全混在一起。玩家坐标、怪物坐标、宝藏数量、地图数组全是全局变量，任何函数都能改，一旦某个分支忘了更新，Bug 就很难追。更致命的是地图本身是硬编码的二维数组，想换一张图就得改源码重编译。后来我试着加“敌人巡逻”功能，发现要在主循环的 switch 里再插一个分支，处理怪物移动和碰撞，结果改完以后玩家穿墙的问题又冒出来了。

后来我把这段经历讲给一个做游戏行业的朋友听，他说你这不是写游戏，是在写“一次性脚本”，这句话我记了很久。1.0 的价值只是验证了玩法本身是有意思的，但它离一个能持续迭代的项目差得太远。

1.2 2.0立下的三条军规

做 2.0 之前，我给自己立了三条硬性要求，后面所有设计和重构都没有脱离这三条：

• 数据和逻辑分离。地图不再是硬编码数组，改由程序化生成；物品、怪物属性全部用独立的配置表管理，而不是散落在代码里。
• 主循环要分层。输入、更新、渲染三段拆开，各自独立，方便后续加新玩法时不用全盘推翻。
• 跨平台可编译。不能再依赖 Windows 控制台 API，底层渲染和窗口改用跨平台库，工程用 CMake 搭，让 Windows、Linux 和 macOS 都能一把过。

这三条军规本质上就是“防自己”的，防止我又回到那种靠全局变量和堆代码解决问题的舒适区里。事实证明，前期多花两天搭结构，后期改功能时能省下两周都不止。

2. 开工前的工程搭建：vscode + CMake + 跨平台编译

2.1 为什么不用一键New Project

很多人学 C++ 都是从 Visual Studio 新建控制台项目开始的，一键编译运行确实爽，但换到 2.0 我第一件事就是放弃这个流程。原因很简单：VS 的工程文件 .sln 和 .vcxproj 是 Windows 专属的，一旦想搬到 Linux 或者让别人用别的 IDE 打开，就会出现各种兼容问题。CMake 不是编译器，而是一个跨平台的构建系统生成器，它可以通过一份 CMakeLists.txt 生成出 MSVC 工程、Makefile 或者 Ninja 构建脚本，一套配置到处用。

这里多说一句，CMake 的学习成本没有想象中高。对单体小项目来说，核心命令就那么几条：cmake_minimum_required、project、add_executable 和 target_link_libraries。最基础的 CMakeLists.txt 我大概长这样：

cmake复制cmake_minimum_required(VERSION 3.16)
project(HunterGame)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 加载SDL2
find_package(SDL2 REQUIRED)

add_executable(hunter_game
    src/main.cpp
    src/Game.cpp
    src/MapGenerator.cpp
    src/Player.cpp
    src/ItemSystem.cpp
)

target_include_directories(hunter_game PRIVATE include)
target_link_libraries(hunter_game PRIVATE SDL2::SDL2)

用 CMake 之后，换一台机器不再需要我手动去配一堆库的路径，只要对方机器上装了 SDL2 和 CMake，三条命令就能完成构建。这也是开源项目“能被人跑起来”的最基本前提。

2.2 vscode配置c/c++环境的关键细节

开发过程中我一直用 vscode 写代码，很多教程喜欢直接让你装 C/C++ 插件，然后配一个 launch.json 点 F5 运行。但对 CMake 项目来说，更省心的做法是保证 vscode 里的配置只是薄薄一层“转发”，把 Intellisense 的 include 路径交给 CMake Tools 插件的 compile_commands.json 去引导。

我踩过的坑是：第一次配置 vscode 时，明明代码在 CMake 里能编译过，编辑器里却到处是红色的波浪线。原因就是 c_cpp_properties.json 里没写 SDL2 的头文件路径。后来我直接启用 CMake Tools 插件的 CMake: Export Compile Commands，让配置工作交给构建系统本身，编辑器红色波浪线立刻消失了。这种“让构建系统统一管头文件搜索路径”的思路，比手工维护一份 JSON 可靠得多。

编译和调试之外，还有一个容易忽略的东西：运行目录。SDL2 默认的资源加载是相对路径，如果你的 assets 目录和可执行文件不在同一个工作目录，图片和音效就会加载失败。我在 vscode 的 launch.json 里专门给 cwd 字段设置为项目根目录，保证资源相对路径能正确找到：

json复制{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Run Hunter",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/hunter_game",
            "args": [],
            "cwd": "${workspaceFolder}",
            "preLaunchTask": "CMake build"
        }
    ]
}

这个配置帮我省掉了大量“资源加载失败”的排查时间。

2.3 目录结构：把“能跑的代码”变成“能维护的代码”

2.0 的目录结构是我开工前就定好的，整整齐齐，强迫症看了会舒服：

code复制hunter-game/
├── assets/              # 图片、音频、物品配置JSON
│   ├── items.json
│   ├── monsters.json
│   ├── textures/
│   └── audio/
├── include/             # 公共头文件
│   ├── Game.h
│   ├── Map.h
│   ├── Player.h
│   ├── ItemSystem.h
│   └── ...
├── src/                 # 实现文件
├── build/               # CMake构建输出
├── tools/               # 地图生成器、资源检查脚本
├── CMakeLists.txt
└── README.md

把头文件和实现分离、资源文件和代码分离，看起来是个很基础的习惯，但对一个要开源的项目来说，它就是用户快速理解项目的第一道门槛。很多新手项目喜欢把 .cpp 和 .h 放同一个目录，小项目没毛病，可一旦文件多了，include 路径管理就乱套。分离之后，target_include_directories 指到 include 一个目录就够了，所有依赖关系一目了然。

3. 游戏循环与状态栈：架构的核心骨架

3.1 拆开输入—更新—渲染三段式

任何一款实时交互游戏，本质上都在干同一件事：读输入、算逻辑、画画面，然后循环往复。2.0 的主循环我把这三件事做了强行拆分，每段都能单独阅读和理解：

cpp复制while (running) {
    processInput();   // 只负责把事件转成意图，比如“玩家想向左走”
    update(deltaTime); // 只负责更新游戏逻辑，不碰窗口和渲染
    render();         // 只负责绘制当前画面
}

这个拆分最有价值的地方在于，update 阶段完全不需要关心“按键到底按在哪”，它只消费 processInput 里生成的状态。比如玩家按下 A 键或者左箭头，processInput 都会置 dir = Direction::LEFT，后面的逻辑只认 dir，不认具体哪个键。以后想加手柄支持，只需要在 processInput 里多映射一层即可，update 一行都不用改。

我也见过很多小游戏的写法是：在事件处理里直接改玩家坐标，然后稍后在循环末尾渲染。这在移动逻辑简单时确实是捷径，但一旦引入动画、可暂停、掉落物延迟生效等机制，就很容易出现“这个帧改了坐标但还没被渲染，下一帧又改了”的错乱。三段式的本质是让数据流的方向永远保持一致：事件 -> 意图 -> 逻辑 -> 画面。

3.2 用状态栈管理菜单、战斗、暂停和结算

游戏不可能只有“玩家在地图上走”这一种状态。打开背包、触发战斗、暂停界面、结算页面，这些都是不同的运行模式。我用一个状态栈来管理，栈顶就是当前活跃状态：

cpp复制enum class GameState {
    Menu,
    Explore,
    Battle,
    Inventory,
    Pause,
    GameOver
};

class StateStack {
    std::vector<GameState> stack;
public:
    void push(GameState s)   { stack.push_back(s); }
    void pop()               { if (!stack.empty()) stack.pop_back(); }
    GameState top() const    { return stack.back(); }
};

状态栈的好处在于天然支持“嵌套暂停”。比如战斗界面里如果打开背包，那就 Battle -> Inventory，关掉背包就自动回到 Battle，不用在代码里写复杂的回跳逻辑。如果战斗胜利，就 pop 掉战斗状态回到地图探索。这个设计的灵感来源于常见平台的 Activity/Fragment 栈，非常直觉。

状态切换的时候有几个注意事项。第一，状态入口和出口要成对处理，比如 Pause 进来时保存当前时间，出去时恢复计时，我会在 push / pop 的调用处统一做，而不是散落在各个业务函数里。第二，不要用 switch 去枚举状态然后到处嵌套 if，一旦状态多了，编译器帮你检查的力度会减弱，逻辑容易漏。我把每个状态的更新逻辑拆到了独立函数里，状态栈只做转发，这让每个状态都像一个“迷你游戏”。

3.3 固定时间步长：为什么不能让帧率牵着跑

主循环刚写完时，我直接用了 SDL_GetTicks() 算 deltaTime 去更新位置，也就是“每帧移动速度 × 帧间隔”。这个方案在普通 PC 上很常见，但存在一个隐患：不同显示器的刷新率不一致，160Hz 屏幕上游戏会比 60Hz 屏幕快近两倍。更严重的是，如果某帧因为后台任务卡了一下，deltaTime 突然变大，怪物可能会“瞬移”到墙后面。

2.0 用固定时间步长来解决这个问题。核心思想是：逻辑更新固定按 1/60 秒的步长计算，多出来的时间积累下来，攒够一个步长就更新一次，渲染则尽量跟随显示器刷新率：

cpp复制double accumulator = 0.0;
const double step = 1.0 / 60.0;
Uint64 last_time = SDL_GetPerformanceCounter();

while (running) {
    Uint64 now = SDL_GetPerformanceCounter();
    double frame_time = (double)(now - last_time) / SDL_GetPerformanceFrequency();
    last_time = now;
    accumulator += frame_time;

    while (accumulator >= step) {
        processInput();       // 输入也可以按固定步长采样
        update(step);
        accumulator -= step;
    }
    render();
}

这个方案的代价是，如果渲染跟不上逻辑，accumulator 会无限增长，这就需要在 update 循环里加一个最大更新次数限制，防止“死亡螺旋”。我在实际项目里设了最多连续更新 5 次，超过就直接丢弃积累时间。固定时间步长最大的收益是：所有数值计算、碰撞判定、怪物 AI 都在“同一个时间基准”上运行，后续调试任何与速度相关的逻辑都会轻松很多。

4. 程序化地图：从手工填数组到房间+走廊自动生成

4.1 地图的数据结构与渲染解耦

1.0 版本的地图是手工输入的字符数组，# 代表墙、. 代表地板。2.0 改成程序化生成之后，地图的本质仍然是一张“格子表”，只是数据的来源变了。我的地图类内部用 std::vector<std::vector<Tile>> 存格子，Tile 是一个枚举，但渲染的时候并不直接拿枚举去画图，而是把 Tile 映射到具体的纹理和是否可通行属性：

cpp复制enum class Tile : char {
    Wall = '#',
    Floor = '.',
    Door = 'D',
    Treasure = 'T',
    MonsterSpawn = 'M',
    Exit = 'X'
};

struct TileInfo {
    bool walkable;
    const char* texture_path;
    // ...
};

数据结构和渲染解耦的好处体现在：我想换一套美术资源，只需改 TileInfo 的映射表，地图生成逻辑完全不用动；我想让某类墙不可通行但可以通过“探测术”看到背后有宝藏，也只需要单独查表而不影响地图存储。

4.2 房间生成与走廊连接算法

程序化地图生成我采用了相对经典的“随机房间 + 走廊连接”方案，这也是很多 Rogue-like 游戏的做法，实现起来不复杂，效果却相当自然：

1. 先在空白地图上随机放置 N 个矩形房间，房间大小和位置都带随机性，但必须完全落在边界内，并且和已有房间保持最小间距。
2. 然后把房间按中心点排序，依次用 L 形走廊连接相邻两个房间中心。L 形走廊就是先水平走一段、再垂直走一段，两条线段都能保证地板可通行。
3. 最后在全图跑一遍连通性检查，确保所有房间都被走廊连起来，防止出现孤立区域。

核心代码里，房间生成部分最需要注意的是“重叠检测”。我在代码里写了一个辅助函数，判断两个矩形是否相交，如果相交就重新生成，随机次数上限之后采用默认位置，避免死循环。这个“随机失败后回退”的思想也适用于很多其他程序化生成场景。

走廊生成如果只画一条线宽度为 1，视觉上会显得很窄，实际操作中我会把走廊宽度设成 2 格，并且在地图边缘多画一圈墙，避免玩家直接走出边界。走廊转弯处容易出现墙壁参差，处理办法是在拐角处强制补一块地板，保证玩家行动的连续感。

4.3 宝藏、怪物、出口的放置规则与边界检查

地图生成后，下一步是往里面放各种“内容”。我设计了一套放置规则，避免无尽随机带来的体验问题：

• 玩家出生点固定放在第一个房间的中心，保证开局周围相对安全。
• 宝藏数量 = 房间数 × 2，分散在不同房间，并且保证不会全部集中在地图深处。
• 怪物生成位置离玩家出生点至少 8 格以上，避免“开局被围”。
• 出口只出现在最后一个被连接的房间里，并且门前走廊宽度不小于 2，防止 BOSS 战区域太狭窄。

这些规则看似简单，里面的边界检查却全是细节。怪物不能生成在墙里，宝藏不能生成在走廊上挡路，出口也不能直接贴着墙面生成。我专门封装了一个 findRandomWalkableTile() 方法，它会反复随机采样，并通过 isWalkable 判断直到找到合法位置，同样设置最大尝试次数防止极端情况。

这节还有一个容易被新手忽略的点：地图生成完之后一定要跑一遍“玩家可达性检测”。如果大部分宝藏都生成了但玩家根本走不到，那这局游戏就是“假玩起来”。我用一个简单的 BFS 从玩家出生点出发，统计能到达的地板格数量，如果低于总地板数的一定比例，就整张地图重新生成。这个检测让 2.0 的地图质量有了稳定的下限。

5. 怪物AI与碰撞检测：让敌人“有点脑子”

5.1 感知半径与简单追击AI

寻宝猎人2.0里的怪物不能像 1.0 那样只会原地站着等玩家撞上去，我给它加了一套简单的感知—追击—攻击逻辑。怪物的行为由几个状态切换：Idle（原地待着）、Chase（追玩家）、Attack（近战攻击冷却）。

感知逻辑我没做复杂的视锥，而是直接用“曼哈顿距离 + 直线遮挡检测”。曼哈顿距离比欧几里得距离计算成本更低，也符合四方向移动的网格游戏直觉。如果玩家进入怪物的感知半径（默认 10 格），并且中间没有墙阻挡，怪物就切到 Chase 状态；否则回到 Idle。

直线遮挡检测本质是网格版的 DDA 画线算法，从怪物格子向玩家格子逐点采样，看路径上有没有 Wall。这个算法比 BFS 找路径快得多，适合每帧对每个怪物都调用。不过要注意，如果怪物被墙挡住了视线，它会傻在原地，所以我还加了一个“回到巡逻点后随机走两步”的 Idle 行为，让怪物不至于完全变成摆设。

5.2 BFS寻路与A*的成本对比

怪物从 Chase 状态开始就需要“走到玩家身边”，而不是直线飞过去。这个需求最直接的解法是 BFS 寻路。对一张经典的 Rogue-like 地图来说，格子数量通常在上万级，每帧给场上最多十来只怪物跑一次 BFS，性能完全扛得住。BFS 的代码比 A* 短很多，而且保证在无权网格中找到的是最短路径：

cpp复制std::vector<Vec2> bfsPath(const Map& map, Vec2 start, Vec2 target) {
    if (!map.inBounds(start) || !map.inBounds(target)) return {};
    std::queue<Vec2> frontier;
    std::map<Vec2, Vec2> cameFrom;
    frontier.push(start);
    cameFrom[start] = start;

    while (!frontier.empty()) {
        Vec2 cur = frontier.front();
        frontier.pop();
        if (cur == target) break;
        for (Vec2 next : map.neighbors(cur)) {
            if (map.isWalkable(next) && !cameFrom.count(next)) {
                frontier.push(next);
                cameFrom[next] = cur;
            }
        }
    }
    // 从 target 回溯路径
    std::vector<Vec2> path;
    Vec2 step = target;
    while (!(step == start)) {
        if (!cameFrom.count(step)) return {};
        path.push_back(step);
        step = cameFrom[step];
    }
    std::reverse(path.begin(), path.end());
    return path;
}

有人会问为什么不用 A*？这里的关键是“值不值得”。A* 在超大开放地图上因为启发式搜索的剪枝效果，性能优势非常明显，但在房间走廊分割的网格地图上，路径大多比较短，BFS 的常数已经足够低。而且 A* 正确的实现需要维护 open list 的排序结构，写起来复杂，一不留神还会出现启发函数不一致导致的路径次优问题。我的原则是：先跑 BFS 能解决问题就不上 A*，等性能瓶颈真的出现再替换。很多项目的寻路优化其实是被过度工程了。

5.3 碰撞检测的顺序与浮点陷阱

碰撞检测这块，2.0 用的还是格子碰撞，逻辑上比像素级碰撞简单十倍。玩家移动前先计算目标格子，如果目标格子 walkable 为 true 就移动过去，否则原地不动。但这里有三个容易踩的坑值得单独说：

一是移动检测的先后顺序。一次键盘输入如果同时携带斜向移动意图，很多新手直接处理成 (dx, dy) 同时变化，结果在走廊里贴着墙走时很不顺滑。我的解法是拆分成“先尝试水平移动，再尝试垂直移动”，每次移动都单独检测目标格子是否可行。这能让贴墙走、拐弯的手感舒服很多。

二是浮点误差。虽然格子坐标用整数表示，但玩家角色的位置我存在 float 里做平滑插值。插值计算后如果直接跟格子坐标比较，很容易因为 0.0001 的误差导致判定失败。解决办法是统一用 round() 到最近的整数格子再做碰撞判断，并且把所有“位置坐标”和“格子坐标”在接口层严格区分，避免混用。

三是墙角的视觉缝合问题。如果只是简单地把可通行格子的地砖贴一遍，墙根处容易出现明显的缝隙。这个不是 C++ 问题，而是资源绘制问题，我的处理是给墙和地板的交界处绘制过渡纹理，同时在碰撞层保留墙格的不可通行属性。

6. 背包、装备与战斗结算：新版本玩法背后的数据结构

6.1 用组合替代继承来设计物品

2.0 准备加背包和装备系统之前，我第一反应是用经典的“物品继承体系”：Item 是基类，HealthPotion、TreasureKey、Sword 都是它的子类。但越设计越觉得繁琐，因为游戏里的物品差异维度很多，比如药水会回血，钥匙能开门，武器增加伤害，但也有一些东西是“同一个物品有多个效果”，比如一把火剑既能加攻击又能在某些场景点火把。

这种情况下继续用继承，要么疯狂加子类，要么用多重继承导致菱形问题。我在设计阶段看到一篇关于数据驱动游戏物品的老文章，思路是物品本身不写业务逻辑，而是维护一组组件或属性：

cpp复制struct Item {
    std::string id;
    std::string name;
    std::vector<Effect> effects;  // 回血、加攻、开锁等
};

这样“火剑”就只是普通剑的 ID + 一条额外”点火“效果，改配置就行，不用新建类。这套组合优于继承的核心原因是：继承表达的是“是什么”，组合表达的是“能干什么”，而游戏物品恰恰更关心后者。

6.2 背包栏与物品使用逻辑

背包的数据结构我用了 std::vector<std::optional<Item>> 加一个最大容量，没直接上链表或红黑树。为什么不用更花哨的结构？因为一个寻宝游戏里背包最多 20 格，线性遍历在 O(20) 的复杂度下是无所谓优化的。很多初学者看到“背包系统”就想到各种高级数据结构，但实际上大多数游戏背包底层就是一个数组，排序和筛选交给策略函数处理即可。

打开背包后状态栈把一个 Inventory 状态压上去，此时游戏暂停，地图更新不会执行，玩家可以用方向键选中物品、回车使用、Backspace 关闭。物品使用的副作用（比如回血后玩家血量变了）在 useItem() 方法里直接修改玩家状态，然后弹一条战斗日志，这个日志用一个 std::deque<std::string> 维护最近几条消息，渲染时只显示尾部 5 条，避免 UI 被刷屏。

一个容易忽略的细节是物品堆叠。HealthPotion 这类消耗品应当支持堆叠，否则背包很快就满了。我在 Item 里加了一个 count 字段，使用一个就减一，减到 0 就把 optional 清空。这个逻辑简单，但需要和“丢弃物品”操作放在同一套代码里，避免两处重复实现产生不一致。

6.3 战斗结算的状态机设计

进入战斗以后，流程不再是实时操作，而是回合制。我把战斗也做成了状态机，每一帧检查当前战况：玩家等待输入时是 PlayerTurn，玩家选完动作后切成 EnemyTurn，敌人行动完再切回 PlayerTurn。如果需要播放动画，中间会插入一个 Animation 状态，等动画结束再继续。

战斗结算的核心其实是一个数值公式：我方伤害 = 攻击力 + 随机浮动值 - 敌方防御力。为了不让战斗变成纯粹的填表算术，我给暴击、闪避、连续攻击都加了概率判定，并且把随机数生成统一封装好。这里强烈建议所有随机判定都走同一个 Random 工具类，并被种子初始化，不要到处调 rand()。否则调试时没法重现一场战斗，每次 Bug 都像玄学。

我实际遇到的 Bug 是：玩家杀掉最后一只怪物后，胜利面板没弹出来。排查原因是怪物死亡时战斗结算逻辑用了 for 遍历怪物容器，而删除当前元素的动作发生在遍历过程中，导致迭代器失效。改成先标记待删除，再循环结束后统一清理，问题就消失了。迭代器失效这种错误，只在容器修改时容易触发，写代码时一定要有“容器被修改后迭代器无效”的警觉。

7. 开源发布与后续维护经验

7.1 README怎么写才有人愿意跑起来

代码写完之后，开源只是万里长征第一步。我见过不少项目代码不错，但 README 只有两行字，导致别人根本跑不起来，最后 Star 也很少。2.0 的 README 我花了大概三个小时来写，核心只有一件事：让一个完全不知道项目的人，在五分钟内把游戏跑起来。

README 至少要包含这几个模块：项目简介（两三句话说清楚是什么）、环境依赖（编译器版本、SDL2 版本）、构建步骤（逐条命令，Windows/Linux/macOS 分别给）、操作说明（键位表）、项目结构树、常见问题（资源加载失败、中文乱码等）。键位表这种内容最适合用表格：

我还放了一张录制好的 GIF 动图在 README 顶部，图片比文字更能让人第一眼判断“这个游戏有没有意思”。开源的传播很多时候靠的是口碑，README 就是口碑的起点。

7.2 许可证、Issue模板与Release管理

项目开源以后，许可证选择直接关系到别人能不能合法地用你的代码。我给自己这个个人学习项目选了 MIT 协议，原因是它足够宽松，别人可以自由使用、修改、再分发，只要保留版权声明即可。如果你的项目不想被人用来盈利，可以选 GPL 系，但那对个人开源来说，可能会劝退一部分潜在贡献者。选许可证这件事，别抄别人，要明白每个协议的大致约束再决定。

GitHub 上设置 Issue 模板也很值得做。刚开始开源时几乎没有 Issue，过了一段时间开始有人提反馈，但大多数都是“打开闪退”这种没头没尾的描述。我后来加了 Bug 模板和功能建议模板，强制提问者填写操作系统、编译环境、复现步骤，问题质量立刻上了一个台阶。别小看这个动作，它节省的是你之后反复追问的时间。

独立软件发布我建议大家用 Release 而不是让人手动编译。虽然本项目主要面向开发者，但总有非深度用户想直接玩。我在 Release 页挂了 Windows 的 zip 包和 Ubuntu 的构建脚本，每个版本都写清楚新增内容和破坏性变更，这对吸引贡献者维护项目非常有帮助。

7.3 实测中遇到的崩溃与优化建议

2.0 从写完到稳定运行，中间修了大概七八个问题，这里挑两个最有代表性的聊聊。

第一个是退出时偶发崩溃。排查之后定位到全局 TextureManager 在析构时，SDL_DestroyTexture 被调用了两次。原因是某些纹理被多个对象以原始指针方式持有，对象释放时各释放一次。修复办法是引入了引用计数或者说把纹理对象的生命周期交给资源管理器统一管理，外部只拿索引，不许拿裸指针。这个教训再次验证了“资源所有权清晰”在现代 C++ 里的重要性。

第二个是帧率在部分低配机器上不稳定。地图渲染的优化方案很简单：只渲染当前相机可视范围内的格子，不把整张地图的几千个格子全交给渲染器。我在初始化时就把地图切成了 16×16 的块，渲染时先粗筛出可见的块，再对块内的格子做精确绘制，帧率从偶尔跌破 30 直接稳定在 60 以上。如果你觉得地图渲染有瓶颈，先检查是不是做了全图绘制，这可能是最高性价比的优化。

如果后续继续迭代，我大概率会把地图生成放进 std::thread 里异步执行，避免生成大地图时界面卡顿，但这需要处理好数据竞争，资源管理器也要设计线程安全的版本。这个方向留给下个版本再折腾，现阶段的重心还是保持代码简单、可读、可贡献。

做完2.0以后，我再回头看那些 c++面试题里的“八股”问题，比如容器迭代器失效、RAII资源管理、移动语义，全都有了真实的画面感。所以如果你也在学 C++ 的路上徘徊，别只盯着语法和考题，找一个像“寻宝猎人”这样小而完整的游戏项目，从头到尾把“能跑”做成“能改”，那些知识点会自动长在手上。