1. 为什么用 EasyX 做迷宫游戏是个被低估的练手项目很多人学完 C 基础语法之后最大的困惑就是我该拿什么练手。刷算法题太枯燥写控制台程序又觉得没成就感想碰图形界面吧Qt 太重、DirectX 太底层、Unity 又跑到 C# 那边去了。我当年也卡在这个阶段很久直到后来重新捡起 EasyX 这个库才发现用它来做一个小型迷宫游戏几乎是 C 初学者从会语法到能做出东西之间最短的一条路。EasyX 本质上是一个面向 C 的轻量级图形库它把 Windows 下那套繁琐的 GDI 绘图接口封装成了非常直观的函数比如initgraph开窗口、circle画圆、fillrectangle填充矩形、getmessage取消息。你不需要理解窗口过程、消息循环、设备上下文这些概念就能在屏幕上画出东西。这一点对初学者极其友好——它让你把注意力放在游戏逻辑上而不是怎么让窗口显示出来。而迷宫游戏这个题材恰好是一个麻雀虽小五脏俱全的载体。它同时包含了几个游戏开发的核心要素地图数据的表示与存储、玩家状态的维护、键盘输入的实时响应、碰撞检测、渲染刷新、以及胜负判定。你把这几个东西跑通一遍基本上就摸到了 2D 游戏开发的骨架。更关键的是迷宫的复杂度可以自由伸缩——你可以先做一个固定地图的版本再升级成随机生成再加计时、步数统计、关卡递进难度曲线完全由你自己控制。这篇文章我打算按真实的开发顺序来讲从环境搭建、地图数据结构设计、渲染循环、输入处理一直讲到随机迷宫生成和几个容易踩的坑。中间会穿插我自己写的时候遇到的实际问题比如画面闪烁、按键响应迟钝、数组越界导致的花屏等等。适合已经学过 C 基本语法变量、循环、数组、函数、类但没怎么做过图形项目的朋友也适合想找个周末小项目练手的人。提示本文所有代码基于 EasyX 的常见版本接口编写不同版本个别函数名可能有细微差异遇到编译报错优先查你本地头文件里的函数声明。2. 环境准备与第一个能跑起来的窗口2.1 EasyX 的安装与工程配置EasyX 的安装方式这些年变过几次早期是直接给 VS 装插件后来也支持手动配置。不管哪种方式核心就是三件事头文件能被找到、库文件能被链接、运行时依赖能被加载。我建议直接用官方提供的安装程序它会自动识别你机器上的 Visual Studio 版本并把文件放到对应目录省去手动配置包含目录和库目录的麻烦。装完之后新建一个空项目写下面这段最小验证代码#include graphics.h #include conio.h int main() { initgraph(640, 480); // 创建 640x480 的窗口 setbkcolor(WHITE); // 设置背景色为白色 cleardevice(); // 用背景色清屏 setlinecolor(BLACK); circle(320, 240, 100); // 在屏幕中心画个圆 _getch(); // 等待按键防止窗口一闪而过 closegraph(); // 关闭图形窗口 return 0; }如果这段代码能弹出一个白底黑圆的窗口说明环境没问题。这里有个新手特别容易犯的错忘了写_getch()或者closegraph()。前者会导致窗口一闪就没了后者虽然程序结束也会释放但显式关闭是好习惯。另外initgraph的坐标原点是左上角x 向右增大y 向下增大这跟数学坐标系是反的画图的时候脑子里要时刻记着这一点不然位置会算错。2.2 双缓冲解决画面闪烁的第一课如果你直接在主循环里cleardevice()然后重画所有东西跑起来大概率会看到明显的闪烁。原因很简单清屏和重绘之间有个时间差屏幕会先显示全空的状态再显示新画面人眼就捕捉到了这个中间态。解决办法就是双缓冲——所有绘制先画到内存里的一张后台画布上画完一次性贴到屏幕上。EasyX 提供了两种做法。一种是手动用BeginBatchDraw()和FlushBatchDraw()BeginBatchDraw(); while (true) { cleardevice(); // ... 所有绘制操作 ... FlushBatchDraw(); // 一次性提交 Sleep(16); // 约 60 帧 } EndBatchDraw();另一种是创建 IMAGE 对象作为缓冲用SetWorkingImage切换绘制目标。对于迷宫这种规模的项目第一种批量绘制的方式已经足够代码也更简洁。我实测下来加上批量绘制之后闪烁基本消失画面变得很稳。注意Sleep(16)这个值不是随便写的。16 毫秒大约对应 60 帧每秒是游戏循环里很常用的节拍。如果你不加 Sleep循环会跑满 CPU风扇狂转不说还可能因为刷新太快导致输入响应异常。3. 迷宫地图到底该怎么存从二维数组说起3.1 用二维数组表示墙体与通路迷宫最自然的表示方式就是二维数组。假设每个格子是 40x40 像素一个 15x15 的迷宫就是 600x600 的窗口。数组里每个元素代表这个格子的类型比如 0 表示通路、1 表示墙、2 表示终点、3 表示玩家起点。这种表示法直观、访问快、遍历方便是绝大多数 2D 迷宫游戏的首选。const int ROWS 15; const int COLS 15; const int CELL 40; // 每格像素 int map[ROWS][COLS] { {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,0,0,0,1,0,0,0,0,0,1,0,0,0,1}, {1,0,1,0,1,0,1,1,1,0,1,0,1,0,1}, // ... 省略若干行 ... {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1} };这里有个设计上的取舍值得说清楚为什么用 int 而不是 bool 或者 char因为迷宫格子往往不止墙/路两种状态后面你可能想加陷阱传送门钥匙门这些元素用 int 预留了扩展空间。如果一开始就用 bool后期改起来要动很多地方。这是我在做第二个版本时才意识到的教训——第一版用 bool 写完加道具系统时几乎重写了一遍地图逻辑。3.2 坐标换算格子坐标与像素坐标的转换游戏里有两套坐标系一套是逻辑上的第几行第几列一套是屏幕上的多少像素。这两套之间必须能自由转换否则渲染和碰撞检测都会乱。转换公式很简单像素 x 列号 × CELL像素 y 行号 × CELL反过来给定一个像素点它落在哪个格子列号 像素 x / CELL行号 像素 y / CELL我建议把这两个转换封装成函数比如cellToPixel和pixelToCell别到处手写乘除法。因为一旦你改了 CELL 的大小散落各处的硬编码就会变成灾难。这个习惯在项目稍微大一点之后价值极高。3.3 玩家状态与地图的关系玩家本质上就是地图上的一个动态格子。我通常用一个结构体或者类来存struct Player { int row; int col; };玩家的移动逻辑就是根据按键方向算出目标格子的行列号检查那个格子是不是墙不是墙就更新玩家的行列号。这里的关键是先判断再移动而不是先移动再回退。前者逻辑清晰后者容易在边界情况下出 bug。提示判断目标格子是否合法时别忘了检查数组边界。玩家站在最外圈时往外的方向算出来的行列号可能是 -1 或者 ROWS直接访问数组就是越界轻则花屏重则崩溃。这个坑我踩过不止一次。4. 渲染循环与键盘输入让迷宫活起来4.1 游戏主循环的标准结构一个 2D 游戏的主循环本质上就是处理输入 → 更新状态 → 渲染画面这三步不断重复。用伪代码表示while (running) { handleInput(); // 读键盘更新玩家位置 update(); // 处理游戏逻辑比如判定胜负 render(); // 清屏 重画地图和玩家 Sleep(16); }这个结构看起来简单但每一步都有讲究。handleInput里如果用阻塞式的getch()游戏就会卡在等按键上画面不刷新。所以必须用非阻塞的按键检测。EasyX 提供了_kbhit()来判断有没有按键配合_getch()读取就能实现有键才处理没键继续跑的效果。if (_kbhit()) { int key _getch(); // 处理方向键 }4.2 方向键的读取与连续移动方向键在 Windows 下比较特殊_getch()第一次返回的是 224扩展键标志第二次才返回具体的方向码。所以读方向键要连着读两次if (_kbhit()) { int key _getch(); if (key 224) { int dir _getch(); switch (dir) { case 72: tryMove(-1, 0); break; // 上 case 80: tryMove(1, 0); break; // 下 case 75: tryMove(0, -1); break; // 左 case 77: tryMove(0, 1); break; // 右 } } }这里有个体验上的细节按住方向键不放时Windows 会连续发送按键消息所以玩家可以持续移动。但如果你想要更顺滑的移动手感可以自己维护一个按键按下状态在主循环里根据状态每帧移动一次而不是依赖系统的重复率。后者在快速连按和长按之间会有不一致的感觉。我第一版用的是系统重复玩起来一顿一顿的后来改成状态驱动才顺滑。4.3 渲染顺序与性能考量渲染的时候顺序很重要。我的习惯是先画静态的地图再画动态的玩家。因为地图每帧都要重画清屏之后而玩家只有一个格子画在最后能保证它永远在最上层不会被墙盖住。对于迷宫这种规模每帧重画所有格子完全没问题15x15 也就 225 个矩形。但如果你想优化可以把静态地图预先画到一张 IMAGE 上每帧只贴这张图再单独画玩家。这样能省下大量重复的绘图调用。不过说实话对于这种小游戏优化带来的收益微乎其微代码复杂度反而上升我建议先跑通再优化别过早陷入性能焦虑。void render() { cleardevice(); for (int r 0; r ROWS; r) { for (int c 0; c COLS; c) { int x c * CELL; int y r * CELL; if (map[r][c] 1) { setfillcolor(BLACK); fillrectangle(x, y, x CELL, y CELL); } else { setfillcolor(WHITE); fillrectangle(x, y, x CELL, y CELL); } } } // 画玩家 setfillcolor(RED); int px player.col * CELL; int py player.row * CELL; fillrectangle(px, py, px CELL, py CELL); }5. 随机迷宫生成从固定地图到无限关卡5.1 为什么固定地图不够用固定地图的版本写完之后你会发现一个问题玩两遍就腻了。迷宫游戏的乐趣很大一部分来自探索未知如果每次进去都是同一张图那跟背答案没区别。所以随机生成几乎是这个项目的必经升级。而且随机生成本身是个很有意思的算法话题能让你接触到递归、栈、并查集这些数据结构。5.2 深度优先搜索生成法递归回溯最经典的迷宫生成算法是递归回溯也叫深度优先搜索生成。它的思路是从起点开始随机选一个没访问过的邻居打通中间的墙走到那个邻居继续这个过程如果四个方向都走过了就回退到上一个格子直到所有格子都被访问。这里的关键是把迷宫看成格子 墙的网格。假设迷宫是 N×N 个格子那么墙的网格是 (2N1)×(2N1)。初始时全是墙然后从某个格子开始挖路。这样生成的迷宫保证任意两点之间有且只有一条路径也就是完美迷宫。void carve(int r, int c) { visited[r][c] true; map[r * 2 1][c * 2 1] 0; // 打通当前格子 int dirs[4][2] {{-1,0},{1,0},{0,-1},{0,1}}; // 随机打乱方向 for (int i 0; i 4; i) { int j rand() % 4; swap(dirs[i], dirs[j]); } for (int i 0; i 4; i) { int nr r dirs[i][0]; int nc c dirs[i][1]; if (nr 0 nr N nc 0 nc N !visited[nr][nc]) { // 打通中间的墙 map[r * 2 1 dirs[i][0]][c * 2 1 dirs[i][1]] 0; carve(nr, nc); } } }递归深度在 N 较大时可能爆栈比如 N50 时递归深度能到 2500 层。如果遇到栈溢出可以改成用显式栈的迭代版本。我实测 N15 的时候递归完全没问题但如果你要做大迷宫记得提前考虑这一点。5.3 起点终点的选取与难度控制生成完迷宫之后起点和终点怎么选也有讲究。最简单的做法是起点固定在左上角终点固定在右下角。但这样每次的挑战性其实差不多。更好的做法是随机选两个距离较远的格子或者干脆用 BFS 算出最远的一对点作为起终点保证每次都有足够的探索距离。难度控制可以通过几个维度调节迷宫尺寸、是否有岔路死路完美迷宫死路多可以打通一些墙制造环路降低难度、是否加计时限制。我个人的经验是15×15 的完美迷宫对新手刚好走完大概需要一两分钟既有挑战又不至于让人烦躁。6. 那些让我卡了半天的坑与调试心得6.1 数组越界导致的花屏与崩溃前面提过边界检查这里展开说。玩家在最外圈往墙外走时如果没做边界判断map[-1][c]这种访问会读到数组前面的内存map[ROWS][c]会读到后面的内存。这些内存里可能是别的变量也可能是垃圾值。如果恰好读到 0玩家就会穿墙跑到地图外面如果读到非 0可能看起来正常但下次访问就更离谱。最坏的情况是写操作越界直接破坏其他数据导致崩溃。我的做法是在tryMove里统一做检查bool canMove(int r, int c) { if (r 0 || r ROWS || c 0 || c COLS) return false; return map[r][c] ! 1; }这个函数是所有移动的唯一入口只要它写对了就不会越界。把边界检查集中在一处比散落在各个方向判断里要可靠得多。6.2 按键响应迟钝的排查过程我遇到过一个很典型的问题按方向键之后玩家要过一小会儿才动而且连续按的时候偶尔会丢按键。排查了半天发现是Sleep的位置不对。我一开始把Sleep(50)放在了输入处理之后、渲染之前导致每次循环都要等 50 毫秒按键消息在队列里堆积处理不及时。后来我把 Sleep 调小到 16并且确保每帧只处理一次输入问题就解决了。这里的原则是输入处理要快渲染节拍要稳。如果输入处理本身耗时比如复杂的路径计算要考虑把它和渲染解耦。6.3 清屏与重绘的顺序陷阱还有一个坑是清屏的时机。我一开始在循环开头cleardevice()然后画地图、画玩家。看起来没问题但如果某一帧因为逻辑分支提前continue了就会跳过绘制屏幕上留下上一帧的残影。解决办法是保证每帧的绘制路径是完整的或者用双缓冲让残影在提交前就被覆盖。另外cleardevice()用的是当前背景色如果你中途改了背景色忘了改回来清屏颜色就会不对。我建议在初始化时设一次背景色之后别再动它。6.4 用调试输出定位逻辑错误图形程序的调试比控制台麻烦因为你看不到中间变量。我的习惯是在关键位置用printf或者写日志文件把玩家的行列号、目标格子的值、判定结果打出来。比如移动失败时打印目标格子是墙坐标 (r,c)一眼就能看出是逻辑错了还是数据错了。EasyX 里也可以用outtextxy直接在窗口上画调试文字但要注意它会和游戏画面重叠调试完记得删掉。我一般只在开发阶段用发布前全部清理。7. 从能玩到好玩几个值得加的扩展方向7.1 计时与步数统计加一个计时器和步数计数器能让游戏有刷成绩的动力。计时可以用GetTickCount()或者clock()在游戏开始时记下起始时间每帧算差值显示在窗口角落。步数就是每次成功移动加一。这两个数据用outtextxy画在窗口顶部或者侧边就行。这里有个小细节计时器要在玩家第一次移动后才开始否则玩家盯着迷宫思考的时间也算进去不太公平。这个体验上的优化是我玩了别人的版本之后才想到的。7.2 关卡递进与难度曲线做完一关之后自动进入下一关迷宫尺寸逐渐增大或者时间限制逐渐收紧这样就有了持续玩的动力。实现上就是维护一个level变量通关后level重新生成迷宫。难度参数可以根据 level 动态调整比如尺寸 11 level * 2。7.3 视野限制与迷雾效果如果想让游戏更有紧张感可以加迷雾——只显示玩家周围一定范围内的地图其余部分用黑色盖住。实现方式是在渲染时判断每个格子到玩家的距离超过阈值就画成黑色。这个效果对渲染逻辑改动不大但游戏体验会完全不同从看图找路变成探索未知。7.4 存档与回放如果想再进阶可以把玩家的移动序列存下来实现回放功能。这需要把每次移动的方向记录下来回放时按顺序重放。这个功能本身不难但能让你接触到状态序列化的概念对理解游戏存档机制有帮助。8. 我在这类小项目里总结的几条经验做迷宫游戏这个项目前后我大概重写了两三遍每次都能发现新的问题。最大的体会是别一上来就追求功能齐全。第一版就做固定地图、能走、能到终点跑通了再加随机生成再加计时再加迷雾。每加一个功能都保证当前版本是能跑的这样出问题的时候范围很小容易定位。另一个体会是关于代码组织。一开始我把所有逻辑塞在main里几百行下来自己都看不懂。后来拆成init、generateMaze、handleInput、update、render几个函数每个函数只干一件事改起来就轻松多了。如果项目再大一点可以考虑用类把地图、玩家、游戏状态封装起来但小项目里函数拆分已经够用。最后说个心态上的事图形编程初期最容易受挫的就是明明逻辑对画面就是不对。这时候别急着怀疑人生先检查坐标换算、检查绘制顺序、检查有没有忘记清屏。十有八九是这些基础问题。把这几样排查一遍大部分诡异现象都能解释清楚。等你把迷宫跑通再回头看那些闪烁、越界、按键迟钝的问题会发现它们其实都是同一类状态没管好的毛病理解了本质以后做别的 2D 项目也能举一反三。