简介：《Slime-Hunter》是一款使用C++与easyx图形库开发的肉鸽小游戏，作者以课程设计为背景完成了中期版本，包含角色控制、敌人行为、得分机制等基础功能，尤其适合正在学习C++图形界面编程或准备游戏课设的入门者参考。压缩包整体95.16MB，共531个文件，囊括完整的Visual Studio工程（.sln、.vcxproj、.cpp、.h）、可运行exe、调试中间文件，以及大量gif/jpg动画截图和mp3音频素材，既能直接运行体验，又能对照源码理解绘图交互与游戏状态的实现。目前已有263人浏览学习，说明对同类项目具备一定参考价值。借助源码和素材，读者可以快速上手easyx的基本用法，了解游戏主循环、碰撞检测、资源组织等工作方式，也能借助工程结构和演示动画把握迭代思路，为后续自行开发或完善功能打下基础。

1. 从零手写一个C++肉鸽游戏：Slime-Hunter到底在做什么

如果你搜到这个标题，大概率不是想找一个现成的成品游戏，而是想弄明白「用C++写一个肉鸽（Roguelike）游戏」这条路到底怎么走。Slime-Hunter这个名字听起来像是个Demo项目，但它背后藏着一整套值得复现的东西：随机地图生成、回合制战斗、永久死亡、道具掉落、状态存档，这些恰恰是肉鸽游戏最核心的骨架。用C++来做这件事，好处是你被迫自己处理内存、数据结构、随机数、状态机这些底层问题，做完之后你对「游戏循环」的理解会比用Unity拖组件深刻得多。

这篇文章适合两类人：一类是C++语法已经入门、想找个正经项目练手的开发者，另一类是已经在做小游戏、想给自己的作品加上肉鸽玩法的人。我会按照「地图怎么生成 → 战斗怎么设计 → 存档怎么做 → 坑在哪」的顺序，把Slime-Hunter这种项目的完整落地路径拆开讲。代码都是可复现的最小实现，你照着敲就能跑，跑起来之后再往里面加怪物种类、技能、装备系统都不难。

2. 用C++写肉鸽游戏的地图生成：随机迷宫与房间布局的实现

2.1 为什么肉鸽游戏离不开随机地图生成

肉鸽（Roguelike）的核心体验是「每一局都不一样」，而地图随机生成就是这种体验的地基。Slime-Hunter里的场景如果每次进入都是同一张图，那刷装备、探路、规划路线的乐趣就全没了。但随机生成并不是「乱画一通」，它需要在可玩性和随机性之间取平衡——太乱玩家会迷路，太规整又显得假。

常见的做法有两种：一种是BSP二叉树分割法，把地图递归切分成多个矩形房间，再用走廊连接；另一种是随机房间+最小生成树法，先生成一组互不重叠的房间，然后用算法找出关键连接路径，再补几条环路。Slime-Hunter这类俯视角2D游戏用后者更合适，因为它天然支持房间和走廊两种地形，玩家一眼就能看出「这是一个房间，那是通道」。

我一般会先用一个二维数组铺底图，0表示墙壁，1表示地板。这个数组就是整个地图的数据模型，之后不管是刷怪物、放掉落物还是做碰撞检测，都直接读写这个数组。把底图数据设计好，后续所有系统都围绕它转，比直接操作坐标点要稳得多。

2.2 最小生成树连接房间：Kruskal算法的应用

生成房间之后，连接是关键。如果单纯把所有房间两两连起来，地图就会变成一团乱麻；如果只连一条链，玩家又只能线性推进，没有探索感。这里我会用Kruskal算法对所有房间做最小生成树，保证所有房间连通的同时路径最少，然后再随机补几条边，让地图有环路。

