C++塔防游戏开发：固定步长主循环与实体管理模型

简介：面向C++游戏开发入门者的植物大战僵尸复刻工程，以塔防玩法为载体，串联起面向对象建模、游戏主循环、矩形碰撞检测、僵尸寻路与资源管理等核心环节，适合已掌握C++基本语法、希望通过一个完整小项目理解游戏框架搭建的学生与自学者对照研读。压缩包为7z格式，共109个文件、约15.82MB：既有主源码与Visual Studio解决方案、工程配置文件，也有可直接运行的exe程序与mp3音效，并附带金币、阳光等游戏素材图；另有tlog、pdb、obj、idb、ilk等编译中间文件与调试符号，可据此还原作者的构建环境与调试过程。目前已有5883人学习下载。读者可从中获得一份可编译运行的工程骨架，参考其中类与对象的划分方式、主循环内状态更新与画面渲染的组织顺序，并借助调试符号排查编译链接问题，把零散的C++知识整合为可运行的游戏雏形。

1. 从「同一格放两株植物」说起：这套 C++ 塔防模型要解决什么

搜索 c++ 游戏开发 素材的人里，十个有八个想做植物大战僵尸。这个选题的吸引力在于它同时覆盖了网格布局、实体管理、定时器和碰撞判定四类基础问题，规模又刚好克制在课程设计或毕设能收尾的量级上。可真动手就会发现，难点从来不是「画一个豌豆射手」，而是「豌豆射手和僵尸在同一格相遇时谁先结算」「切窗口后僵尸突然瞬移一大截」这类模型层面的秩序问题。这套 C++ 塔防模型要解决的正是这件事：把经典游戏的玩法拆成可落地、可配置、可验证的数据结构与状态机，让没有引擎经验的开发者也能按模块推进、按模块自测。它适合三类人——课程设计要交可运行 Demo 的学生、毕设要做完整关卡系统的人、以及想从零练一遍 C++ 面向对象与游戏主循环的开发者。往下读，看到的是从需求拆到验收的完整链路，而不是一段跑起来就黑屏的示例代码。

2. 需求拆解与技术选型：把经典玩法压成六个可编码的模块

塔防游戏看着热闹，真正需要写代码的东西其实不多。把它拆开，无非是「一块固定尺寸的草坪、两种会自己行动的实体、一种飞出去就消失的实体、一套资源产出与消费规则、一张按时间轴排的出兵表、一份关卡数据」。这六件事定下来，剩下的都是围绕它们的边角工作。需求阶段最容易犯的错是直接把「好玩」翻译成代码，结果写出一堆互相引用的类，改动一个数值要重新编译整个工程。所以我一般会先做一件事：把每个玩法要素钉到具体的数据结构上，再决定渲染方式，最后才谈目录。

2.1 玩法要素到数据结构的映射

草坪是骨架。经典布局是 5 行 9 列，行是僵尸行进的固定轨道，列只决定了植物的横向位置。这个「行固定、列推进」的特性非常关键，它让碰撞判定从二维退化成一维：僵尸永远在自己那一行里走，子弹永远沿行飞，判定时只需要比较行号是否相等、横向距离是否小于阈值。如果一上来就搞全 2D 自由移动，碰撞检测立刻要引入四叉树或者网格分桶，工作量翻三倍且和原作手感不符。

表格里「草坪占用」这一行值得多说一句。它看起来和植物数组冗余，实际是处理「点击同一格」最省事的办法：种植前先查grid[r][c]是否为空，为空才允许，写完立刻把新植物的 id 填进去；植物死亡时按 id 反查清空。没有这张表，你就要每次遍历植物数组判断坐标，种植手感会随着植物数量增加而变差。

僵尸和子弹都不用完整的二维坐标，只保留row与x。x的单位我建议直接用「格」而不是像素，0 表示草坪最左端，9 表示最右端。这样速度写成「每秒 0.2 格」，数值调整和关卡设计是同一套语言，渲染时再乘cellW换成像素。这个约定一旦定下，后面所有模块都受益。

2.2 渲染与循环的选型取舍

渲染方式决定项目什么时候能给老师或评审看到画面，所以要先定。常见的两条路：

我的建议不是二选一，而是把渲染抽象成接口，先控制台跑通逻辑，再换图形库。核心层只吐「谁在哪、什么状态」，渲染层负责翻译。这样换渲染器时不用动一行战斗逻辑，答辩时也能讲清楚分层。

