简介：这份资源是一款基于 raylib 定制引擎开发的复古生存恐怖游戏源码，面向具备 C++ 基础、希望入门游戏引擎与图形编程的开发者。项目以 C++ 为主要语言，完整呈现了从依赖安装、项目构建到编辑器模式运行的全流程，适合作为学习 raylib 渲染、场景管理与实体系统设计的实战案例。压缩包共 60 个文件，约 170KB，其中 22 个 .h 头文件与 20 个 .cpp 源文件构成核心逻辑，另有 4 个 png 贴图、4 个 scene 场景文件、3 个 yml 配置、1 个 blend 模型源文件及 1 个 obj 模型，配合 Makefile 与 README 说明，目录结构清晰，涵盖 assets、src、systems、entities 等模块。目前已有 629 人学习下载。读者可借此理解 raylib-cpp 的封装方式、游戏主循环与系统分层思路，并直接运行编辑器模式调试场景，是研究复古恐怖游戏实现与 C++ 引擎架构的实用参考。
1. 黑暗不适：用 raylib 手搓复古生存恐怖引擎，到底在解决什么问题
很多人第一次听到“基于 raylib 的定制引擎做复古生存恐怖游戏”，脑子里冒出来的画面是：拿个现成引擎拖拖拽拽，套一层像素滤镜，把亮度调低，完事。真动手做过的人会告诉你，这条路走不通。复古生存恐怖的核心不是“画面糊”，而是资源极度稀缺下的决策压力——弹药有限、视野受限、存档点稀少、敌人不可预测。这些东西如果交给通用引擎的默认组件去拼，你会被它的抽象层反复绊倒：碰撞回调时机不对、渲染顺序不可控、固定时间步和物理插值打架，最后做出来的东西手感像在冰面上开卡车。
raylib 在这里的价值，是它足够薄。它不替你决定游戏循环长什么样，不强制你用实体组件系统，不隐藏帧缓冲和着色器。你要自己写状态机、自己管内存、自己控制每一帧的绘制顺序。这恰好是定制引擎该干的事：把“生存恐怖”的规则直接刻进代码结构里，而不是靠配置去凑。适合读这篇的人有三类：想从零理解游戏引擎最小闭环的开发者、做过 Unity/Godot 但觉得手感调不透的独立作者、以及想用 C 系语言写一个能跑在低配机器上的完整小项目的人。下面按“先立住结构，再动手复现，最后避坑”的顺序推。
2. 定制引擎的最小闭环：从窗口到固定时间步
2.1 为什么不用现成引擎的默认循环
通用引擎通常给你一个Update()和一个Draw()，中间夹着物理、动画、音频的自动更新。问题在于，生存恐怖游戏对“时间”极其敏感。举一个具体场景：玩家在黑暗中听到脚步声，决定是否开枪。这个决策窗口可能只有 0.3 秒。如果引擎的更新频率随帧率浮动，那么在高刷屏上敌人移动更快，在低配机上敌人像慢动作，整个紧张感就崩了。定制引擎的第一件事，就是把逻辑更新和渲染更新彻底分开，逻辑跑固定步长，渲染跑可变步长并做插值。
raylib 本身不提供固定时间步，它只给你WindowShouldClose()和BeginDrawing()。这反而是好事，因为你可以完全控制累加器逻辑。常见做法是：逻辑固定 60Hz，渲染不限帧，用累加器把剩余时间传给插值函数。这样无论显示器是 60Hz 还是 144Hz，游戏世界里的“一秒”都是同一秒。
2.2 用 raylib 搭出固定步长骨架
下面这段代码是一个可复现的最小骨架，包含窗口初始化、固定步长累加器、以及逻辑与渲染的分离。直接编译就能跑，你会看到一个方块以恒定速度移动，不受帧率影响。
#include "raylib.h" #define LOGIC_HZ 60 #define LOGIC_DT (1.0f / LOGIC_HZ) #define MAX_FRAME_TIME 0.25f typedef struct { Vector2 pos; Vector2 prevPos; Vector2 vel; } Entity; static void UpdateLogic(Entity *e, float dt) { e->prevPos = e->pos; e->pos.x += e->vel.x * dt; e->pos.y += e->vel.y * dt; // 边界反弹，模拟生存恐怖里狭窄走廊的碰撞 if (e->pos.x < 0 || e->pos.x > 800) e->vel.x *= -1; if (e->pos.y < 0 || e->pos.y > 450) e->vel.y *= -1; } static Vector2 LerpVec(Vector2 a, Vector2 b, float t) { return (Vector2){ a.x + (b.x - a.x) * t, a.y + (b.y - a.y) * t }; } int main(void) { InitWindow(800, 450, "retro survival engine skeleton"); SetTargetFPS(0); // 不限帧，由累加器控制逻辑 Entity e = { .pos = {400, 225}, .prevPos = {400, 225}, .vel = {120, 80} }; float accumulator = 0.0f; while (!WindowShouldClose()) { float frameTime = GetFrameTime(); if (frameTime > MAX_FRAME_TIME) frameTime = MAX_FRAME_TIME; // 防止卡顿后逻辑爆炸 accumulator += frameTime; while (accumulator >= LOGIC_DT) { UpdateLogic(&e, LOGIC_DT); accumulator -= LOGIC_DT; } float alpha = accumulator / LOGIC_DT; Vector2 renderPos = LerpVec(e.prevPos, e.pos, alpha); BeginDrawing(); ClearBackground(BLACK); DrawRectangleV(renderPos, (Vector2){32, 32}, RAYWHITE); DrawFPS(10, 10); EndDrawing(); } CloseWindow(); return 0; }逻辑说明：accumulator累积真实帧时间，每满一个LOGIC_DT就执行一次逻辑更新，剩余部分作为插值系数alpha。prevPos保存上一逻辑帧的位置，渲染时在prevPos和pos之间插值，这样即使渲染帧率远高于逻辑帧率，画面也是平滑的。参数说明：LOGIC_HZ设为 60 是复古手感的常见选择，调高会让输入响应更灵敏但增加 CPU 占用；MAX_FRAME_TIME是“后悔药”，防止玩家切出窗口再切回来时累加器暴涨导致敌人瞬移。这个骨架跑通之后，所有后续系统——碰撞、AI、存档——都挂到UpdateLogic里，渲染只读状态，不写状态。
2.3 状态机与场景切换的落地方式
生存恐怖游戏离不开场景切换：探索、战斗、道具栏、存档界面。如果每个场景都写一个if-else分支，代码会迅速腐烂。定制引擎里我一般用一个极简的函数指针状态机，每个状态有Enter、Update、Draw、Exit四个钩子。切换时先调旧状态的Exit，再调新状态的Enter，中间不保留任何全局临时变量。这样做的好处是，存档系统只需要序列化当前状态 ID 和实体数据，不需要遍历整个场景树。
具体实现上，用一个枚举表示状态 ID，一个结构体数组存放四个函数指针，索引就是状态 ID。切换函数只做两件事：调用Exit，设置currentState，调用Enter。注意不要在Update里直接改currentState，而是设置一个nextState标志，等当前帧逻辑跑完再切换，否则会出现“半帧”状态，导致渲染读到不一致的数据。这个坑我在早期版本里踩过，表现为切换场景时偶尔闪一帧黑屏，排查了很久才发现是状态切换时机不对。
3. 复古生存恐怖的核心系统：视野、资源与存档
3.1 黑暗视野的渲染实现与性能取舍
“黑暗”不是把屏幕调暗，而是让玩家只能看到有限范围，其余部分不可见。常见做法有两种：一种是基于射线投射的可见性多边形，计算量大但精确；另一种是基于距离衰减的遮罩，用着色器或渲染纹理实现，性能好但边缘柔和。复古生存恐怖通常选后者，因为老式硬件本来就算不动精确可见性，那种“模糊的恐惧”反而更对味。
在 raylib 里，我一般用RenderTexture2D做离屏渲染：先把场景画到纹理上，再用一个全屏着色器根据玩家位置和半径计算亮度衰减。着色器里传入玩家屏幕坐标和视野半径，片元到玩家的距离超过半径就输出黑色，半径内按平滑曲线衰减。这样做的性能开销主要在离屏纹理的切换和着色器采样上，低配机器也能跑满 60Hz。参数上，视野半径建议设为屏幕高度的 0.35 到 0.45 倍，太小会让玩家频繁撞墙，太大则失去压迫感。衰减曲线用smoothstep而不是线性，边缘更自然。
3.2 弹药与道具的稀缺性参数设计
资源稀缺是生存恐怖的核心。但“稀缺”不能靠拍脑袋，要有可调参数。我通常把资源系统拆成三个维度：初始携带量、掉落概率、消耗速率。初始携带量决定开局压力，掉落概率决定中期节奏，消耗速率决定战斗时长。以手枪弹药为例，初始 12 发，普通敌人掉落概率 0.15，Boss 战消耗约 8 到 10 发。这三个数要一起调，单独改一个很容易让游戏要么太简单要么不可通关。
落地时，用一个资源管理器结构体保存每种资源的当前量和上限，掉落逻辑放在敌人死亡回调里，用GetRandomValue(0, 99) < dropRate * 100判断。注意随机数种子要在存档时保存，否则读档后掉落序列会变，玩家可以利用这一点刷资源。这个细节在测试阶段被一个玩家发现过，他反复读档刷弹药，后来我把种子写进存档才堵住。
3.3 存档点与状态序列化的最小实现
复古生存恐怖的存档点通常很少，而且存档时游戏不暂停（或者假装不暂停）。这意味着序列化必须快，不能遍历整个堆。我的做法是：只序列化玩家位置、朝向、资源量、已拾取道具的位掩码、以及当前场景 ID。敌人状态不保存，读档后敌人重置到初始位置。这既符合老游戏的“不完美存档”手感，也避免了序列化复杂 AI 状态的麻烦。
具体代码上，定义一个SaveData结构体，用fwrite直接写二进制。注意结构体要#pragma pack或者手动保证没有填充字节，否则不同编译器读出来的布局可能不一样。读档时先校验一个魔数，再校验版本号，版本不匹配就拒绝加载并提示“存档不兼容”。这个校验在迭代期救过我很多次，因为改结构体是常事，没有版本号的话读旧档会直接崩溃。
4. 避坑与排查：定制引擎里最容易翻车的五件事
4.1 现象：画面撕裂且输入延迟明显
原因：渲染和逻辑在同一个循环里且没有垂直同步，或者SetTargetFPS设得过高导致 CPU 空转。解决：把SetTargetFPS设为 0，用累加器控制逻辑，渲染交给显卡垂直同步。如果还有撕裂，检查是否在BeginDrawing之前做了耗时操作，比如文件读取。把 IO 放到单独线程或预加载。
4.2 现象：敌人偶尔穿墙
原因：固定步长下，如果单帧位移大于墙的厚度，碰撞检测会漏掉。解决：在UpdateLogic里对位移做分段检测，每段不超过墙厚的一半。或者把墙做厚一点，但这不是根治。更稳的做法是记录上一帧位置，用线段与墙的 AABB 做相交测试，而不是只测当前点。
4.3 现象：着色器编译失败但没报错
原因：raylib 的着色器加载默认不输出详细日志，路径错误或 GLSL 版本不匹配时静默失败。解决：加载后检查shader.id是否为 0，是 0 就打印GetShaderLocation的返回值并检查文件路径。GLSL 版本要跟 raylib 的 OpenGL 后端匹配，桌面端通常用 330 core，Web 端用 100。
4.4 现象：存档读档后资源数量翻倍
原因：读档时没有先清空当前资源，而是直接累加。解决：读档函数第一步就是把所有运行时状态重置为默认值，再覆盖存档数据。这个坑很隐蔽，因为单次读档看起来正常，只有反复读档才会暴露。
4.5 现象：低配机器上音频卡顿导致逻辑卡顿
原因：音频回调在主线程里执行，如果音频缓冲区设得太小，回调频率过高会挤占逻辑时间。解决：把音频缓冲区调大（比如 1024 采样），或者把音频更新放到独立线程。raylib 的SetAudioStreamBufferSizeDefault可以在初始化前调整。
5. 进阶技巧：用调试覆盖层验证手感与性能
最后一章不讲大道理，讲一个我每次做定制引擎都会先搭的东西：调试覆盖层。它不是一个正式功能，但能让你在十分钟内判断当前参数是否合理。具体做法是，在渲染循环最后，用DrawText在屏幕上打印几个关键指标：逻辑帧率、渲染帧率、累加器余量、玩家坐标、当前状态 ID、资源量。这些数字实时变化，你调参数的时候盯着看，比凭感觉靠谱得多。
更进一步，加一个按键切换的“碰撞盒显示”和“视野半径显示”。碰撞盒用DrawRectangleLines画出来，视野半径用DrawCircleLines画。这样敌人穿墙、视野过大过小，一眼就能看出来。我通常把这两个开关绑在 F1 和 F2 上，测试时随手按。下面是一个可直接嵌入的调试绘制函数：
static bool showColliders = false; static bool showVision = false; static void DrawDebugOverlay(Entity *entities, int count, Vector2 playerPos, float visionRadius) { if (IsKeyPressed(KEY_F1)) showColliders = !showColliders; if (IsKeyPressed(KEY_F2)) showVision = !showVision; if (showColliders) { for (int i = 0; i < count; i++) { DrawRectangleLines( (int)entities[i].pos.x, (int)entities[i].pos.y, 32, 32, GREEN ); } } if (showVision) { DrawCircleLines((int)playerPos.x, (int)playerPos.y, visionRadius, YELLOW); } DrawText(TextFormat("logic: %d Hz", LOGIC_HZ), 10, 30, 16, LIME); DrawText(TextFormat("fps: %d", GetFPS()), 10, 50, 16, LIME); DrawText(TextFormat("player: %.1f, %.1f", playerPos.x, playerPos.y), 10, 70, 16, LIME); }逻辑说明：IsKeyPressed只在按键按下的那一帧返回 true，所以切换开关不会连续触发。DrawRectangleLines和DrawCircleLines是 raylib 自带的描边绘制，开销很低，测试时开着不影响帧率。参数说明：visionRadius要和着色器里用的半径保持一致，否则调试看到的圈和实际视野对不上。这个覆盖层我一般保留到项目结束，发布版用宏包起来，编译时去掉。
还有一个验证手感的小技巧：录一段自己玩自己游戏的视频，然后逐帧看。人在实时玩的时候对输入延迟的感知很模糊，但逐帧回放时，从按键到角色开始移动之间隔了几帧，一目了然。我一般要求这个间隔不超过 2 帧（60Hz 下约 33ms），超过就说明逻辑更新或输入采样有问题。这个习惯帮我省掉了无数次“玩家说手感怪”的返工。希望帮到你。
本文还有配套的精品资源，点击获取
