简介一套基于C与Qt框架编写的飞机大战游戏完整源码面向已掌握基础语法、渴望通过实战巩固面向对象能力的C学习者也可作为游戏开发入门或课程设计的参考项目。源码包共55个文件、压缩后约2.45MB包含13个.cpp源文件与13个.h头文件分别实现主渲染、敌机控制、子弹管理、计分板等模块13个MP3音效负责背景音乐与打击反馈6张PNG贴图配合3个PSD源文件便于界面素材替换与二次调整另有Qt工程文件(.pro/.ui)、配置文件及readme说明文档整体目录分层明确可直接导入Qt Creator编译运行。已有2036人学习下载适合逐模块拆解C类设计、信号槽机制与绘图逻辑并可在现有架构上扩展关卡、道具和多人对战玩法。1. 飞机大战的C源码包下载之后你真的能跑起来吗很多人在网盘里下载了C语言编写的飞机大战游戏源码.zip解压后对着几个.cpp和.h文件发愣用Visual Studio打开报一堆链接错误用Dev-C打开发现编译器太老甚至有人把源码当Python脚本硬改。这个标题是C入门游戏最常见的样本——一个用图形库或Win32 API写的打飞机小游戏目标使用者是刚学完类与对象、想用完整项目巩固语法和调试能力的新手。它能解决的问题很具体让你把零散的C语法串成一条能玩的链路亲手跑起来而不是永远停在教材的课后题。这篇笔记从图形方案选型、主循环、碰撞检测一直写到真正的坑照着复现就能出效果。2. 图形方案选型与SDL2主循环先从能跑起来开始2.1 图形库三选一EasyX、SDL2还是Win32 API先回答一个绕不开的问题这个zip包里的代码究竟用什么做图形市面上流传的C飞机大战源码按图形方案分三类。EasyX是许多国内教材的首选因为安装简单、接口接近Windows图形设备接口但它是Windows专用且需要单独下载库文件SDL2跨平台、资源占用可控是多数从业者给你的推荐Win32 API的裸写版本则几乎以纯C风格为主结构松散好处是零依赖。判断你拿到的是哪一类最快的办法是看代码里有没有initgraph、SDL_Init或CreateWindowEx这三个函数名之一。图形方案依赖跨平台上手难度适合场景EasyX需单独安装库仅Windows低课程作业、语法复习SDL2需配置include/libWindows/Linux/macOS中想继续做游戏开发Win32 API系统自带仅Windows高想看底层窗口机制我带学员时会让先做一件事不要看业务逻辑先看图形库——这决定了你能不能在三十分钟内把它跑起来。EasyX版本通常一个项目就能编译SDL2需要你在链接器里加上SDL2main.lib和SDL2.libWin32 API版本则需要自己写窗口过程函数。我的建议是如果你只想复习C语法选EasyX版本最省心如果你想把项目放到Linux或后续扩展成小游戏引擎果断选SDL2并自己加一层窗口管理。判断失误的代价是编译错误像雪崩一样滚出来而多数错误与你的代码无关。2.2 用SDL2把最小主循环跑起来拿到SDL2版本源码之后第一件事是让它跑起来。这里给一个验证环境的最小可编译文件这段代码不算游戏逻辑只把窗口、事件循环和帧率控制这三大件立起来。#include SDL2/SDL.h int main(int argc, char* argv[]) { if (SDL_Init(SDL_INIT_VIDEO) ! 0) { SDL_Log(SDL初始化失败: %s, SDL_GetError()); return -1; } SDL_Window* window SDL_CreateWindow( C 飞机大战, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 800, 600, SDL_WINDOW_SHOWN); if (!window) { SDL_Log(窗口创建失败: %s, SDL_GetError()); SDL_Quit(); return -1; } SDL_Renderer* renderer SDL_CreateRenderer( window, -1, SDL_RENDERER_ACCELERATED); bool running true; SDL_Event event; const int targetFps 60; const Uint32 frameTime 1000 / targetFps; while (running) { Uint32 frameStart SDL_GetTicks(); while (SDL_PollEvent(event)) { if (event.type SDL_QUIT) running false; } SDL_RenderClear(renderer); SDL_RenderPresent(renderer); Uint32 elapsed SDL_GetTicks() - frameStart; if (elapsed frameTime) SDL_Delay(frameTime - elapsed); } SDL_DestroyRenderer(renderer); SDL_DestroyWindow(window); SDL_Quit(); return 0; }这段代码是任意SDL2项目的地基。SDL_Init只开启了视频子系统因为你暂时不需要音频和游戏手柄如果后续给游戏加音效要改成SDL_INIT_VIDEO | SDL_INIT_AUDIO。SDL_CreateRenderer的最后一个参数用SDL_RENDERER_ACCELERATED优先走硬件加速CPU占用会低得多。帧率控制用的是最朴素的延迟方案frameTime等于16毫秒实测误差可以接受追求更平滑可以改用SDL_RENDERER_PRESENTVSYNC配合垂直同步但这种方法帧率会被显示器刷新率锁死。提示编译时注意区分编译与链接。很多新手在VS Code里配好了C/C扩展cpp能编译却不知道要把SDL2的头文件目录加进includePath、把SDL2.lib路径加进linker flags。报错信息里出现“无法打开包含文件 SDL.h”是头文件路径问题出现“无法解析的外部符号 SDL_Init”才是库链接问题两个错误解法完全不同。用g编译这文件时命令大致长这样g main.cpp -I/usr/include/SDL2 -L/usr/lib/x86_64-linux-gnu -lSDL2 -o game-I指定SDL2头文件目录-L指定库文件目录-lSDL2链接动态库。Windows下使用MinGW时库路径要指向你下载的SDL2开发库的lib目录x64版和x86版不能混用编译目标平台必须和库的位数一致否则链接器会报一堆莫名其妙的unresolved external symbol。2.3 敌机随机生成stdlib的rand够用吗飞机大战的敌机生成是典型的随机数场景。很多源码直接调用rand() % 800作为敌机出现的x坐标在小规模demo里这没什么问题但如果你把游戏帧率提高到120 FPS会发现敌机出现位置有周期性——原因是rand()内部是线性同余生成器rand() % N会让低位数分布不均匀序列在大量调用后会自我重复。我一般建议换用C11的 库也就是热搜里常提到的C随机数用法非常直接。#include random std::mt19937 gen(std::random_device{}()); std::uniform_int_distributionint distX(0, 760); // 每帧调用一次生成敌机初始位置 int enemyX distX(gen);random_device是系统级熵源负责给mt19937一个种子uniform_int_distribution保证分布均匀。这个方案比rand() % N多写几行但它值得——当游戏加入道具掉落、暴击判定这类需求时一个可复现的随机种子是调试的救命稻草。把gen的种子固定下来比如改用std::mt19937 gen(42)你就能让敌机刷新的位置序列每次运行都完全一致这对复现“玩家第三关必被某颗子弹击中”的bug极其有效。3. 飞机、子弹与敌机把C的对象模型用起来3.1 继承和多态该用在哪里飞机大战里最常见的类设计是一个基类GameObject下面派生出Player、Enemy、Bullet。很多初学者一上来就把攻击逻辑塞进Player类里把子弹数组也挂在Player下面写到最后Player类膨胀到四百行。这是飞机大战源码里最常见的坏味道。真正的分工应该是GameObject只管位置、速度、存活状态和虚函数Update()与Render()Player处理键盘输入与射击节奏Enemy管移动模式与血量Bullet管方向和碰撞回调。继承在这里的价值是让对象数组能统一管理。class GameObject { public: float x, y; // 位置 float vx, vy; // 速度 bool alive true; virtual void Update(float dt) 0; virtual void Render(SDL_Renderer* renderer) 0; virtual ~GameObject() default; }; class Bullet : public GameObject { public: void Update(float dt) override { y vy * dt; // 沿Y轴向上飞 if (y -10) alive false; // 飞出屏幕标记回收 } void Render(SDL_Renderer* renderer) override { SDL_Rect rect {(int)x, (int)y, 4, 12}; SDL_SetRenderDrawColor(renderer, 255, 255, 0, 255); SDL_RenderFillRect(renderer, rect); } };注意Update里y vy * dt的dt是帧间隔秒数这样能让游戏在不同帧率下表现一致。dt单位是秒还是毫秒直接决定初始速度值如果dt是秒vy等于300就是每秒飞300像素如果dt是毫秒vy要写成0.3。看源码时先找到游戏循环里传进Update的那个值再调速度常量这是调试经验里最容易被忽略的一环。多态的价值在统一管理时出现。用一个std::vectorstd::unique_ptr 保存所有对象每帧遍历调用Update和Render碰撞判定时也只要遍历这个容器。unique_ptr比裸指针安全——子弹射完不需要手动delete容器析构时自动回收。你会在很多源码里看到裸指针delete的写法能跑但容易漏游戏里最典型的症状是子弹打多了内存占用持续上升最后崩溃。3.2 对象池为什么飞机大战要换掉vector new如果你在源码里看到每发射一颗子弹就new一个Bullet射完就delete恭喜你拿到了最有“教学味”的版本。但这种写法在子弹数量上到几百颗、敌人同屏几十个的时候会有明显卡顿原因是new/delete的分配开销和内存碎片。做游戏的人碰到这个问题常见的做法是对象池预先分配一个Bullet数组用alive标记区分可用与活跃对象。class BulletPool { static const int MAX_BULLETS 512; std::arrayBullet, MAX_BULLETS pool; public: Bullet* Spawn(float x, float y) { for (auto b : pool) { if (!b.alive) { b.alive true; b.x x; b.y y; return b; // 返回池内对象的地址 } } return nullptr; // 池满本帧放弃射击 } };这个池的实现思路是线性的——每次找第一个未存活的对象512个子弹的规模下循环开销可以忽略。池满时返回nullptr而不是扩容让射击方自行决定是静默丢弃还是播放空仓音效。这种取舍在游戏开发里很常见子弹是短暂资源满了优先丢弃而不是卡顿。对象池的好处不只性能更关键的是避免了delete延迟带来的悬空指针——碰撞检测在处理子弹时发现它已阵亡直接置alive为false对象的生命周期完全由池控制不会出现“碰撞回调时对象已经被释放”的未定义行为。还要注意Spawn返回的是池内对象的地址调用方不应该尝试delete它。如果你把Bullet塞进vectorGameObject再统一清理池方案就直接崩给你看——同一个地址在池析构和vector析构里被释放两次。常见做法是碰撞检测和对象池共享同一个数组碰撞命中时只置alive为false渲染和Update都跳过非存活对象整个游戏循环里不出现一次delete。3.3 玩家控制与边界约束玩家飞机的移动逻辑看似简单但按像素计算的键盘处理里有个经典的坑。如果你在Update里直接写x 5游戏90 FPS和30 FPS下移动速度差了3倍。正确的做法是把速度当作每秒像素数乘以帧间隔秒数。此外玩家飞机需要边界约束否则飞机飞出屏幕后还能继续射击敌人打你时你不在画面里判定逻辑全乱。void Player::Update(float dt, const Uint8* keyState) { float speed 300.0f; if (keyState[SDL_SCANCODE_LEFT]) x - speed * dt; if (keyState[SDL_SCANCODE_RIGHT]) x speed * dt; if (keyState[SDL_SCANCODE_UP]) y - speed * dt; if (keyState[SDL_SCANCODE_DOWN]) y speed * dt; const int screenW 800, screenH 600; if (x 0) x 0; if (x screenW - kPlayerWidth) x screenW - kPlayerWidth; if (y 0) y 0; if (y screenH - kPlayerHeight) y screenH - kPlayerHeight; }keyState取自SDL_GetKeyboardState(NULL)返回的指针由SDL内部管理调用方不要delete。边界约束用的是关卡尺寸而不是渲染器尺寸本身——如果游戏左侧有计分面板占掉120像素边界就应该是scorePanelWidth到screenW - kPlayerWidth。很多源码把边界写死在数字里导致调整窗口大小时玩家会飞出可视区这个坑在移植到不同分辨率时一定会炸。顺带说一句双人模式的实现。常见做法是为两个玩家各建一个Player实例第一人用WASD控制、第二人用方向键控制射击键分别设成左Ctrl和右Ctrl。键盘状态数组支持多键同时按下两个Update调用互不干扰唯一要处理的是两个玩家的子弹池要分开否则分不清谁打中了谁、分数该加给谁。4. 碰撞检测判定两架飞机撞没撞到远比你想象的复杂4.1 AABB碰撞检测的数学飞机大战的碰撞判定90%以上的源码采用AABB轴对齐包围盒做法把飞机和子弹都抽象成矩形然后检测两个矩形是否重叠。判断条件记住口诀两个矩形在X轴方向重叠且Y轴方向也重叠才算碰撞。每帧对所有子弹和所有敌机做一次这样的两两检测。bool CheckAABB(const SDL_Rect a, const SDL_Rect b) { return a.x b.x b.w a.x a.w b.x a.y b.y b.h a.y a.h b.y; }这个函数面对的是SDL_Rect这种整数坐标结构。注意三个坑第一a.x a.w可能溢出int像素坐标在1920x1080下不太可能但如果你做横版大地图游戏就一定要小心建议改用long long或把比较换算成中心坐标。第二矩形包含的是半开区间还是闭区间SDL的绘制习惯是左上角闭合、右下角开放碰撞边界差一个像素会变成“明明碰到了一起却没触发爆炸”。第三用SDL_Rect做碰撞检测意味着逻辑坐标、渲染坐标必须一致如果你像某些源码那样把逻辑坐标设为1000x700、渲染窗口是800x600碰撞矩形和显示矩形之间就必须做缩放转换忘了转就会看到子弹穿过敌机。4.2 子弹穿透问题为什么高速子弹会“穿模”玩过飞机大战的人一定遇到过这个现象子弹画面上明明穿过了敌机却没有爆炸特效。这个问题的根源叫隧穿效应——子弹每帧移动20像素而敌机只有30像素宽如果子弹上一帧在敌机左边、这一帧已经在右边中间没有任何一帧检测到重叠碰撞判定就漏掉了。解决隧穿效应有三个层级的方法从简单到复杂第一把高速子弹的碰撞体拉长比如子弹高度12像素但碰撞检测用20像素的矩形缺点是视觉上子弹明明没贴到飞机却爆炸了第二检查本帧起点到终点的线段是否与目标矩形相交这叫Swept AABB数学上要解线段与矩形的联立方程第三把两帧之间的运动细分每帧内部做多次小步碰撞检测。对飞机大战这个量级我推荐第一种的变体——区分“视觉矩形”和“碰撞矩形”碰撞矩形在运动方向上多延伸出子弹本帧的位移量。bool CheckAABBSwept(const Bullet bullet, const Enemy enemy, float dt) { // 把子弹视为从旧位置到新位置扫过的长条 SDL_Rect sweptRect bullet.GetCollider(); if (bullet.vy 0) { // 子弹向上飞碰撞矩形向上延伸本帧的位移量 sweptRect.h (int)(-bullet.vy * dt); sweptRect.y - (int)(-bullet.vy * dt); } return CheckAABB(sweptRect, enemy.GetCollider()); }这段代码只处理了vy小于0的情况因为飞机大战的子弹朝上飞而敌机在下如果源码里还有斜上方飞的强化弹这个逻辑要按速度方向做分支。正确性依赖速度换算一致如果游戏循环里传给Update的dt单位是秒而这里用毫秒拉长的距离会是预期值的1000倍结果就是整个屏幕边缘的子弹都在误报碰撞。4.3 碰撞的粗筛别把所有对象两两比较当你把子弹池开到512、敌机同屏30个的时候最直接的碰撞方案是每帧做15,360次AABB检测这对现代CPU不是问题。但别忘了还有玩家子弹打敌机、敌机子弹打玩家、敌机撞玩家、道具与玩家这四类碰撞加起来每帧接近六万次加上渲染和Update本身的开销低端机器上就会掉帧。常用的优化是空间网格法把屏幕切成固定大小的格子例如64x64像素每帧先按位置把每个对象登记到它所在的格子碰撞检测只检查同一格子和相邻格子里的对象对。这个方案比四叉树好写得多也比全体遍历快一个数量级网格大小是唯一的调参关键点——太小导致对象频繁跨格、登记开销变大太大会退化回全部检测。另一个被忽视的优化是先用中心点距离做粗判。计算两个对象中心点距离如果大于两个对象对角线长度之和直接跳过AABB一次乘法加比较就能拦截大多数不相干对象。飞机大战的敌机和子弹在数百量级加了这个粗筛后碰撞检测耗时能压到一帧总耗时的5%以内完全不会成为性能瓶颈。5. 飞机大战源码编译与运行的五个避坑记录5.1 LNK2019链接错误比语法错误更打击新手现象编译通过链接阶段报错“无法解析的外部符号 _SDL_main”或一串“LNK2019无法解析的外部符号”。原因SDL2在Windows下要求入口函数是SDL_main它会接管你的main函数。常见坑位是代码没有包含SDL.h就写了mainSDL2main.lib没有排在SDL2.lib前面使用了x64库却把工程平台编译成x86或者用了静态库SDL2-static.lib但忘了加winmm.lib、imm32.lib这些依赖。解决确认链接器输入顺序是SDL2main.lib在前、SDL2.lib在后把工程平台从x86切到x64或反过来匹配你下载的库不想折腾静态库就直接用SDL2.dll动态库放到exe同目录。这个错误占了我带学员时三分之一的上手时间所以排查它要同时检查库路径、库名称、平台位数三件事缺一不可。5.2 中文字符乱码源码里的字全变成问号现象窗口标题或界面文字显示成“???”或甲骨文一样的乱码控制台输出的中文也全部错乱。原因源码文件保存成了带签名的UTF-8而编译器默认按GBK解析反过来的情况同样存在。这不是代码问题是编码表不匹配。VS2019以上通常能自动识别UTF-8带BOM但Dev-C老版本会把它当GBK读。解决统一把源码文件保存为UTF-8 with BOM或者在主函数开头调用SetConsoleOutputCP(CP_UTF8)把控制台输出代码页改过来。Windows的C游戏普遍还涉及宽字符和窄字符转换最省事的做法是别把中文字符串写在代码里放到外部配置文件中用UTF-8读进来再转成宽字符渲染。这个习惯在跨平台项目里也是必修课。5.3 窗口关闭了但进程还挂在后台现象点了窗口右上角X窗口消失了但任务管理器里进程依然占用CPU风扇狂转。原因事件循环里只处理了SDL_QUIT就退出但如果你在游戏循环的某处用了while(running)而running没有在所有退出路径上被置为false比如玩家死亡弹窗后直接return或者你在SDL_Quit之前有非NULL的renderer和window指针没有释放进程就不会干净退出。解决在退出循环后按固定顺序调用SDL_DestroyRenderer、SDL_DestroyWindow、SDL_Quit。同时检查Update逻辑里有没有提前return的分支漏掉running标志。排查手法是每帧打印SDL_GetTicks()如果退出后还有输出说明循环没跳出来如果没输出但进程还在问题出在资源释放和SDL_Quit的调用顺序。5.4 敌机的玄学加速帧率不锁导致难度漂移现象跑在不同显示器上游戏难度明显不同刷新率高的屏幕上敌机移动更快、子弹更密。原因帧间隔不同。如果移动和生成逻辑写的是“每帧移动5像素”90Hz下每秒就是450像素60Hz下只有300像素游戏物理全乱。更隐蔽的是生成间隔按“每隔N帧生成一个”来控制帧率一变生成密度就变。解决所有速度、间隔、冷却时间统一用秒为单位在Update(dt)里乘以dt。帧率控制用第二章的帧延迟方案再配合SDL_RENDERER_PRESENTVSYNC让帧率上限和显示刷新率一致。判断源码写得好不好的硬指标就是同一套逻辑在上百FPS和60FPS下手感应当完全一致差别只在于渲染开销。5.5 子弹消失不是bug对象池与数组越界的边界问题现象连续高速射击时偶尔有一发子弹开火后凭空消失敌机也没被击中。原因子弹池满了Spawn返回nullptr射击方没检查空指针就继续调用Bullet的方法。或者用的是std::vector射击时push_back触发扩容之前持有的Bullet引用、指针全部失效。解决池方案的Spawn返回nullptr时代表本帧弹药耗尽合理表现是静默丢弃或播放冷却音效绝不能让飞机卡死vector方案不要在持有Bullet引用时push_back先重新取下标志再操作。排查手法是给每颗子弹编一个自增id打印生成和销毁日志看消失的那颗是没触发碰撞还是根本没创建。6. 给源码加评分系统与双人模式验证你读懂了这套代码6.1 用状态机把主循环改成“菜单-战斗-结算”三段式很多飞机大战源码只有一个战斗循环。加评分系统不能硬塞在战斗逻辑里先抽出状态机。用一个枚举存当前游戏状态主循环每帧只处理当前状态对应的Update和Render状态切换用函数显式完成。这个改造的价值是后续加暂停、加结束页面都不需要动主循环代码。enum class GameState { MENU, PLAYING, PAUSED, GAME_OVER }; GameState state GameState::MENU; // 在事件循环里处理键盘切换状态 if (event.type SDL_KEYDOWN) { if (event.key.keysym.sym SDLK_SPACE state GameState::GAME_OVER) state GameState::PLAYING; // 重开 }敌机被击毁时在碰撞回调里把击杀信息写入总分变量显示分数时用SDL_QueryTexture拿到渲染纹理的尺寸再居中绘制。关键是把UI渲染和游戏逻辑分离否则会看到分数字体在爆炸特效里闪烁这类难排查的视觉bug。验证方式很简单打死一架敌机分数字面要立即变化重开后分数归零暂停时分数不能动。这三条过了状态机的状态切换就基本可靠。6.2 验证代码的健壮性内存与帧率两个硬指标最后说一个我自己的习惯。拿到任何一份游戏源码我不会跑通就算完必定做两件事再下结论。第一用Visual Studio的诊断工具或Windows任务管理器跑五分钟看内存在游戏过程中是否单调上升——如果上升对准对象池和new/delete的位置这是内存泄漏的信号也是新手最容易翻车的地方。第二在窗口标题栏实时显示SDL_GetTicks()算出的当前帧率把子弹数量翻三倍再观察帧率变化这一步能暴露出碰撞检测里的O(n²)增长点也能判断这份源码值不值得在你自己的项目里复用。飞机大战这个项目适合绝大多数C入门者但多数网盘源码止步于“能编译能玩”。如果你照这篇笔记把图形库选型确认了、对象生命周期理顺了、帧间隔统一成秒、再给碰撞检测加一层空间粗筛这份源码的价值就从“跑通一个demo”变成了“一套能继续长成的游戏骨架”。我在检查别人项目时吃的亏几乎都集中在上述五个坑里尤其是帧率不锁和对象池空指针这两个问题希望这些经验能帮到你。本文还有配套的精品资源点击获取