// render/IRenderer.h #pragma once #include <string> // 渲染层只接受"画什么"，不参与任何游戏规则计算 class IRenderer { public: virtual ~IRenderer() = default; virtual void clear() = 0; virtual void drawPlant(int row, int col, const std::string& id, int hp) = 0; virtual void drawZombie(int row, double x, const std::string& id, int hp) = 0; virtual void drawSun(int amount) = 0; virtual void present() = 0; // 一帧结束，控制台实现里就是换行刷屏 };

接口里刻意没有update，因为渲染不该推进时间。drawZombie的x是格单位，具体实现自己乘cellW，这条约定把「单位换算」的责任压在渲染层，核心层永远不出现像素。

2.3 目录与模块划分

模块划分按「谁依赖谁」来切，而不是按「谁像谁」。核心层不包含任何渲染头文件，数据层不包含任何实体头文件。

pvz/ ├── src/ │ ├── core/ # 时钟、随机数、网格配置 │ │ ├── FixedClock.h │ │ └── GridConfig.h │ ├── entity/ # Entity 基类与三类实体 │ │ ├── Entity.h │ │ ├── Plant.h │ │ ├── Zombie.h │ │ └── Projectile.h │ ├── system/ # 纯逻辑系统，不碰渲染 │ │ ├── EconomySystem.h │ │ ├── WaveSystem.h │ │ └── CombatSystem.h │ ├── data/ # 关卡配置与加载器 │ │ └── LevelLoader.h │ └── main.cpp ├── assets/ # 贴图与字体（控制台方案下可为空） └── tests/ # 无渲染的逻辑自测

tests/这个目录不是摆设。塔防的数值和判定很容易出错，但错误往往表现为「感觉不对」而不是崩溃，写几个不依赖画面的断言函数，比如「给僵尸 100 血打 5 发 20 伤子弹后 hp 应为 0」，比盯着屏幕数僵尸靠谱得多。

3. 总体架构设计：固定步长循环与三层实体职责划分

架构这块我只讲三件事：时间怎么走、对象怎么分层、坐标怎么换。这三件事定错了，后面每个模块都会带着病。

3.1 游戏主循环与固定时间步长

最朴素的写法是while(running){ dt = now - last; update(dt); draw(); }，然后把dt直接乘进速度里。这个写法在 60 帧机器上没问题，一到别人的电脑就翻车：帧率高的时候僵尸走得慢，帧率低的时候僵尸一帧跨半格直接穿模。原因很简单，浮点累加和离散判定不兼容，一步跨太大就跳过了判定窗口。

正确做法是固定步长：逻辑永远按 1/60 秒推进，真实帧只决定「这一帧要补几步」。

// core/FixedClock.h #pragma once class FixedClock { public: explicit FixedClock(double step = 1.0 / 60.0, int maxCatchUp = 5) : step_(step), maxCatchUp_(maxCatchUp) {} // 传入真实帧间隔，返回本次需要执行的逻辑步数 int tick(double realDelta) { if (realDelta > 0.25) realDelta = 0.25; // 断点/切窗口造成的时间尖峰，先截断 acc_ += realDelta; int steps = 0; while (acc_ >= step_ && steps < maxCatchUp_) { acc_ -= step_; ++steps; } if (steps == maxCatchUp_) acc_ = 0.0; // 追不上就丢弃余量，避免越补越卡 return steps; } double step() const { return step_; } private: double step_ = 1.0 / 60.0; double acc_ = 0.0; int maxCatchUp_ = 5; };

三个参数各有含义。step_是逻辑步长，1/60 秒足够让 0.2 格/秒的僵尸每步移动 0.0033 格，判定窗口不会被打穿；改成 1/30 也能跑，但高速子弹更容易漏判。maxCatchUp_是一次最多补几步，设 5 意味着单帧最多推进 5 步，防止掉帧时补步补到卡死。0.25那个截断是给调试用的，你在断点停 10 秒再继续，不截断就会瞬间补 600 步，僵尸直接瞬移到你家。丢余量那行是「后悔药」，宁可让时间稍微慢一点，也不要陷入补步越补越慢的死循环。

主循环就变成：

