用raylib自研引擎，打造复古生存恐怖游戏《黑暗不适》

简介：这是一份基于raylib定制引擎开发的复古生存恐怖游戏《黑暗不适》的完整工程源码，使用C++编写，面向对复古游戏开发、raylib引擎及C++项目架构感兴趣的初学者与进阶开发者。压缩包内共60个文件，包含22个头文件、20个C++源文件，以及图片素材、场景文件、配置与模型文件、构建脚本和说明文档等，整体约170KB，目录划分清晰，便于按模块阅读。目前已有628人学习下载。代码模块划分明确，src与systems子目录承载核心游戏逻辑，assets与scenes保存美术场景资源，配合README可快速掌握跨平台构建与编辑器模式启动流程。通过该资源，读者可以系统研究raylib定制引擎的封装方式、游戏场景与实体系统的组织逻辑、资源加载与渲染流程，还能参考编辑器模式参数实现可视化编辑，适合作为小型游戏引擎与生存恐怖玩法的入门实践样例。

黑暗不适：我用raylib写了一套定制引擎，做了一款复古生存恐怖游戏

做这个项目的起因其实有点偏执：市面上现成引擎什么都帮我做好了，但恰恰是那种“什么都有”的自动化，让我在做复古生存恐怖时感到束手束脚。我想要的是可控的颗粒感、奶油一样厚重的黑色、刻意不干净的画面，而不是开了Physical Based Rendering之后每个材质都油光发亮的“真实”。所以我把目光放回到raylib，在这套极简的C语言图形库上，自己从头搭了一款定制引擎，最终做成了《黑暗不适》——一个以压抑黑暗、资源稀缺、缓慢节奏为核心玩法的第一人称复古生存恐怖游戏。

如果你也喜欢老派恐怖游戏，或者你想知道“用raylib到底能不能撑起一个完整3D游戏”，这篇文章值得你花十分钟看完。我会把从引擎架构到恐怖氛围设计的技术路线，连同踩过的坑一起拆开讲。

1. 为什么要为一个复古恐怖游戏专门造一个引擎

1.1 我对“复古恐怖”画面的理解

先说结论：复古恐怖不是低模加噪点滤镜这么简单。老一代恐怖游戏之所以吓人，很大一部分来自技术限制造成的视觉盲区——看不清、猜不透、突然出现的东西没有充足光照，这套逻辑在4K高帧率下其实很难实现。因此我需要的渲染环境必须允许我做“不够完美”的东西：手动控制纹理采样方式、关闭平滑光照、故意低频的阴影、屏幕空间上的颗粒抖动。这些细节在Unity里也不是做不到，但为了关闭一堆默认特性、绕过PBR管线，我要写的代码可能比直接用raylib造一个渲染层还多。

1.2 raylib给的不多，但每一样都是我要的

raylib更像一套“零主见的工具箱”：它给你窗口、OpenGL上下文、3D模型加载、基础Shader、音频播放，但不会替你想好场景结构、摄像机管理、资源生命周期、UI系统。这恰恰是好事。我可以在它上面按自己的方式搭引擎，而不是去逆着一个庞大引擎的设计哲学做修改。

做选型的时候我也简单对比过几个方案，结论放在这里：

对单人开发来说，时间是最稀缺的资源。raylib帮我省略掉了窗口创建、OpenGL初始化、模型OBJ/GLTF解析、音频解码这些没有乐趣的部分，又把最需要创造力的画面控制和游戏逻辑完全留给我，这是它最大的价值。

1.3 “库”到“引擎”之间到底差了什么

很多人会问，用raylib直接写和用“定制引擎”写，区别在哪？我的理解是：当你的代码开始有独立的场景系统、实体生命周期、可扩展的渲染管线、资源管理器、固定频率的游戏逻辑更新，而不是在main函数里堆一堆DrawModel，那它就已经是个引擎了，尽管很小。

《黑暗不适》的引擎层我命名为DrkEngine，整体就一条极简路径：主循环 → 逻辑更新 → 渲染场景 → 后处理叠加 → UI绘制。所有玩法系统都挂在引擎之上，不直接碰raylib API。这样做的收益在项目后期非常明显——我可以在不动玩法代码的前提下，把后期特效从“叠一层噪点”改成“动态噪点加CRT扫描线”，完全不用重写其他地方。

2. 引擎核心骨架：第一刀就切在raylib的主循环上

2.1 目录结构与模块划分

这个引擎只有五个核心模块，我尽量控制不要过度设计：

• core：窗口创建、时间管理、浮点精度控制；
• scene：场景图、实体保存、摄像机管理；
• render：网格提交、纹理绑定、后处理帧缓冲；
• res：模型/纹理/音频的加载缓存；
• game：具体交互逻辑，独立于引擎。