#include <vector> #include <algorithm> struct Edge { int from, to, weight; }; struct UnionFind { std::vector<int> parent; UnionFind(int n) : parent(n) { for (int i = 0; i < n; i++) parent[i] = i; } int find(int x) { while (x != parent[x]) { parent[x] = parent[parent[x]]; // 路径压缩 x = parent[x]; } return x; } bool unite(int a, int b) { int ra = find(a), rb = find(b); if (ra == rb) return false; parent[ra] = rb; return true; } }; // rooms 是预先生成的房间列表，每个房间有中心坐标 std::vector<Edge> buildMSTConnections(int roomCount) { std::vector<Edge> allEdges; for (int i = 0; i < roomCount; i++) { for (int j = i + 1; j < roomCount; j++) { // 距离越近，权重越小，优先连接 int dist = abs(roomCenters[i].x - roomCenters[j].x) + abs(roomCenters[i].y - roomCenters[j].y); allEdges.push_back({i, j, dist}); } } std::sort(allEdges.begin(), allEdges.end(), [](const Edge& a, const Edge& b) { return a.weight < b.weight; }); UnionFind uf(roomCount); std::vector<Edge> mstEdges; for (const auto& e : allEdges) { if (uf.unite(e.from, e.to)) { mstEdges.push_back(e); } } return mstEdges; }

这段代码里的UnionFind是并查集结构，find带了路径压缩，能让合并操作接近O(1)。buildMSTConnections先把所有房间两两配对生成边，权重用曼哈顿距离表示，然后按权重升序排列，逐条尝试合并。合并成功说明这两个房间此前不连通，这条边就留下；合并失败说明已经连通，跳过。最终留下的边数一定是房间数减一，这就是一棵最小生成树。

用曼哈顿距离做权重的理由是，走廊在网格地图上只能横平竖直地走，欧几里得距离反而不符合实际路径。如果你希望地图更紧凑，可以在权重里加一点随机扰动，让相邻房间不一定总是被优先连接——这样同一关每次生成的地图结构都有变化，玩家不会摸清规律。

2.3 走廊生成与地图数组写入：L型走廊的实现

MST只给出了「哪些房间需要连通」的信息，真正画走廊还要把边转成坐标路径。最简单的方式是L型走廊：先横着走到目标房间的X坐标，再竖着走到目标房间的Y坐标。这种走廊虽然不够美观，但实现简单、不易出错，对于2D俯视角肉鸽游戏完全够用。

