在64KB空间内开发第一人称射击游戏：纹理生成、地图优化与虚拟机技术解析

daivuk

引言 [00:00]

• 游戏简介 [00:48]
  • “QUOD”是一款第一人称射击游戏，特点是体积极小，仅64KB。
  • 游戏内容包括3个关卡、一个Boss关卡、4种可用武器、4种敌人、门、平台、开关、粒子、贴花、秘密、水体、音乐和音效。
• 64KB的含义 [01:02]
  • 灵感来源于2000年代早期的Demoscene，其中64KB作品展现的创造力令人着迷。
  • 1KB在计算机领域等于1024字节，因此64KB实际上是65536字节。
  • 作为对比，游戏的PNG格式Logo图片大小约为30KB，是游戏总大小的一半，凸显了64KB的极限。
  • 视频将解释如何通过自定义工具、压缩技巧等实现这一目标。

纹理 [02:19]

• 纹理生成而非存储 [02:27]
  • 直接存储PNG图像会超出64KB的预算。
  • 核心思路是存储生成纹理的“编辑操作”，而非图像本身，类似于存储Photoshop的动作指令。
• 自定义纹理工具详解 [02:38]
  • 工具通过图层（Layers）构建纹理。
  • 每个图层可定义以下属性：
    • 覆盖范围 (Coverage)：包括完整填充(Full)、矩形(Rect)、圆角矩形(Rounded Rect)和位掩码(Bitmask)。
      • 位掩码：使用16字节数据，并可水平镜像，适用于绘制骷髅头等小型细节。
    • 混合模式 (Blending)：包括Alpha（半透明）、加法(Additive)（使物体更亮）和乘法(Multiply)（使物体更暗）。
    • 填充颜色 (Fill Color)：为覆盖区域指定颜色。
    • 噪声 (Noise)：增加纹理的随机缺陷，可调整密度和频率，通过分层噪声创建分形效果。
    • 斜角 (Bevel)：创建三维立体感，是作者最喜欢的功能。
      • 可生成柔和斜角(Soft Bevel)模拟圆润表面。
      • 自动生成阴影，深度可调。
      • 可创建内凹斜角(Inner Bevel)表现下陷区域。
    • 平铺 (Tiling)：在纹理上重复图层。
      • 来源于JavaScript 13KB游戏启发，实现螺丝、通风口等细节的对齐。
      • 可对角平铺，无需位掩码即可创建对角形状。
      • 可重复错位图案，如弹孔或血迹。
    • 发光 (Emissive)：使图层发光，用于灯光、电脑屏幕、怪物发光的眼睛等。
• 纹理数据压缩 [06:54]
  • 纹理总大小：2字节用于宽度和高度。
  • 图层数据：
    • 第一个字节：混合了2位的覆盖范围和6位的功能标志（Copy, Fill, Noise, Bevel, Tile, Emissive）。
    • 覆盖范围相关：矩形需要4字节（偏移量和尺寸），圆角矩形额外1字节（半径）。
    • 填充颜色：2字节（每通道4位，共4096种颜色）。
    • 混合和发光：共1字节（2位用于混合，1位用于发光标志）。
  • 字体也通过此工具创建，主要使用位掩码、斜角和噪声，并可移除未使用的字符以节省空间。
  • 一个64x64像素的猫咪图像（16色、4x4块压缩、每通道2位）需要1300字节，虽大但仍比PNG小，主要用于演示不同的压缩方法。

地图 [08:49]

• 地图设计理念 [08:51]
  • 作者希望手动设计关卡，而非通过程序生成或数学公式。
  • 使用TrenchBroom，一个用于Quake的地图编辑器。
  • 定制化TrenchBroom以支持游戏的实体定义、关卡大小限制和纹理库。
• 地图几何体压缩 [09:12]
  • 解析编辑器使用的.map文件，并对几何体的面进行压缩。
  • 不生成BSP（二叉空间分割），也不进行外部面剔除。
  • 外部面需要手动分配空纹理，让工具知道不包含这些面以节省空间。
  • TrenchBroom的优势：能够将多个画刷（brushes）组合成组，并以引用方式复制。
    • 对于重复部件（如柱子、拱门），只需存储一个原始画刷，其余为偏移量和角度的副本。
    • 优化时大量使用此功能来处理复杂形状或重复纹理。
• 面数据存储方式 [10:11]
  • 根据面类型（墙壁、地板、天花板）、是否倾斜或拥有复杂UV（如旋转），采用不同的存储方式。
  • 纹理ID：1字节（最多256种纹理）。
  • 量化标志 (Quantization Flags)：1字节，描述面的存储方式和UV。
    • 纹理缩放被完全忽略。
    • 如果纹理与轴对齐：存储指向的轴方向（X轴3位，Y轴3位），这是一个巨大的优化。旋转纹理很少使用。
    • 如果是地板或天花板（矩形）：存储一个顶点的坐标、宽度和深度。
    • 如果是墙壁（矩形）：存储一个顶点、高度、长度和角度。
