从Shovel Knight到Mina the Hollower：复古Game Boy Color美学下的现代定制引擎开发
中测主题
本期播客深入探讨了由Yacht Club Games开发的复古动作角色扮演游戏《Mina the Hollower》的幕后技术。嘉宾详细解析了为该游戏定制的C++引擎“Propeller”、如何在现代渲染管线中还原并扩展Game Boy Color的音画约束，以及从《恶魔城》中汲取的战斗设计哲学。
基本信息
- 节目：Software Engineering Daily
- 嘉宾：David D’Angelo（Yacht Club Games首席程序员）
- 日期：2026-06-25
- 来源：Software Engineering Daily
- 链接：https://softwareengineeringdaily.com/2026/06/25/mina-the-hollower/
核心观点
Yacht Club Games在《Mina the Hollower》的开发中展现了一种“伪限制性”的开发哲学：不拘泥于硬件的绝对物理限制，而是通过现代的C++定制引擎，以数字化模拟的方式重构Game Boy Color时代的标志性艺术风格与音画体验。游戏的核心竞争力不仅在于还原历史，更在于如何利用现代技术解决复古视角下的渲染遮挡、无缝无载入大世界管理，以及如何通过精心设计的动作帧率限制来创造“硬核且公平”的战斗反馈。
Highlights
- 定制C++引擎“Propeller”：Yacht Club自研了跨平台C++引擎，仅保留了前作《Shovel Knight》的关卡编辑器和动画导入器，底层完全重构，支持在不同主机（如PS5等）之间高效渲染和移植。
- 伪Game Boy Color（GBC）约束：游戏不采取硬件层面的真限制，而是限制每个精灵（Sprite）最多使用3种颜色，并采用基于现代芯片模拟但保留经典波形声道的音轨设计。
- 俯视角（Top-Down）的伪3D渲染难题：不同于侧卷轴游戏，俯视角游戏面临复杂的层级遮挡关系（Z-Ordering）与碰撞箱（Hitbox）立体判定，开发团队通过定制深度排序规则解决了这一痛点。
- 无缝大世界与自动存档机制：游戏移除了加载界面，并在玩家跨越每一个屏幕区域时自动进行后台静默存档，这导致了复杂的碰撞边界判定与存档状态冲突风险。
- 恶魔城式（Castlevania）战斗哲学：摒弃现代动作游戏常见的“随时翻滚打断”机制，采用具有前摇和硬直的判定，强迫玩家利用身体位移和预判进行防御。
长文笔记
1. 跨越世代的“伪复古”：Game Boy Color美学的现代重塑
《Mina the Hollower》在视觉和听觉上致敬了Game Boy Color（GBC）时代经典的《塞尔达传说：织梦岛》和《塞尔达传说：大地/时空之章》。然而，Yacht Club Games并没有使用真实的旧硬件开发，也没有在引擎中强行植入物理层面的硬件模拟器。他们采用的是一种“数字化模拟下的约束”。
在真实的GBC硬件中，调色板的限制是绝对的。尽管GBC允许开发者自定义调色板，但同屏颜色数和每个精灵的颜色数都有严格的硬件上限。在开发中，团队要求美术师在现代数字画布上遵守相同的规则：每个精灵最多只能使用三种颜色（外加透明色）。这种做法保留了复古艺术的“高对比度”与“形状清晰度”，但避免了老旧芯片带来的闪烁和画幅限制。
在音频方面，游戏音乐基于高度定制的音频系统，模拟了GBC经典的波形通道（Waveform Channel）与噪波通道（Noise Channel），但其编曲精细度超出了旧硬件的负荷。通过现代引擎的混音技术，团队得以实现多达三个音轨的实时叠加与动态交互，使音效在符合经典8-bit听感的前提下，具备现代游戏的动态反馈。
2. 定制C++引擎“Propeller”的技术架构与演进
Yacht Club Games为其新项目开发了名为“Propeller”的C++底层引擎。相较于前作《Shovel Knight》使用的引擎，Propeller进行了一次彻底的底层重构。
- 跨平台中间件层：Propeller的核心是一个纯C++编写的渲染、输入、控制器管理和文件I/O框架。针对不同的目标平台（例如Nintendo Switch、PS5、PC），引擎派生出不同的分支。当游戏逻辑发出“绘制精灵”的调用时，Propeller会将该调用分发给具体平台的底层渲染API，实现跨平台渲染。
- 工具链重用与重构：开发团队并未完全抛弃前作的资产，而是保留了关卡编辑器和动画导入器。由于复古游戏极其依赖像素对齐和精准的帧动画判定，保留成熟的工具链极大地缩短了资产导入的开发周期。
- 色板动画工具：引擎内置了专门用于生成调色板循环动画（Palette Swapping）的工具。例如，当角色受到伤害或环境光源发生变化时，引擎无需重新加载纹理，而是直接在显存中替换色板索引，实现毫秒级的色彩过渡。
3. 俯视角（Top-Down）游戏的三维遮挡与碰撞判定
从《Shovel Knight》的侧卷轴（Side-scrolling）转向《Mina the Hollower》的俯视角（Top-Down）RPG，开发团队面临的最大挑战是非写实视角下的深度排序（Z-Ordering）。
在侧卷轴游戏中，背景、前景和角色的层次关系是静态的，开发人员只需将图层从后向前堆叠即可。但在俯视角游戏中，当角色在一个巨大的怪物后面移动时，角色应当被怪物遮挡；而当角色走到怪物前方时，角色则应当遮挡住怪物。
[ 俯视角渲染层级动态判定 ]
( 怪物怪物怪物 ) <- 怪物资产（高深度）
||
[ 玩家 ]- - - - - - -> 当玩家Y轴大于怪物Y轴时：渲染顺序 [怪物] -> [玩家] (玩家遮挡怪物)
||
( 怪物怪物怪物 ) <- 当玩家Y轴小于怪物Y轴时：渲染顺序 [玩家] -> [怪物] (怪物遮挡玩家)Propeller引擎必须在每一帧实时计算所有动态实体（Entity）的Y轴坐标，并将其映射为渲染管线中的深度值。这引发了以下几个技术难题：
- 超大实体的层级计算：对于体型巨大的Boss，其精灵图可能跨越了多个网格。如果仅以Boss的原点（Origin Point）计算Y轴，会导致Boss头部与周围环境的遮挡关系错乱。团队不得不将大实体拆分为多个碰撞与渲染子模块，分别参与深度排序。
- 碰撞箱（Hitboxes）的伪3D判定：在俯视角下，两个角色在屏幕上的“接触”并不一定意味着它们在游戏世界中处于同一高度。引擎需要为实体分配一个隐性的Z轴高度（例如跳跃时），在处理碰撞和攻击判定时，必须将X/Y轴的2D相交与Z轴的高度区间结合，以避免出现“玩家在空中却被地面火球击中”的Bug。
4. 无缝大世界的静默存档与边界漏洞
为了提供沉浸式的探索体验，《Mina the Hollower》去除了传统复古RPG在切换屏幕时的“淡入淡出”加载界面。游戏世界是一个庞大的、连续的无缝地图。
伴随无缝世界而来的是极其频繁的自动存档机制。为了防止玩家因为意外断电或死亡丢失进度，引擎会在玩家每次跨越虚拟屏区边界时，在后台静默保存当前玩家的所有状态（包括生命值、持有的装备、当前屏幕内敌人的消灭状态）。
这一机制导致了大量的“位置卡死”Bug。在开发阶段，经常出现玩家在跨越边界的瞬间触发了某种位移（如被击飞、闪避），导致存档记录的坐标恰好落在了实体的碰撞体内部。一旦玩家重新载入游戏，就会陷入无限卡死的死循环。开发团队为此重新设计了位置回溯算法，在加载存档时，如果检测到角色与周围静态瓷砖（Tiles）重叠，系统会自动将角色安全移至最近的空闲网格。
5. “硬核且公平”：恶魔城式动作设计的机制实现
在现代动作游戏中，玩家习惯了“闪避打断（Dodge Cancel）”——即在攻击动画的任意帧，都可以通过按下闪避键瞬间中断攻击并获得无敌帧。
但《Mina the Hollower》采用了致敬《恶魔城》的硬核设计：攻击一旦发出，动作帧就必须完整播放，玩家在此期间无法通过闪避打断。
- 位置导向（Position-Based）的战斗：游戏的核心防御机制是“钻地（Burrow）”。钻地动作包含一段不可打断的起跳前摇（约30帧）。这意味着玩家不能依靠反应极限去“瞬闪”伤害，而是必须预判敌人的攻击轨迹，提前进行身位移动。
- 逃生阀值设计（Dodge Pendulum）：为了防止这种高惩罚性的动作设计劝退普通玩家，开发团队引入了“闪避钟摆（Dodge Pendulum）”等饰品（Trinkets）。当玩家装备该饰品时，如果受到攻击的瞬间执行跳跃，系统会给予一定帧数的无敌判定。这种设计既保留了硬核的策略博弈，又为不同操作水平的玩家提供了调谐空间。