简介：VC6雷霆战机C++源码是一份基于Win32 API（而非MFC）编写的飞行射击游戏完整工程，面向想把C++语法用于真实项目的初学者，能有效解决缺乏实战项目、难以上手Windows程序开发的问题。压缩包共99个文件，大小仅1.83MB，包含26个bmp位图、22个h头文件、21个cpp源文件、16个wav和4个mid音频，另有dsp/dsw工程文件、rc资源描述和可直接运行的exe，覆盖素材、代码、工程配置与可执行程序。已有901人学习下载，代码在游戏循环、GDI绘图、窗口消息处理、碰撞检测、内存管理、资源加载等方面提供了清晰示范，且各模块按cpp与h文件组织，便于对照学习，有助于理解游戏对象组织与Win32 API实际调用。通过阅读源码并配合位图与音频资源，能够直观看到媒体文件如何被加载、绘制和播放，从而快速建立C++项目级开发经验，为后续学习游戏编程打下扎实基础。 前阵子翻旧硬盘，找到一个VC6工程，打开一看，居然是当年在宿舍熬夜写的雷霆战机C++源码。编译一遍居然还能跑，看着控制台里一堆字符拼出来的飞机上下翻飞，子弹像模像样地打出去，敌机一架架炸开，还真有点感慨。VC6这个开发环境，老归老，但承载了太多人写游戏的第一行代码。如果你正想学C++，或者对游戏开发感兴趣但不知道从哪里下手，这个项目可以说是最合适的练手素材——没有复杂的引擎依赖，没有看不懂的框架，就是纯C++代码、基础数据结构、还有一点初级的算法，把一个完整的弹幕射击游戏从零到一搭起来。
这个项目的价值在于：它把C++的语法、数组、指针、结构体、函数调用、循环控制这些零散知识点，在一个真实项目里全部串起来了。你需要的不是高深的理论，而是动手把代码敲出来、跑起来、改起来。我会把整个项目的设计思路、核心数据结构的定义、每个模块的编写过程，还有我在调试中踩过的坑，都拆开揉碎讲给你听，保证你照着做也能写出一份能玩的雷霆战机。
1. 项目整体思路：为什么还在用 VC6 写游戏
1.1 从零勾勒“雷霆战机”的核心玩法
雷霆战机在游戏类型上属于纵版弹幕射击（STG），核心玩法并不复杂：玩家控制一架飞机在屏幕底部移动，通过发射子弹消灭从上方不断出现的敌机，同时要躲避敌方子弹和敌机碰撞。一个最小可玩版本需要的功能是：玩家飞机的移动与射击、敌机的生成与移动、子弹的运动、碰撞检测、计分和游戏结束判定。
这些功能拆到C++代码里，本质上就是几件重复的事：不停更新位置、不停判断碰撞、不停绘制画面。所以，我们不需要引入任何游戏引擎，只需要把“游戏循环”这个概念想清楚：程序在循环里做三件事——接收输入、更新游戏状态、绘制画面，然后循环往复，直到游戏结束。这种循环在VC6的控制台程序里实现起来非常直观。
1.2 技术选型：控制台、EasyX 还是 Win32
写这个项目时我用的是纯控制台方案，也就是在黑色命令行窗口里用字符拼画面。这个方案的好处有三个：第一，不依赖任何第三方图形库，拷贝任何一个VC6环境都能编译；第二，字符画对坐标计算的要求很直白，可以把注意力集中在游戏逻辑上；第三，它天然逼你去手动处理“渲染”问题，比如屏幕闪烁，反而能把双缓冲这类概念学明白。
如果你想要更华丽的画面，可以在VC6里用EasyX图形库。EasyX在VC6下有对应的旧版本，直接包含graphics.h就能画矩形、贴图，控制台的方案稍微调整一下也可以迁移过去。不过我不建议一上来就上图形库，控制台方案跑通整个游戏框架之后，再换EasyX其实是水到渠成的事。
1.3 对象管理：用数组和结构体撑起整个战场
飞机、敌机、子弹这些都是游戏“对象”。如果给每架飞机都单独声明一个变量，代码会写得让人崩溃。合理的做法是定义结构体，然后用数组来管理同类型的对象。比如敌机最多同时存在20架，就声明一个长度为20的敌方结构体数组；子弹最多同时存在50颗，就声明一个长度为50的子弹结构体数组。这个思路在游戏开发里叫“对象池”，你不需要动态分配内存，开局就把数组分配好，运行时只需要复用数组里的元素。
这里正好串起C++的多个关键知识点：结构体定义复合类型、数组管理同类型数据、遍历时用下标或指针访问对象、循环里加状态标记来控制对象的启用与禁用。可以说，把这段逻辑写明白了，你的C++基本功就扎实了一大截。
2. 核心数据结构与游戏循环设计
2.1 玩家、敌机、子弹的数据结构定义
在源码中，我定义了几个结构体来管理游戏对象，核心字段如下：
struct Plane { // 玩家飞机 int x; // 横坐标（列） int y; // 纵坐标（行） int hp; // 生命值 int score; // 当前分数 }; struct Enemy { // 敌机 int x, y; // 坐标 int hp; // 血量 int active; // 是否活跃（1存活，0死亡/未使用） int speed; // 下落速度 }; struct Bullet { // 子弹 int x, y; // 坐标 int active; // 是否存活 };用坐标而不是像素坐标，是控制台方案的特殊之处。控制台窗口的字符位置就是天然坐标系，横向用x表示列，纵向用y表示行。画飞机、画子弹，本质上就是把字符写到对应坐标。
全局对象这样声明：
#define MAX_ENEMY 20 #define MAX_BULLET 50 Plane player; Enemy enemies[MAX_ENEMY]; Bullet bullets[MAX_BULLET];数组里每一个元素都带一个active标记，表示这个对象当前是否“活着”。每次更新时，只处理active为真的元素。这比动态创建和删除对象简单可靠得多，也避免了频繁new和delete带来的内存碎片问题。
2.2 游戏主循环：输入、更新、渲染的固定节奏
游戏的核心是 while 循环：
void gotoXY(int x, int y); // 光标定位函数 void initGame(); // 初始化游戏 void input(); // 处理输入 void update(); // 更新游戏逻辑 void render(); // 绘制画面 int main() { initGame(); while (player.hp > 0) { input(); update(); render(); Sleep(50); // 控制帧率 } printf("Game Over! Score: %d\n", player.score); return 0; }这个循环里，Sleep(50)大约能让游戏以20帧每秒的速度运行。帧率太慢会显得卡顿，太快则根本看不清画面。控制台游戏要做的就是这种“延时循环”。
2.3 双缓冲渲染：让控制台画面不再闪烁
在控制台里画画面，最简单的方式是每次system("cls")清屏再重画。但这样做会产生明显的闪烁，因为清屏和绘图之间有间隙，人眼能感觉到屏幕在刷新。解决方法是“双缓冲”：先在一个内存数组里把完整画面绘制好，再一次性地把内存中的整幅画面输出到控制台。
具体做法是定义一个二维字符数组作为缓冲区，比如：
char screen[25][80]; // 25行，80列先清空这个数组，把飞机、子弹、敌机都“画”到数组的对应位置（其实就是往数组元素里放字符），最后用一个循环或者一次批量输出把整个数组内容打印到屏幕上。这样就不会闪烁，而且画面切换非常干净。屏幕缓冲区用二维数组来做，这里其实就踩到了热词里提到的“多维数组”，它最典型的应用场景就是这种逐行逐列写画布的操作。
3. 核心功能模块实现
3.1 键盘输入与玩家移动控制
获取键盘输入，在Windows控制台里最常用的函数是kbhit()和getch()。kbhit()用来检测键盘是否有键被按下，getch()用来获取被按下键的字符编码。方向键有特殊编码，通常是两个字节：第一个字节是0（或224），第二个字节才是真正的按键码。
我用一个input()函数统一处理：
void input() { int key; if (kbhit()) { key = getch(); if (key == 224) { // 方向键的第一个字节 key = getch(); switch (key) { case 72: player.y--; break; // 上 case 80: player.y++; break; // 下 case 75: player.x--; break; // 左 case 77: player.x++; break; // 右 } } else if (key == ' ') { fire(); // 空格键发射子弹 } } }移动前要检查边界，防止飞机超出屏幕范围，否则会出现数组越界或者画面边缘截断的问题。这个检查很简单：如果player.x小于边界就置为边界值，大于边界也做同样处理。
3.2 子弹与敌机管理
发射子弹的逻辑是：在玩家飞机的位置向下发射一颗子弹，也就是在子弹数组里找一个active为0的空位，把它设置为活跃，坐标放在玩家飞机的正前方。
void fire() { for (int i = 0; i < MAX_BULLET; i++) { if (bullets[i].active == 0) { bullets[i].active = 1; bullets[i].x = player.x; bullets[i].y = player.y - 1; break; } } }敌机的生成也是类似思路，但需要随机数来控制生成时机和位置：
void spawnEnemy() { if (rand() % 100 < 5) { // 每次更新有5%概率生成敌机 for (int i = 0; i < MAX_ENEMY; i++) { if (enemies[i].active == 0) { enemies[i].active = 1; enemies[i].x = rand() % 75 + 2; enemies[i].y = 1; enemies[i].hp = 1; enemies[i].speed = 1 + rand() % 3; break; } } } }这里的概率控制是重点。如果每次更新都按固定概率生成敌机，游戏难度会随着时间变化不够平滑。我在实际代码里加入了一个难度递增逻辑：随着分数的增加，rand() % 100的判定阈值从5逐步上升到15，这样后期敌机密度明显变大。你可以在update()里根据player.score动态调整生成概率，比如：int rate = 5 + player.score / 500; if (rand() % 100 < rate)。
3.3 碰撞检测：矩形区域判定的那种简单粗暴做法
碰撞检测是游戏能否成立的关键。在控制台字符游戏里，飞机和子弹都可以视为一个字符大小的矩形区域，所以碰撞检测几乎可以简化成坐标比较：两个对象占用的字符位置有重叠，就判定为碰撞。
比如玩家子弹命中敌机：
void checkCollision() { for (int i = 0; i < MAX_ENEMY; i++) { if (enemies[i].active == 0) continue; for (int j = 0; j < MAX_BULLET; j++) { if (bullets[j].active == 0) continue; if (bullets[j].x == enemies[i].x && (bullets[j].y == enemies[i].y || bullets[j].y == enemies[i].y + 1)) { bullets[j].active = 0; enemies[i].hp--; if (enemies[i].hp <= 0) { enemies[i].active = 0; player.score += 10; } break; } } // 敌机碰撞玩家 if (enemies[i].active && enemies[i].x == player.x && (enemies[i].y == player.y || enemies[i].y == player.y + 1)) { player.hp--; enemies[i].active = 0; } } }严格来说，这里的碰撞判定是“点重合”判断，对于字符画效果完全够用。字符在屏幕上本来就是一个点，如果要更精确，可以把碰撞区域扩展为矩形，用矩形的左上角坐标和宽高判断是否有交集。矩形碰撞判断的公式其实很经典：
bool hit(int ax, int ay, int aw, int ah, int bx, int by, int bw, int bh) { return ax < bx + bw && ax + aw > bx && ay < by + bh && ay + ah > by; }3.4 计分与游戏状态切换
计分逻辑很简单，击中一个敌人加10分，击毁后可以再额外加分，玩家死亡则游戏结束。状态切换可以用枚举值来管理，让游戏有“运行中”、“暂停”、“结束”几个状态。虽然这个最小版本里只有“运行中”和“结束”两个状态，但用枚举定义清楚，后续扩展菜单、暂停时就会轻松很多。
enum GameState { STATE_RUNNING, STATE_PAUSED, STATE_OVER };在while循环里，switch当前状态，根据状态决定调用哪些函数。这样代码结构清晰，也方便后面加功能。
4. 调试、踩坑与优化实录
4.1 在VC6里调试常见编译错误
这个源码最常用的编译环境就是VC6，但你如果第一次在VC6里打开工程，多半会遇到几个老熟人般的报错。
最常见的报错之一是“unexpected end of file while looking for precompiled header directive”，这是因为VC6默认开启了“预编译头”功能（stdafx.h），如果你没有把#include "stdafx.h"放在源文件第一行，或者工程里没有stdafx.h，编译器就会闹脾气。我的做法是：新建Win32 Console Application时直接选“An empty project”，之后自己创建.cpp文件，这样就不会被预编译头折磨。如果你接手一个已有工程，可以在工程设置里关闭“Precompiled Headers”，或者保证每个.cpp文件第一行都包含它。
另外一个高频报错是C2447“missing function header (old-style formal list?)”，多半是前面的函数定义少了一个大括号，或者是函数名写错了。这种错误在VC6里提示很不直观，我一般会先看编译器报错所在行，然后往上翻几十行检查括号配对，因为这个错的实际位置往往比报错位置靠前。
4.2 数组越界：游戏崩溃的头号元凶
在VC6里写雷霆战机，最容易踩的坑就是数组越界。比如子弹数量是50，但玩家连续按空格导致所有子弹都是活跃状态，又再发射时遍历寻找空位，可能会导致越界，或者找不到空位而跳出，这种情况还好。比较恶心的是：当你用下标i从0到49访问数组时没问题，但某处偶然写成了<=MAX_BULLET，访问了下标为50的元素——C++的数组下标越界不会像Java那样直接抛异常，它只会静默地破坏相邻内存。在VC6的Debug模式下，系统往往会弹出对话框告诉你内存损坏，在Release下则可能表现成游戏运行几分钟后莫名其妙地崩掉或者画面出现乱码。
我排查这种问题的方式是：在所有循环更新数组的地方检查下标范围。一个稳妥的做法是在每次循环里先加一个if判断，确保下标在合法区间内再访问。虽然会多写几行，但在一个20行的循环里是值得的。
4.3 游戏运行卡顿的隐性原因
如果你的游戏运行起来卡顿，多半不是逻辑太复杂，而是渲染方式的问题。如果你用system("cls")清屏再printf重绘，每一帧都要执行大量控制台IO操作，这在VC6下会非常慢。换成我前面提到的二维缓冲数组方案之后，卡顿问题会立刻消失。
还有一种情况：Sleep(50)和渲染耗时的总和偏大，导致帧率被拖得很低。这时候可以测量一下每帧实际耗时，通常的做法是在循环里记录timeGetTime()或者clock()，计算间隔，再动态调整Sleep时间。注意VC6的Sleep单位是毫秒，如果你在循环里既Sleep(50)又做了大量计算，一帧可能跑出80到100毫秒，游戏自然就拖沓了。
4.4 控制台中文乱码那些事
在VC6的源码里写中文注释或者中文输出，控制台经常出现乱码。这是因为VC6编辑器的默认编码和Windows控制台的代码页不一致。最简单的处理方案是：源码里少用中文，输出信息用英文或者拼音。如果一定要输出中文，可以在程序开头调用SetConsoleOutputCP(CP_UTF8)或SetConsoleOutputCP(936)，但不同Windows版本的兼容性略有差异。我当年的经验是：宁可代码注释用英文，也不折腾编码问题，免得在“中文乱码”上浪费一个晚上。
5. 后续扩展：从“能玩”到“好玩”
5.1 增加道具系统
现在的最小版本已经能打完一整局，但如果要让游戏更有可玩性，我建议先加道具系统。敌人被击毁后有一定概率掉落道具，道具用一个新增的结构体管理，类型用枚举表示：加速射击、双发子弹、护盾、炸弹。道具从敌机死亡位置往下掉落，碰到玩家飞机后生效。
这个扩展非常适合练手，因为道具本质上是一组新对象，和敌机、子弹的管理方式完全一致。你已经有了“active标记 + 数组遍历”的基础，新增一个道具数组只需要复刻之前的逻辑，几乎没什么新知识。
5.2 加入关卡波次与Boss战
再往深了做，就是关卡的波次管理。可以把每一波敌机出现的数量、频率、类型定义成一个数组表格，打完整张表就进入Boss战。Boss可以设计成一个大号的字符图形，血量几十点，会从不同角度发射子弹。Boss的子弹会更快、更密集，玩家碰撞到Boss子弹也会掉血。
波次系统看上去复杂，其实核心就是一个“阶段计数器”，每过一段时间或者每消灭若干敌人，就把计数器加1，更新敌机生成的参数。这样比纯随机生成更有节奏感。
5.3 用EasyX给游戏换上真正的画面
如果你觉得字符画实在不够好看，下一步可以尝试EasyX。在VC6下装好EasyX之后，把控制台的绘制逻辑替换成图形绘制：玩家飞机画成矩形或图片，子弹画成小圆点，背景可以加一张滚动图片。这个迁移过程需要改的主要是render()部分，游戏逻辑完全不用动。也就是说，你之前写的输入、更新、碰撞检测代码，在图形界面下全部照常使用，这就是“逻辑与渲染分离”的好处，也是这个小项目最有价值的工程经验之一。
我在实际做这个迁移时，最大的体会是：框架比细节重要。只要你在一开始就把逻辑和渲染的边界划分清楚，后面换渲染方案、加新玩法、修复bug，代价都极其小。反过来，如果一开始就图省事，把绘制和碰撞检测混在一起写，后面改一个显示字符都要动三个函数，维护起来非常痛苦。
把雷霆战机这个项目完整跑通，你的C++基础、数组理解、函数拆解能力都会有一个肉眼可见的提升。可能很多年之后你也会像我一样，在某次翻硬盘的时候遇到这个老工程，然后发现——当年的代码虽然简陋，但它真的让你第一次明白了什么叫做“自己动手做一个游戏”。如果你也想做个游戏练手，不用犹豫，就从这份VC6的C++源码开始。
本文还有配套的精品资源，点击获取