• 潜在的用户错误 [11:57]
  • 由于优化依赖于关卡在编辑器中的构建方式，容易出现用户错误。
  • 添加了覆盖视图（Overlay View）以可视化每个面的成本，并提供描述性提示，在优化关卡时非常有用。
• 光照 [12:19]
  • 最初尝试动态光照（聚类前向渲染），但没有达到“Quake”的感觉。
  • 最终决定使用预计算的探针光照 (Precomputed Probe Lighting)。
  • 每64单位放置一个探针，地图限制为4000x4000x4000（总计约25万个探针）。
  • 每个探针：向周围光线追踪，并投射16条光线计算反弹光，结果存储在16像素的探针纹理中。
  • 像素着色器根据探针数据进行查找，确定如何照亮像素。
  • 虽然预计算量大，但加载速度快（未进行多线程优化以节省代码字节）。
  • 探针光照不像光照贴图那么精细，但生成快，实体能获得正确的光照。

模型与动画 [13:40]

• 3D模型制作 [13:42]
  • 模型在Blender中创建。
  • 大部分模型使用镜像修改器，引擎会镜像顶点，直接节省50%的顶点存储空间。
• 模型工具与图层系统 [13:56]
  • 使用类似于纹理工具的图层系统。
  • 源图层 (Source Layer)：加载FBX文件，存储顶点、索引和骨骼。
  • 镜像图层 (Mirroring Layer)。
  • 子模型图层 (Child Model Layer)：从之前加载的模型中附加子模型。
• 模型数据压缩 [14:14]
  • 顶点位置、UV和骨骼索引存储在仅4字节（32位）中：
    • X, Y坐标：各7位（范围-64到64）。
    • Z坐标：6位（范围-32到31），因为模型通常宽度大于高度。
    • 骨骼索引：4位（最多16根骨骼，通过镜像可翻倍）。
    • UV坐标：各4位（纹理被划分为16x16个区域，最后一行和一列不可用）。
  • 索引：1字节（最多可存储256个顶点，通过镜像可翻倍）。
• 动画制作 [15:13]
  • 模型工具中创建姿势（Poses），作为后续动画的关键帧(Keyframes)。
  • 每个姿势：存储模型的全局偏移量。例如，角色跑步时Z轴上下轻微移动。
  • 每个骨骼：存储3个旋转角度（各1字节）。
  • 动画：通过关键帧之间的线性插值实现。
• 特殊动画图层 [15:54]
  • 声音图层 (Sound Layer)：关键帧带有声音ID，在实体上播放，用于脚步声、枪声、斧头挥砍等。
  • 精灵图层 (Sprite Layer)：放置3D精灵（主要用于武器闪光）。
  • 动作图层 (Action Layer)：触发游戏内函数，如“射击子弹”、“射击激光”或“生成子实体”。
  • 所有关键帧线性存储，未经压缩。动画在代码中由其第一个关键帧的偏移量定义。

音频 [16:27]

• 音频制作与图层系统 [16:29]
  • 音频制作也通过图层系统完成。
  • 16种可应用的效果：静音(Silence)、噪声(Noise)、正弦波(Sin wave)、方波(Square wave)、三角波(Triangle wave)、锯齿波(Saw wave)、淡入(Fade In)、淡出(Fade Out)、放大(Amplify)（避免音量过低）、速度(Speed)（也影响音高）、混响(Reverb)、回声(Echo)、低通滤波(Low Pass Filter)、从另一个声音复制(Copy from another sound)、包络(Envelope)、咕噜声(Grunt)和哎哟声(Ouch)（后两者是结合原生代码模拟人声）。
  • 图层定义效果应用的范围。
  • “复制”效果允许将更小的声音组合成更复杂的声音，例如电脑音效是由各种小蜂鸣声组合而成。
  • 音频压缩：图层属性直接存储，声音在运行时实时生成，没有特殊压缩。
• 音乐制作 [17:38]
  • 使用自制的追踪器(Tracker)工具。
  • 创建小节(Bars)，然后在音乐轨道中使用这些小节。
  • 最多4个通道，意味着一次只能播放4个小节。
  • 每个小节只能有一种乐器和32帧。
  • 乐器不是程序合成的，而是使用音效，并根据所需的音符调整其音高。
  • 可以对音量进行修改。

代码优化 [18:04]