FixedClock clock; double last = nowSeconds(); while (running) { double cur = nowSeconds(); int steps = clock.tick(cur - last); last = cur; for (int i = 0; i < steps; ++i) { economy.update(clock.step()); waves.update(clock.step()); updateEntities(clock.step()); // 植物、僵尸、子弹统一推进 combat.resolve(); // 判定放在推进之后，避免同帧顺序歧义 } renderer.drawAll(); }

注意combat.resolve()在循环内、推进之后。判定和推进分开，是为了让「同一帧内新生成的子弹」不会立刻参与结算，顺序一旦固定，回放和自测才可复现。

3.2 实体分层：Plant / Zombie / Projectile 的公共基类

三类实体有共性：都有 id、都占一行、都要更新、都会死。抽一个基类出来，容器就能统一存放，遍历也只需要一次。

// entity/Entity.h #pragma once enum class EntityType { Plant, Zombie, Projectile, Sun }; class Entity { public: Entity(EntityType t, int row, double x, int hp) : type_(t), row_(row), x_(x), hp_(hp) {} virtual ~Entity() = default; virtual void update(double dt) = 0; // 只改自身状态，不访问其他实体 bool alive() const { return hp_ > 0 && !removed_; } void markRemoved() { removed_ = true; } void applyDamage(int dmg) { hp_ = (hp_ > dmg) ? hp_ - dmg : 0; } EntityType type() const { return type_; } int row() const { return row_; } double x() const { return x_; } // 单位：格 void setX(double v) { x_ = v; } protected: EntityType type_; int row_; double x_; int hp_; bool removed_ = false; // 延迟删除标记 };

removed_这个标记是血泪经验。很多人在遍历子弹数组时发现僵尸死了就erase，结果迭代器失效，程序在随机位置崩，调试器给出的栈还指在无辜的渲染函数里。正确做法是只打标记，遍历结束后统一清理。update的注释写着「只改自身状态」，这是纪律：植物不该知道僵尸在哪，僵尸也不该知道植物血量，跨实体的事情全部交给 system 层，否则实体之间会形成网状依赖，改一个数值要读五个文件。

3.3 网格坐标与世界坐标的双向换算

换算逻辑集中在一处，别散落在各模块里。

// core/GridConfig.h #pragma once struct GridConfig { int rows = 5; int cols = 9; int cellW = 80; int cellH = 100; int originX = 220; // 草坪左上角在窗口中的像素位置 int originY = 90; }; // 像素坐标 -> 行列，返回 false 表示点在草坪外 inline bool worldToCell(const GridConfig& g, int px, int py, int& outRow, int& outCol) { int cx = px - g.originX; int cy = py - g.originY; if (cx < 0 || cy < 0) return false; outCol = cx / g.cellW; outRow = cy / g.cellH; return outRow < g.rows && outCol < g.cols; } // 格子中心 -> 像素，用于摆放植物与子弹起点 inline void cellCenterToWorld(const GridConfig& g, int row, int col, int& px, int& py) { px = g.originX + col * g.cellW + g.cellW / 2; py = g.originY + row * g.cellH + g.cellH / 2; }

worldToCell里负数必须先判，因为 C++ 的整数除法对负数是向零取整，-1 / 80得 0，会把草坪左边界外的点击误判成第 0 列，表现出来就是「点到界面空白处也能种植物」。行优先还是列优先也要一次定死：这里数组下标是[row][col]，行对应僵尸轨道，别在某个模块里写成[col][row]，这种错误编译器不会报，只会让植物长在隔壁行。

4. 核心模块实现：阳光、波次与命中的三段关键代码

架构搭好之后，真正决定手感的是三个系统：资源、出兵、结算。这一段给的是可直接改参数复用的实现。

4.1 阳光经济与冷却计时器

阳光是整个玩法的节奏器。产得太快没有压力，太慢第一波就崩。经典数值是开局 50、天降阳光每 8 秒一个、单个 25 点、场上同时存在的阳光不超过 8 个。

// system/EconomySystem.h #pragma once #include <algorithm> class EconomySystem { public: void update(double dt) { sunTimer_ += dt; // 场上阳光达到上限时不再生成，防止挂机攒一堆 if (sunTimer_ >= kInterval && sunOnField_ < kMaxOnField) { sunTimer_ -= kInterval; sunOnField_++; } } bool trySpend(int cost) { if (sun_ < cost) return false; sun_ -= cost; return true; } void collectFieldSun(int n = 1) { sunOnField_ = std::max(0, sunOnField_ - n); sun_ = std::min(sun_ + 25, kCap); } int sun() const { return sun_; } private: static constexpr int kStart = 50; static constexpr int kCap = 9990; static constexpr double kInterval = 8.0; static constexpr int kMaxOnField = 8; int sun_ = kStart; int sunOnField_ = 0; double sunTimer_ = 0.0; };

trySpend先判断再扣，返回值让调用方决定后续动作，这个模式比「先扣再检查负数」稳。kCap设得很大是因为向日葵产出的阳光理论上能堆很高，不需要硬性限制。collectFieldSun里写成固定 25 只是示例，正式代码应该把阳光值的来源传给函数，因为不同植物产出的阳光数不一样。

植物卡片的冷却单独一个结构，别塞进植物实体里——卡片是界面元素，植物是场上实体，两者生命周期不同：

// 每张卡片一个，冷却期间不能重复种植 struct CardCooldown { double remain = 0.0; void update(double dt) { remain = (remain > dt) ? remain - dt : 0.0; } void trigger(double cd) { remain = cd; } bool ready() const { return remain <= 0.0; } };

remain > dt ? remain - dt : 0.0这行是为了避免浮点误差把冷却减成负数，导致「明明显示好了却点不动」这种玄学问题。

4.2 僵尸波次生成与状态机

波次表按时间轴排，扫描指针只前进不回退，这样每帧的开销和波次数量无关。

// system/WaveSystem.h #pragma once #include <vector> struct WaveEntry { double at; int count; int zombieType; }; class WaveSystem { public: void update(double dt) { if (cleared_) return; elapsed_ += dt; while (next_ < waves_.size() && elapsed_ >= waves_[next_].at) { spawn(waves_[next_]); ++next_; } // 全部波次放完且场上无存活僵尸，才算过关 if (next_ >= waves_.size() && aliveZombies_ == 0) { cleared_ = true; } } bool levelCleared() const { return cleared_; } void onZombieDied() { if (aliveZombies_ > 0) --aliveZombies_; } private: void spawn(const WaveEntry& w) { for (int i = 0; i < w.count; ++i) { // 同一波内的僵尸错开一点出发时间，避免叠在同一个像素上 pending_.push_back({ w.zombieType, i * 0.6 }); aliveZombies_++; } } struct PendingSpawn { int type; double delay; }; std::vector<WaveEntry> waves_; std::vector<PendingSpawn> pending_; size_t next_ = 0; double elapsed_ = 0.0; int aliveZombies_ = 0; bool cleared_ = false; };

僵尸本身用三态状态机就够了：行走、啃食、死亡。行走时横坐标按速度递减；脚点进入某格且该格有植物时切到啃食，按固定间隔扣植物血；植物死了切回行走。

enum class ZombieState { Walking, Eating, Dying }; void Zombie::update(double dt) { switch (state_) { case ZombieState::Walking: x_ -= speed_ * dt; // 速度单位：格/秒 if (x_ <= targetX_) { /* 触发啃食判定 */ } if (x_ < -1.0) markRemoved(); // 走到最左侧，判负 break; case ZombieState::Eating: eatTimer_ += dt; if (eatTimer_ >= kEatInterval) { eatTimer_ -= kEatInterval; /* 扣植物血 */ } break; case ZombieState::Dying: fadeTimer_ += dt; if (fadeTimer_ > 0.5) markRemoved(); break; } }

x_ < -1.0这个判负阈值给了一格余量，让僵尸完全走出画面再判失败，观感上更自然。

4.3 碰撞判定与伤害结算

判定只做两件事：子弹打僵尸、僵尸啃植物。因为行号已经固定，两者都能降成一维比较。

// system/CombatSystem.h void CombatSystem::resolveProjectiles(std::vector<Projectile>& shots, std::vector<Zombie>& zombies) { for (auto& p : shots) { if (!p.alive()) continue; for (auto& z : zombies) { if (!z.alive() || z.row() != p.row()) continue; // 容差 0.15 格，约等于 12 像素，太小会打不中移动中的僵尸 if (std::abs(z.x() - p.x()) < 0.15) { z.applyDamage(p.damage()); p.markRemoved(); break; // 一颗子弹只结算一个目标 } } } }

容差 0.15 格是关键参数。设成 0.05 会出现「子弹从僵尸身体里穿过去」的现象，因为子弹每帧前进的步长可能就接近这个值；设成 0.5 又会变成隔空命中。经验值是「子弹单帧位移」的 1.5 到 2 倍。子弹速度 0.5 格/秒、步长 1/60 秒时，单帧位移约 0.0083 格，0.15 有足够余量且不影响判定精度。

4.4 关卡数据外部化配置

数值写死在代码里，改一次难度就要重新编译，答辩现场想调都来不及。把关卡拆成 JSON，加载器负责解析，实体只认 id。

{ "level": 1, "grid": { "rows": 5, "cols": 9 }, "startSun": 50, "plants": [ { "id": "sunflower", "cost": 50, "hp": 300, "cooldown": 7.5, "produce": 25, "interval": 24.0 }, { "id": "peashooter", "cost": 100, "hp": 300, "cooldown": 7.5, "damage": 20, "rate": 1.5 } ], "zombies": [ { "id": "normal", "hp": 200, "speed": 0.22, "eat": 10 } ], "waves": [ { "at": 15.0, "count": 2, "zombie": "normal" }, { "at": 40.0, "count": 5, "zombie": "normal" }, { "at": 70.0, "count": 8, "zombie": "normal" } ] }

cooldown是卡片冷却秒数，rate是射击间隔秒数，speed是格/秒。加载时做一次校验：id 是否重复、cost是否为正、波次时间是否递增。校验放在加载阶段，比等到运行十分钟后才发现第 5 波时间是负数的成本低太多。

5. 避坑与排查：五个能让逻辑跑飞的常见问题

5.1 帧率一变游戏速度就变

现象：在自己机器上僵尸走得好好的，换台电脑或窗口失焦后回来，僵尸突然冲到左边，或者慢得像散步。 原因：把真实帧间隔直接乘进位移，帧率 30 和 144 得到的每帧位移差四倍，同时单帧跨步太大还会跳过命中容差。 解决：改成第 3.1 节的固定步长，真实帧只决定补几步，逻辑永远拿1/60。同时加时间尖峰截断，断点调试后不会瞬移。

5.2 遍历中删除实体导致随机崩溃

现象：僵尸被打死后偶尔闪退，栈顶指向一个和逻辑无关的函数，或者干脆是vector内部。 原因：在 range-for 里erase，迭代器失效，后续访问的是已释放内存。 解决：给实体加removed_标记，遍历只打标记，一帧结束统一remove_if。清理和遍历分开，顺序可控，也方便写自测。

5.3 点到草坪外也能种植物

现象：界面上方或左上角空白区域点击，植物出现在第 0 行第 0 列。 原因：worldToCell里没判负坐标，C++ 整数除法对负值向零取整，-3 / 80得 0，越界点击被算成合法格子。 解决：先判cx < 0 || cy < 0直接返回 false，再算行列并校验上界。这个坑很隐蔽，因为只有点草坪左侧才会触发。

5.4 阳光不够、冷却没好，但植物还是种下去了

现象：开局 50 阳光连点两下种了两株向日葵，经济直接起飞，测试时数值全乱。 原因：种植流程只查了格子是否为空，漏了资源和冷却校验，或者校验和实际扣除不在同一处。 解决：种植收敛到一个函数里，顺序固定为「格子空、卡片就绪、阳光足够、扣阳光、触发冷却、占格、生成实体」，任何一步失败立即返回并给出提示。所有修改入口只有这一个，别在别处再写一份。

5.5 关卡数据路径在别人电脑上找不到

现象：自己机器上跑得好好的，拷到实验室机器上贴图全白、配置读不到，日志里只有一句「文件打开失败」。 原因：用了相对路径且工作目录不同，或者资源文件名大小写和代码里写的不一致，在区分大小写的系统上直接失败。 解决：启动时先确定可执行文件所在目录，资源路径基于它拼接；大小写统一小写；加载失败要把尝试过的完整路径打出来，别只打「失败」。这算是最没技术含量但最耽误时间的坑。

6. 验收与答辩：一张可复现的检查表证明模型没崩

方案交出去之前，我习惯跑一遍固定的检查表，而不是靠「玩两把感觉还行」。检查表按模块列，每项都要能在三分钟内复现：

答辩演示顺序也有讲究。我一般按「先讲模型，再演示异常，最后调参数」三步走：先用一张图说清实体分层和固定步长，让评审知道这不是一堆 if 堆出来的；然后主动演示越界点击、阳光不足连点这两个反例，说明校验做在哪一层；最后现场打开 JSON 把第一波时间从 15 秒改成 5 秒，重启关卡立刻生效。第三步最能体现数据驱动的价值，也最容易让人记住。常见提问集中在「为什么不用引擎」「僵尸多了会不会卡」「怎么保证不同机器一致」，前两个用分层和降维判定回答，第三个直接把检查表第一项跑给他看。

从那以后我每次交付带实时循环的项目，都会先把「帧率无关」和「遍历中删除」这两条写进自测清单，不管多小的 Demo 都强制走一遍，因为这两个坑从来不会在演示前一分钟暴露，只会在演示当场暴露。希望这套拆解和检查表能帮到你，把那份方案稳稳地交出去。

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