// main.c 核心入口 #include "raylib.h" #include "drk.h" int main(void) { DrkInit("Dark Discomfort", 320 * 4, 200 * 4); DrkLoadAssets("assets/"); while (!DrkShouldClose()) { DrkUpdate(); // 内部使用固定时间步长 DrkRender(); // 先渲染到低分辨率纹理，再放大 } DrkShutdown(); return 0; }

字面上看和普通raylib程序差不多，但DrkUpdate和DrkRender内部已经是一个完整分层。大部分玩法代码，比如开门、拾取、敌人AI，都运行在DrkUpdate提供的固定步长上下文里。

2.2 固定时间步长：恐怖游戏不能有的帧率抖动

帧率波动对其他品类也许可以忍，但在生存恐怖里完全不行。镜头微小的停顿或者移动速度忽快忽慢，会直接破坏紧张感的连续性。因此我采用固定时间步长的逻辑更新，渲染则独立插值或直接接受略有偏差。

这里我踩过一个具体教训：最初为了省事直接拿GetFrameTime()做物理和玩家位移，结果在低配置机器上画面会间歇性“顿挫”。后来改成固定步长：

static double accumulator = 0.0; static const double step = 1.0 / 60.0; void DrkUpdate(void) { accumulator += GetFrameTime(); while (accumulator >= step) { DrkStep((float)step); // 游戏逻辑只认这个时间 accumulator -= step; } }

这个思路很老派，但对恐怖游戏尤其重要，因为玩家的手感和读图记忆建立在一套稳定的时间感之上。

2.3 场景管理不需要二叉空间分割

很多人一听场景管就会想到四叉树、八叉树、大世界分块。但对一个迷宫式恐怖游戏，地图规模其实很小，走廊窄、房间少，我直接用一个线性场景列表就够了。每个实体有一个Transform和一组组件，更新时按类型分组处理。这样的设计让调试很舒服——出问题我只要看内存里的实体列表，不需要翻空间索引。

3. 让“黑暗”成立：渲染与后处理的复古化方案

3.1 低分辨率不是偷懒，是创造颗粒感

《黑暗不适》的画面逻辑是先渲染到一个很低分辨率的渲染纹理，再用点采样放大到窗口。我选的基准分辨率是320×200，放大4倍到1280×800。320×200不是随手拍的，这个分辨率下每颗像素都够大，模型表面会产生天然的锯齿感，再加上点采样放大，远处物体都带着一种模糊猜测感。

这也是众多老派游戏让人“看不清楚”的本质原因。玩家看到远处走廊尽头似乎有个轮廓，但像素太少，无法确认是不是人形。恐惧的种子就是在这里埋下的。

核心代码其实很短：

RenderTexture target = LoadRenderTexture(320, 200); BeginTextureMode(target); DrkDrawScene(camera); EndTextureMode(); BeginDrawing(); DrawTexturePro(target.texture, (Rectangle){ 0, 0, 320, -200 }, (Rectangle){ 0, 0, 1280, 800 }, (Vector2){ 0, 0 }, 0.0f, WHITE); EndDrawing();

注意那个-200，因为RenderTexture默认的原点方向不同，我初始化时花了不少时间才意识到不是纹理问题，而是UV翻转。

3.2 后处理堆叠：暗角、噪点和扫描线

要让玩家“不舒服”，画面不能只是暗，要暗得有纹理、有压力。我的后期管线堆了四层屏幕空间效果，全部用raylib的Shader实现：

• 暗角：以屏幕中心为圆心的径向渐变，越靠边缘越黑，模拟手持手电筒的视觉收窄；
• 动态噪点：每帧生成随机值采样的Value Noise，再做低透明度叠加；
• 扫描线：模拟CRT的水平暗线，让大面积的纯黑区域不至于死板；
• 色差：画面边缘RGB通道轻微偏移，制造一种镜头玻璃扭曲的微不适感。

其中噪点是最容易做过头的一项。我测试时遇到过噪点太强导致玩家头晕的情况，后来把噪点透明度压到8%左右，反而刚刚好。

3.3 光照即恐惧：手电筒、雾和“看不见”

整个游戏只有两个动态光源：玩家手电筒和远处的应急灯。为了配合复古感，我禁用了光滑表面反射，所有材质统一用简单的Blinn-Phong模型。手电筒是一个SpotLight，角度很窄，亮度故意调低，照射距离大概只有六个身位。

再配合一层浅灰色指数雾，所有超出光照范围的地方都会被雾吞没。这种雾不是为了让画面好看，而是为了隐藏我根本没建模的“远距离物体”。玩家不知道前方是墙还是一张脸，这是生存恐怖比较核心的心理玩法。

之后我还在某些转角反复放置了视觉相似但略有不同的物件，让玩家产生“我是不是来过这”的记忆错觉，这种氛围设计必须建立在“看不清”的渲染基础上，否则一眼就看穿了。

4. 让“不适”升级：生存循环、追踪AI与声音反馈

4.1 资源稀缺：从“吓你”到“逼你”

恐怖光靠吓人是廉价的，真正让人坐立难安的是“逼迫感”。我给《黑暗不适》设计了一套极简但不留余地的资源循环：地图上只会出现六发左轮弹药、两个急救包和一个能短时间驱散敌人的荧光棒。初始生命值只有两格，被敌人摸到一次掉一格，这意味着整局游戏你可能只有两三次犯错机会。

存档点则固定在有限的几个老旧电话亭里，而且存档道具本身非常稀缺。每次走回存档点的过程都承担着巨大心理压力。这种缺少资源导致的风险厌恶感，自然会放大玩家对黑暗角落的警惕。

4.2 简而不糙的敌人AI

敌人AI我故意做得“不聪明”：它平时在几个出生点之间巡逻，只有当玩家跑步或开枪时，声音事件才会把敌人吸引过来。这意味着玩家必须控制自己的行动节奏——跑动最快但最危险，慢走安全但耗时更长。

实现上就是一个有限状态机：巡逻→警觉→追踪→攻击。追踪状态下敌人不会穿墙，也不会抄近路，只沿着当前房间到玩家位置的简单寻路移动。相比复杂导航网格，这种设计有个隐藏优点：敌人可以被玩家“卡”在走廊转角，但代价是转角时必须压着脚步走，这种压迫感比全知AI强得多。

声音反馈在这里是大头。敌人靠近时，听觉信号比视觉信号更早到达：低频脚步声持续逼近、紧跟其后的呼吸音、突然响起的金属碰撞声都是警告。我甚至给追踪状态的敌人叠加了一个往上飘的渐变音量，玩家能通过声音音量的持续增加判断它是否在走近，而看不到任何画面。这个过程让“背对恐惧”成为常态，紧张感自然拉满。

4.3 从audible设计里捡来的经验

还需说一句：raylib自带的音频播放对音效够用，但对动态混合并不友好。我的做法是把所有环境音预先压成单声道小文件，用音量衰减模拟空间感。具体来说，敌对声源离玩家越远，低通滤波效果越强，听起来像隔了层墙。尽管没有真HRTF，实测感受已经很接近“隔着房间听到动静”。

如果要做更精细的多普勒效果，要么自己写采样率转换，要么铺一条AudioStream做实时处理。我的精力有限，选择了预先烘焙“靠近”和“远离”两套音效素材，按距离交叉淡入淡出，效果比实时演算还稳。

5. 开发中踩过的坑：模型翻转、绘制批次与内存管理

5.1 模型翻转问题：OpenGL和D3D约定不同

这个坑很基础但非常磨人。第一次加载GLTF模型时，整个场景像是照了镜子。原因是模型Assimp到了raylib内部OpenGL坐标轴约定从右手变成了左手，z轴方向反了。我最初决定所有模型在建模软件里统一采用Blender的-Y前向反而更麻烦，后来干脆在引擎层把所有模型的一阶变换矩阵里z乘上-1。这种问题看起来是小事，但如果不做统一封装，每个模型都要手动改，后期一定会出错。

5.2 Draw Call不是你想优化就能优化

早期版本的场景里每个墙板、每个油桶都单独提交DrawModel，结果是画面帧时间高得离谱，哪怕地图不大也卡。raylib的DrawModel不支持自动批处理，简单模型动辄上千个Draw Call实在扛不住。后来我做了三层优化：

• 把静态家具合并成一个大Mesh，贴图用一张图集；
• 动态物品单独提交，但数量控制在30个以内；
• 手电筒光照只对邻近物体计算，其他默认不受光。

优化之后Draw Call从两千多降到两百多，在老核显上都能稳定60帧。在这个阶段我才理解到一件事：raylib不会替你优化，但它给了你足够低的层来自己优化。

5.3 内存释放和崩溃排查：纯C项目的必修课

射线库很人性化，但底层仍然是C语言。游戏里我加载了大量模型、音频、纹理资源，如果没有统一资源管理，很容易出现找不到指针、重复释放、加载后没进缓存导致卡顿等问题。

我给自己定了几条规矩：

• 所有资产先过资源管理器，同名文件不会加载第二遍；
• 每次Shutdown统一释放所有缓存，不分别释放；
• 所有文件读取失败都直接抛到日志，而不是静默继续。

这样在Debug阶段发现很多加载错误，例如纹理文件路径大小写不同导致某些机器上加载失败，替换成加载器统一小写化后彻底解决。

开发到这里，《黑暗不适》已经形成一套完整可玩的复古生存恐怖体验。对我来说，用raylib做定制引擎的最大感受不是“我又造了个轮子”，而是亲手控制了每一个黑暗、每一次恐慌。如果你想尝试复刻一套类似的玩法，我建议从最丑陋的画面开始，先架好固定步长逻辑，再一点点把黑暗和资源压力加进去，你会发现恐怖游戏的本质从来不依赖昂贵的素材，而是在于精确控制玩家每一次看不见、等不及和得不到的瞬间。

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