• 编译器和链接器标志 [18:06]
  • /Os：请求编译器为减小代码大小进行优化，而不是优先速度。
  • /Ob0：禁用内联函数扩展，防止代码重复，从而减小可执行文件大小。
  • /MAP：生成地图文件，列出所有代码段及其大小，用于跟踪代码大小优化进度。
  • /NODEFAULTLIB：阻止链接默认库，这意味着不能使用标准库函数（如字符串操作、数学库、malloc、free、memcpy）。
    • 必须创建自己的函数或使用Windows API函数。例如，使用HeapCreate和HeapAlloc进行内存分配。
    • HeapAlloc的HEAP_ZERO_MEMORY标志允许在分配时将内存归零，避免了额外的代码来手动归零内存。
• 全局变量 [19:35]
  • 将变量定义为全局变量，因为C++中全局变量会自动初始化为零。这可以避免调用memset[<a href="https://youtube.com/watch?v=qht68vFaa1M&t=0">0</a>]，节省代码空间。
  • 例如DirectX 11的渲染状态结构体，通过定义为静态全局变量，节省了几百字节。
• 函数使用 [20:04]
  • 对于频繁重复的代码，创建函数以节省空间（良好的编程实践）。
  • 避免为了速度而展开循环或内联代码，这会增加代码大小。
• 资源存储在代码中 [20:42]
  • 所有资产（纹理、模型、音频数据等）都作为字节数组直接存储在代码中。
  • 这样无需文件I/O，游戏可以打包成单个可执行文件。
  • 这些数据数组由自定义工具自动生成。
• 着色器优化 [20:57]
  • 编写脚本来最小化着色器。
  • 将所有变量名替换为单个字母，并为关键字定义宏。
  • 最终得到一个用于3D的元着色器和一个用于2D的着色器，简化优化工作。
  • 使用顶点颜色来确定网格的渲染方式（是否受光照影响、是否有贴花、水面波动动画）。
  • 水面动画就是着色器中的时间驱动波形扭曲。
  • 整个游戏只有一个着色器来处理所有这些不同的效果。

虚拟机 [21:36]

• 创建虚拟机和自定义语言的原因 [21:44]
  • 自定义语言（“QUOD Script”）允许对字节码进行精确控制，从而节省空间。
  • C++编译器有时会浪费字节。
• QUOD Script的字节码优化 [21:53]
  • 示例：C++代码 entity.velocity.z = 7; 编译后大约10字节。
  • 在QUOD Script中，相同的操作只需3字节：
    • 第一个字节（F0）：操作码，表示“移动(MOVE)”。
    • 第二个字节（D0）：目标符号，包含零页索引、对velocity.z的偏移量和全局索引。
    • 第三个字节（E7）：源符号，包含一个5位的数字（即7的二进制表示）。
• QUOD Script的进一步优化 [22:24]
  • 所有寄存器和全局变量存储在一个256元素的数组中，可以通过单个字节寻址。
  • 最常用的全局变量存储在“零页”（前32个元素）中，进一步优化访问。
  • 函数数量限制在256个，因此函数调用只需2字节（操作码+函数索引）。
• 效果和权衡 [24:49]
  • 将所有游戏逻辑代码移植到QUOD Script后，节省了约2KB空间。
  • 资源加载代码保留在C++中，因为其对速度要求高（生成纹理、音频、探针光照是资源密集型任务）。

经验总结 [25:04]

• 未来项目的改进方向 [25:15]
  • 纹理：改进动画纹理系统（现有系统对于简单动画过于复杂）。
  • 颜色：尝试使用1字节颜色（限制为256色，但图层效果可以扩展颜色范围）。
  • 几何体：
    • 引入样条曲线矢量图形(Spline Vector Graphics)，使非矩形形状的定义更容易（例如墙上的对角线图案、管道）。
    • 开发一个管道工具，利用样条曲线定义弯曲路径。
    • 地图存储方式：考虑存储画刷(Brushes)而非面(Faces)，这可能使碰撞处理更简单和更优，但可能不会节省空间。
    • 模型制作：在编辑器内开发建模工具，通过简单的图元和变形操作来构建模型，而非存储顶点，这将大大节省空间并允许更高的顶点计数和曲面。
  • 动画：对武器闪光等效果使用粒子系统，而非精灵动画，因为后者制作困难且效果不佳。
  • 音频：重新设计为节点式系统，每个节点可以反馈到之前的节点或自身，从而创建更复杂的音效。未来考虑使用MIDI。
  • 编译器：引入更复杂的编译器优化，如LLVM，以移除死代码和冗余，进一步优化字节码。
  • 运行时：考虑即时编译（Just-In-Time Compile），而非构建和运行虚拟机，这可能减少C++样板代码，并提高运行时性能。
• 展望 [27:39]
  • 作者期待在未来的项目中尝试这些改进。