void carveCorridor(std::vector<std::vector<int>>& map, int x1, int y1, int x2, int y2) { // 先水平方向挖过去 for (int x = std::min(x1, x2); x <= std::max(x1, x2); x++) { map[y1][x] = 1; } // 再垂直方向挖过去 for (int y = std::min(y1, y2); y <= std::max(y1, y2); y++) { map[y][x2] = 1; } }

注意这里挖走廊的顺序是「先横后竖」，也就是说走廊在拐角处会形成一个直角。如果把顺序反过来，路径会稍微不同，但效果都成立。map[y][x]的行列顺序容易搞反——第一个索引是行（Y坐标），第二个是列（X坐标），这是一个经典的C++二维数组坑，后面避坑章节还会细说。

走廊宽度默认是1格，玩家角色如果也占1格就会觉得通道很挤。我建议把走廊宽度改成3格：挖的时候以中心线为基准，左右各扩展1格。代价是房间边界要留出足够间隔，否则走廊会挖穿别的房间。判断方法是：走廊格子在写入前检查周围8格，如果有其他房间的地板，这面墙就不要留，直接打通。

2.4 地图数据封装与坐标系统：为什么用struct而不是class

地图数据在游戏循环里会被频繁读写，我会把它封装成一个GameMap结构体，包含宽高、格子数组、玩家出生点、楼梯位置这几个关键字段。用struct而不是class的原因是，这个对象没有复杂的封装需求——它就是个数据容器，所有字段对外可见，省去getter/setter的噪音。

struct GameMap { int width, height; std::vector<std::vector<int>> tiles; int playerStartX, playerStartY; int stairsX, stairsY; GameMap(int w, int h) : width(w), height(h), tiles(h, std::vector<int>(w, 0)) {} bool isWalkable(int x, int y) const { if (x < 0 || x >= width || y < 0 || y >= height) return false; return tiles[y][x] == 1; } };

isWalkable是碰撞检测的最小接口，所有移动逻辑只认这个函数。注意它先做边界检查再访问数组，顺序不能反——C++的vector越界访问不会立刻崩溃，而是产生未定义行为，表现起来就是「偶尔闪退、偶尔正常运行」。后面寻路、刷怪、放置玩家都要先调用isWalkable确认目标格能走，这是整个游戏稳定性的底线。

3. Slime-Hunter的回合制战斗系统：玩家与史莱姆的行动逻辑

3.1 回合制循环的状态机设计

肉鸽游戏有两种时间推进方式：实时制与回合制。Slime-Hunter用回合制更合适，因为它和随机地图天然搭配——玩家每走一步，怪物跟进一次，整个游戏节奏由玩家的决策驱动，而不是靠帧循环驱动。回合制的核心是一个有限状态机：PLAYER_TURN、ENEMY_TURN、GAME_OVER三个状态循环切换。

enum class GameState { PLAYER_TURN, ENEMY_TURN, GAME_OVER, WIN }; GameState state = GameState::PLAYER_TURN; void gameLoop() { while (state != GameState::GAME_OVER && state != GameState::WIN) { handleInput(); // 读取玩家动作 updateWorld(); // 刷新怪物状态 render(); // 输出画面 checkGameOver(); } }

handleInput只在PLAYER_TURN状态下生效，玩家按键移动或攻击后，状态切到ENEMY_TURN。updateWorld里所有怪物各自执行AI逻辑，结束后回到PLAYER_TURN。这个循环的要点是「一个回合只允许玩家做一件事」，不要出现玩家连续砍两刀或者怪物连续走两格的情况。

3.2 玩家移动与碰撞：看向哪、走到哪

移动逻辑的逻辑很简单：读取方向键，计算目标坐标，检查目标格是否可行走，可行就更新玩家位置；如果目标格上有怪物，就触发攻击而不是移动。这里最容易出错的是「先判断怪物还是先判断墙壁」的顺序，如果反过来，玩家贴墙打怪会判定撞墙，体验很生硬。

void movePlayer(GameMap& map, int dx, int dy) { int nx = player.x + dx; int ny = player.y + dy; // 目标有怪物 -> 攻击 for (auto& enemy : enemies) { if (enemy.x == nx && enemy.y == ny && enemy.alive) { attackEnemy(enemy); state = GameState::ENEMY_TURN; return; } } // 目标可行走 -> 移动 if (map.isWalkable(nx, ny)) { player.x = nx; player.y = ny; state = GameState::ENEMY_TURN; } }

移动和攻击共用一个入口，这是回合制游戏的常规设计。攻击命中后立即切到敌人回合，等于玩家攻击不消耗额外时间；如果攻击落空也要切状态，否则玩家可以反复攻击直到命中，游戏就失衡了。攻击的命中率、伤害数值建议在独立的attackEnemy函数里计算，方便后续加暴击、属性克制。

3.3 史莱姆AI：简单寻路与感知范围

肉鸽游戏里的怪物不需要太聪明，但也不能傻站着。Slime-Hunter的史莱姆AI我会做成两层：感知层和行动层。感知层判断玩家是否在警戒范围内（比如曼哈顿距离小于等于5），在范围内就追，不在就随机游走。行动层负责实际移动——每次只走一格，优先向玩家方向靠拢。

void updateEnemy(Enemy& enemy, const GameMap& map) { if (!enemy.alive) return; int dist = abs(enemy.x - player.x) + abs(enemy.y - player.y); if (dist <= enemy.detectRange) { // 追踪：分别计算X和Y方向的步进 int dx = (player.x > enemy.x) ? 1 : ((player.x < enemy.x) ? -1 : 0); int dy = (player.y > enemy.y) ? 1 : ((player.y < enemy.y) ? -1 : 0); // 优先尝试水平移动，受阻则尝试垂直移动 if (dx != 0 && map.isWalkable(enemy.x + dx, enemy.y)) { enemy.x += dx; } else if (dy != 0 && map.isWalkable(enemy.x, enemy.y + dy)) { enemy.y += dy; } else if (map.isWalkable(enemy.x + dx, enemy.y + dy)) { enemy.x += dx; enemy.y += dy; } } else { // 随机游走：向随机方向移动 int dir = rand() % 4; int rdx[] = {0, 1, 0, -1}; int rdy[] = {-1, 0, 1, 0}; int tx = enemy.x + rdx[dir]; int ty = enemy.y + rdy[dir]; if (map.isWalkable(tx, ty)) { enemy.x = tx; enemy.y = ty; } } }

这个AI有个明显的局限：它不会绕过障碍物，如果玩家躲在L型走廊的拐角后，史莱姆会一头撞在墙上然后停在原地。解决办法是在else if分支加一格斜向移动，让怪物贴着墙壁滑动；更完善的做法是接一个BFS寻路，但Slime-Hunter这种小型Demo没必要上BFS，保持怪物有点「笨」反而像早期Roguelike的味。rand() % 4用了C标准库的随机数，后续会讨论为什么需要换成更好的随机数方案。

3.4 战斗数值与随机数：先解决C++随机数的坑

伤害计算里最怕「每次打出的数字都一样」，这会让战斗完全失去波动。传统写法rand()有两个问题：一是如果不调用srand初始化，每次程序启动生成的序列完全一样；二是rand()的周期可能只有几万，对肉鸽游戏这种长时间运行的程序会产生可感知的重复模式。C++11之后的标准库提供了<random>，这才是正路。

#include <random> std::mt19937 rng(static_cast<unsigned int>( std::chrono::steady_clock::now().time_since_epoch().count() )); int rollDamage(int baseDamage) { std::uniform_int_distribution<int> dist(0, baseDamage / 2); return baseDamage + dist(rng); }

std::mt19937是梅森旋转算法，周期长达2的19937次方减1，对游戏来说基本可以认为是真随机。用steady_clock当前时间戳做种子，保证每次启动的序列不同。uniform_int_distribution负责把随机数映射到指定区间，这里表示在基础伤害上增加0到一半基础伤害的浮动值。比如基础伤害10，最终落在10到15之间，玩家能明显感觉到「这一刀重了」的反馈。

注意dist(rng)每次调用都传入rng对象，不要自己实现取模随机——%会把随机数的低比特位暴露出来，某些发生器会产生明显的取模偏差。随机数是战斗手感的一部分，值得花十分钟做对。

4. 掉落系统与背包管理：让每一局都有成长感

4.1 史莱姆掉落物设计：掉落表与概率控制

肉鸽游戏的爽感很大一部分来自「赌掉落」。Slime-Hunter里杀死一只史莱姆，应该掉落什么东西，得有一个可控的掉落表。直接写if (rand() % 100 < 20)也能用，但掉落多了之后代码会变得又长又乱。我会用一张权重表来管理所有掉落物，每个物品一个权重，总权重做分母。

struct DropEntry { int itemId; int weight; }; // 史莱姆的掉落表 std::vector<DropEntry> slimeDropTable = { {ITEM_NONE, 50}, {ITEM_HEAL, 30}, {ITEM_SWORD, 15}, {ITEM_ARMOR, 5} }; int rollDrop(const std::vector<DropEntry>& table) { int total = 0; for (const auto& entry : table) total += entry.weight; int roll = uniformInt(1, total); // 1到total闭区间 int cumulative = 0; for (const auto& entry : table) { cumulative += entry.weight; if (roll <= cumulative) return entry.itemId; } return table.back().itemId; }

权重表的优势是调整概率时不用改代码——把ITEM_SWORD的权重从15改成2，掉率立刻变化，数值策划的需求被直接满足。注意ITME_NONE的权重就是「什么都不掉」的概率，它参加了累计计算，所以总和一定是100%覆盖。掉落物生成的位置建议放在怪物死亡格，这样玩家需要走回去捡，制造一点交互感；如果直接背包到玩家身上，就少了那种战利品躺在地上的感觉。

4.2 背包数据结构：定长数组与道具叠加

肉鸽游戏的背包通常是定长的，比如20格，每格要么空着，要么放一个道具。道具按类型分可叠加（药水类）与不可叠加（武器类）。C++里比较稳的方案是用std::vector加std::optional，但为了减少依赖，我会用结构体数组手动管理。

struct Item { int id; int count; }; class Inventory { public: static const int CAPACITY = 20; Item slots[CAPACITY]; bool addItem(int itemId, int count = 1) { // 先尝试叠加到已有道具 for (int i = 0; i < CAPACITY; i++) { if (slots[i].id == itemId && slots[i].count < 99) { slots[i].count += count; return true; } } // 找不到叠加，找个空格 for (int i = 0; i < CAPACITY; i++) { if (slots[i].id == 0) { slots[i] = {itemId, count}; return true; } } return false; // 背包已满 } void removeItem(int slotIndex, int count = 1) { Item& item = slots[slotIndex]; item.count -= count; if (item.count <= 0) { item.id = 0; item.count = 0; } } };

slots[i].id == 0表示空格，这个约定避免了额外维护一个empty标记。注意叠加上限99，超过上限时即使背包没满也会创建新格子，这个阈值可以根据道具类型做成可配置——有些游戏药水不叠加、卷轴最多5张，规则不同需求不同。

背包系统的坑主要在处理「满了」的状态。addItem返回false后，游戏要提示「背包已满」并让道具留在原地；如果忽略返回值，道具会凭空消失，玩家会觉得很迷。还有一点：掉落物从地图移除和放入背包必须是一个原子操作，不要在怪物死亡时就直接插入背包，而是等玩家走到道具上再触发。

4.3 装备系统：如何让攻击力动态计算

拿到武器后攻击力应该立刻变化，这就需要一个getPlayerAttack()之类的动态属性函数。玩家的基础攻击力是常量，装备加成循环相加，临时Buff另外算。这种设计比一处处修改全局攻击变量要稳，因为后期加Buff、加中毒效果时不用回头改战斗逻辑。

int getPlayerAttack() { int base = 5; int equipmentBonus = 0; int buffBonus = 0; for (const Item& item : inventory.slots) { if (item.id >= ITEM_SWORD_START) { equipmentBonus += itemAttackBonus(item.id); } } // buffBonus 由状态效果系统维护 return base + equipmentBonus + buffBonus; }

这种写法把攻击力计算收敛到一个函数里，所有战斗逻辑调用它，而不是到处散落着attack = 5 + swordBonus。同样的手法可以用于防御力、暴击率、移动速度。肉鸽游戏后期道具组合爆炸，动态计算属性是唯一的出路；如果每个道具直接改全局变量，卸载道具时你就得记住之前改了什么，那是一个痛苦的黑匣子。

5. 楼层推进与永久死亡的存档机制：肉鸽的最后一环

5.1 为什么存档是肉鸽游戏最微妙的设计

肉鸽游戏有一个矛盾：它希望玩家死亡后重头再来，但一次游戏可能持续40分钟以上，完全不存档又太不近人情。Slime-Hunter的做法是分两种存档：探险存档（每下到新楼层自动记录一次）和最终存档（玩家通关后记录结果）。不支持战斗中随时存档，这样死亡惩罚保留，又不会因为闪退让玩家白打40分钟。

从实现角度，存档的本质就是把GameMap、Player、Enemy、Inventory的字段序列化成字节或文本，再写到磁盘。C++没有内置序列化机制，得自己设计格式。我推荐用文本格式（比如JSON或自定义分隔），虽然体积大一点，但排错方便——存档损坏时你能用文本编辑器直接看到问题在哪一行。

5.2 保存与读取：从内存到文件的序列化

下面这个函数把整个游戏状态写到一个文本文件里。格式很简单：每个对象一行，字段用冒号分隔。

bool saveGame(const GameState& gs, const std::string& filename) { std::ofstream file(filename); if (!file.is_open()) return false; file << "VERSION 1\n"; file << "PLAYER " << gs.player.x << " " << gs.player.y << " " << gs.player.hp << " " << gs.player.maxHp << "\n"; file << "MAP " << gs.map.width << " " << gs.map.height << "\n"; for (int y = 0; y < gs.map.height; y++) { for (int x = 0; x < gs.map.width; x++) { file << gs.map.tiles[y][x] << " "; } file << "\n"; } file << "ITEMS"; for (const auto& item : gs.inventory.slots) { file << " " << item.id << ":" << item.count; } file << "\n"; return !file.fail(); }

加载函数就是反过来逐行读取。写存档最容易出的问题是指针没保存——存档里只放坐标、数值、物品ID，不要把怪物对象的指针或者vector的迭代器写进文件，进程重启后这些地址全部失效。另外建议在写文件前先把数据合并到内存缓冲区，一次性写入，避免中途崩溃留下半个存档；简单做法是先用std::stringstream拼好内容，再一次write到文件。

5.3 楼层生成与难度曲线的控制

每下一层，地图重新随机生成，怪物的攻击、生命值按楼层数线性增长。我用一个floorLevel变量记录当前楼层，进入下一层时调用generateFloor(floorLevel)重开一张图。难点在于要保证出生点没有怪、楼梯旁没有堵死的通道，这些检查都要在生成阶段完成，不能在玩家进入后才修补。

void generateFloor(int level) { gameMap = generateMap(30 + level * 2, 20 + level); // 地图随层数微增 placePlayerAtStairs(true); // 玩家出生在楼梯口 spawnEnemies(level + 3); // 怪物数量随层数增加 ensurePathToStairs(); // 检查所有房间可达性 }

ensurePathToStairs这一步很容易被忽略。MST连接只能保证房间之间连通，但如果后续开墙、刷怪盖住了通道，可能出现玩家被围死的情况。建议在生成结束后做一个BFS，从出生点到楼梯跑一遍，跑不通就重新生成地图——概率非常低，但一旦发生就是必死局，玩家会直接卸载游戏。

6. 避坑与常见问题：C++肉鸽开发里最典型的5个坑

6.1 数组越界导致的间歇性崩溃

现象：游戏运行一段时间后随机崩溃，有时候走几步就崩，有时候十分钟才崩，调试器定位到的代码行每次都不同。

原因：地图访问越界。tiles[y][x]中如果x或y超过vector的尺寸，C++不做边界检查，行为是未定义的。越界可能改写相邻的内存区域，破坏其他对象的数据，等到真正崩溃时已经是几万条指令之后了。

解决：所有地图访问统一走isWalkable这样的封装函数，确保每次访问前都有边界检查。不要在游戏逻辑里出现裸的map.tiles[y][x]访问，一旦出现就该敲警钟。

6.2 随机数种子没初始化导致每局地图一样

现象：每次启动游戏，第一层地图完全相同，怪物掉落也一模一样。

原因：用了rand()但没有调用srand(time(NULL))，或者直接用了mt19937 rng;而没传种子。无种子的mt19937每次产生的序列是确定性的，这等于地图根本没随机。

解决：用std::chrono::steady_clock的纳秒时间戳做种子，或者更稳的方案是把种子也写进存档——这样玩家读档之后能恢复完全相同的地图序列，不会出现「读档后地图变化」的严重体验问题。

6.3 坐标传参顺序混淆：先X还是先Y

现象：怪物生成的位置总是偏的，或者走廊挖出来是斜的。

原因：C++中map[y][x]的第一个索引是行（Y轴），第二个是列（X轴），但很多人在定义函数参数时习惯写成(x, y)。一旦在某个函数里把map[player.x][player.y]当成了访问方式，渲染和逻辑就会同时出错。

解决：统一约定。我建议所有接口函数都按(x, y)传参，内部访问数组时再统一翻转成tiles[y][x]。在GameMap的封装里加注释明确这个约定，能救回几个小时的调试时间。

6.4 存档文件损坏后游戏直接崩溃

现象：读档时报错、乱码、或者读一半崩溃。

原因：存档文件被写坏，比如程序中途断电导致只写了一半。读取时没做校验，直接按预期字段解析，遇到缺失数据就访问了不存在的索引。

解决：在存档开头写一个版本号和魔数（比如SLIME_HUNTER_SAVE_V1），读取时先校验，不匹配就返回失败并提示「存档损坏」。每个关键字段读取后做合理性检查——比如player.hp小于0就重置为1、map.width超出合理范围就用默认值，不要轻信磁盘上的数据。

6.5 怪物AI卡死在墙边不动

现象：怪物贴着墙壁抖动，玩家在拐角另一侧攻击它，它却不还手。

原因：追踪逻辑里如果水平方向和垂直方向都被挡，怪物就会原地待着。对于简化的AI，它没有能力绕路，卡墙是必然结果。

解决：在AI里加一条「斜向移动」兜底，让怪物沿墙滑行；如果还是卡住，就让怪物随机选择一个可行走方向移动一步，破坏僵局。对于Slime-Hunter这个规模，BFS寻路是第一层的解法，但我建议先用兜底逻辑跑起来，真觉得AI太蠢再升级寻路——做肉鸽游戏的节奏是「先能玩，再变好」。

7. 从Demo走向完整作品：给Slime-Hunter加技能的技巧与验证方法

7.1 用状态效果系统扩展战斗维度

打完基础框架后，下一步往往是给史莱姆加「黏液」「中毒」之类的技能效果。不要为每个技能单独写一个逻辑分支，而是做一个StatusEffect系统——结构体里放效果类型、持续回合数、每回合伤害，挂在玩家或怪物身上，在每个回合开始时统一结算。

struct StatusEffect { enum Type { NONE, POISON, SLOW, STUN } type; int duration; int damagePerTurn; }; void applyStatusEffects(Player& player) { for (auto it = player.effects.begin(); it != player.effects.end();) { if (it->type == StatusEffect::POISON) { player.hp -= it->damagePerTurn; } if (it->type == StatusEffect::STUN) { // 眩晕状态下跳过玩家行动 } it->duration--; if (it->duration <= 0) { it = player.effects.erase(it); } else { ++it; } } }

效果系统的核心是「统一结算、时间衰减、自动移除」。新加一种效果只需要定义新的枚举值和结算逻辑，不用改战斗主循环。状态效果是肉鸽游戏做深度的利器——它能跨越单个战斗回合，让玩家的决策延伸到未来3到5个回合。

7.2 如何验证地图生成质量：三个量化指标

地图生成是最容易「看起来随机但实际不均衡」的部分。我用三个指标来检查：

写一个测试函数循环生成100张图，统计这三个指标的分布。如果连通性不是100%，说明生成逻辑有bug；如果冗余度超过1.5，说明补充的环路边太多，地图会失去「走廊探索」的味道——各路都能跑，反而没有方向感。

7.3 我自己的验证步骤与收尾心得

我的习惯做法是：先跑20局自动测试——用一个脚本模拟随机操作1000个回合，确认没有崩溃、没有卡死；再手动玩5局，重点感受前10个回合的战斗节奏。肉鸽游戏的平衡不是算出来的，是玩出来的。数值上看似合理，实际玩起来可能30分钟就腻了，这只能靠反复试。

做这种C++小游戏，最大的坑其实不是技术，而是「做得太复杂」。Slime-Hunter如果一上来就搞技能树、合成系统、多职业，很可能三个月后还是一堆半成品文件。先把地图、战斗、掉落、存档这四个闭环跑通，哪怕画面是黑白字符，它已经是一个完整游戏了。之后每一个新系统都在这条主线上加，加一个就保一个，这才是独立开发者该有的节奏。

回头看我做这类项目最值钱的习惯，就是每个环节都留一个验证入口——地图生成写完跑自动化测试，战斗写完调数值脚本，存档写完测断电恢复。这套习惯帮我避免了很多次「改一行代码、崩三个地方」的翻车体验。希望这些路径和坑位对你正在写的Slime-Hunter有所帮助，动手就比空想强，先跑起来再说。

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