Game Boy 自制游戏开发并没有想象中那么遥远。在 4.19MHz 的 CPU、8KB 显存、160x144 分辨率和 4 级灰阶这些硬约束下《黑城堡 2》这类像素动作冒险游戏仍然可以靠 GBDK 这套 C 语言工具链完整跑通。这篇文章以《黑城堡 2》的开发为主线记录从硬件约束理解、环境搭建、地图与对象设计、核心代码实现、ROM 构建到实机烧录验证的完整流程。目标读者是有 C 语言基础、想尝试 Game Boy 自制游戏的开发者学完之后能用自己的工具链做出一颗可以在模拟器和实机上运行的最小 ROM。《黑城堡 2》作为教学对象采用横版动作冒险形态核心循环收敛为“探索城堡、击败敌人、收集钥匙、开启出口”。下面所有代码和配置都是这套最小循环的实现示例实际项目里要替换成自己的包名、资源路径和关卡数据但整体流程可以原样复用。1. 先理解 Game Boy 自制游戏的硬约束与工具链1.1 硬件规格决定了所有代码写法的上限Game Boy 的屏幕只有 160x144 像素颜色的“彩色”也只是 4 级灰阶同时最多显示 40 个精灵但每条扫描线最多只能显示 10 个精灵。这些数字不是历史背景介绍而是写代码时必须遵守的物理边界。做《黑城堡 2》时一个房间里放多少敌人、敌人能不能同屏出现首先不是美术问题而是“每行 10 个精灵”和“每帧 16.7ms 计算时间”共同决定的逻辑问题。内存方面更需要提前理解。Game Boy 的 8KB VRAM 要同时承担 tile 数据、背景地图和窗口8KB WRAM 用来存放运行时变量OAM 只有 160 字节每个精灵属性占 4 字节。因此tile 数量要精打细算一个 8x8 的 tile 占 16 字节整个显存最多容纳 384 个 8x8 tile。背景地图默认是 32x32 个 tile可以用“地图数组”的方式直接编译进 ROM。精灵的 x、y、tile 索引、属性标志都放在 OAM 中每次更新要经过影子 OAM 和 DMA 搬运。下面这张表整理了对开发者最有用的内存区域地址范围大小用途开发注意点0000-3FFF16KBROM Bank 0固定代码区启动入口和中断向量4000-7FFF16KBROM Bank 可选区大 ROM 靠 MBC 芯片切换 bank8000-9FFF8KBVRAMtile、背景地图、窗口A000-BFFF8KBSRAM电池存档需要 MBC 开启片选C000-DFFF8KBWRAM游戏运行时变量FE00-FE9F160BOAM精灵属性数据FF00-FF7F128BI/O 寄存器LCD、输入、声音和中断控制在 C 语言里写代码时不一定直接操作每个地址但理解这张表后面排查黑屏、花屏、精灵闪烁和存档丢失时才知道问题出在哪个区域。1.2 开发方式选型GBDK C 还是 RGBDS 汇编自制 Game Boy 游戏的主流开发路线有两条GBDK-2020基于 SDCC 的 C 编译器工具链社区持续维护封装了显示、输入、中断和声音的常用接口适合逻辑量较大的完整游戏。RGBDS汇编工具链包含 rgbasm、rgblink、rgbfix、rgbgfx适合精确控制显存、时序和性能极限。两者的选择直接影响后续所有代码写法放在一起对比更直观对比项GBDK-2020RGBDS语言C汇编上手难度中低高硬件控制程度封装度高完全直接性能上限依赖编译器生成代码可以人工精细控制适合对象完整小游戏、原型验证引擎开发、极限优化《黑城堡 2》选择 GBDK-2020。原因很实际这个游戏有完整的输入、碰撞、敌人 AI、道具和过关切换逻辑用 C 表达更安全迭代更快遇到问题也能用调试器逐步排查。汇编不是不可以只是会让起步阶段的排错成本高出很多等 C 版本跑通后再针对热点函数做汇编优化是更稳的路径。1.3 一条完整的交付链路从源码到实体卡带完整链路是源代码和资源 - 编译链接 - ROM 文件.gb- 模拟器验证 - flash cart 烧录 - 实机运行。在模拟器上跑通只说明游戏逻辑在“模拟环境”里正确不代表在实机上兼容。ROM 的 header 校验是否正确、MBC 类型是否匹配、SRAM 存档是否可用、精灵在一行内超过 10 个时怎么表现这些都需要在实机上验证至少一轮。后面第 5 章和第 6 章会分别给出验证和排查方法。2. 搭建开发环境工具链不对齐报错会很难看懂2.1 依赖清单与版本确认Game Boy 自制开发的环境并不复杂但工具版本必须对齐。混用老版本 GBDK 的头文件和 2020 版本的工具编译期可能不报错运行期却会出现各种诡异现象。工具作用安装说明GBDK-2020C 编译器、链接器和游戏库从官方仓库的 release 页下载注意环境变量Make构建驱动Linux/macOS 自带Windows 可用 MSYS2 或 ChocolateySameBoy高精度模拟器适合验证兼容性和调试Emulicious调试模拟器可以观看 VRAM、OAM、中断和 CPU 占用png2asset将 PNG 图片转换为 C 数组GBDK-2020 自带或单独下载rgbfixROM header 修正工具来自 RGBDS 工具链安装完成后先确认工具能正常执行。以 GBDK 和 Make 为例lcc --version make --version不同系统的输出格式不一样关键是命令能被找到。如果提示“command not found”说明环境变量没有生效优先处理这一步不要急着开始写代码。2.2 安装 GBDK-2020 后要确认环境变量GBDK-2020 解压后包含bin和include两个关键目录。在 Linux/macOS 上可以把bin目录加入 PATHexport GBDK_HOME/opt/gbdk export PATH$GBDK_HOME/bin:$PATHWindows 则在系统环境变量里追加对应的 bin 路径。这里有个常见坑GBDK 的头文件路径、库文件路径和lcc必须来自同一套版本不要图方便把多个版本的 GBDK 全部放进 PATH。多个 GBDK 版本混在一起时lcc会找到旧头文件最终生成错误的 ROM。2.3 项目目录结构如何组织建议把源码、资源和构建产物分开目录结构可以参照下面这种black-castle2/ ├── Makefile ├── src/ │ ├── main.c │ ├── player.c │ ├── enemy.c │ └── level.c ├── assets/ │ ├── png/ # 原始美术资源 │ ├── tiles/ # png2asset 转换后的 tile 数组 │ └── maps/ # 地图数组 └── build/ # 构建中间文件和 ROM这样划分的理由很直接美术资源与代码分离后重新导出一张图不用动逻辑代码build目录专门放中间文件清理时不会误删源码和原始资源。2.4 Makefile 的最小写法制作一个可复现的构建脚本比每次手动敲编译命令更可靠。最小 Makefile 可以这样写CC lcc TARGET build/black_castle2.gb SRCS src/main.c src/player.c src/enemy.c src/level.c $(TARGET): $(SRCS) mkdir -p build $(CC) -o $(TARGET) $(SRCS) clean: rm -rf build这个 Makefile 的核心价值是不管换了机器还是换了平台只要 GBDK 版本一致执行make就能得到 ROM。GBDK 的lcc内部会完成编译、链接、生成.ihx中间文件和最终.gb文件的整套流程。更复杂的 bank 切换、自动 bank 分区、调试符号选项等游戏超过 32KB ROM 之后再按版本文档加入初期不要堆太多开关。2.5 学习环境和正式交付环境的差异学习阶段可以直接在模拟器里反复跑改代码、重编译、看效果这个循环越短越好。但正式交付时环境要多考虑几层学习环境只要 GBDK 和模拟器重点验证玩法和逻辑。测试环境用高精度模拟器做回归验证存档、声音、精灵溢出边界。实机环境通过 flash cart 跑实体硬件验证引导 Logo、画面撕裂、按键手感、存档断电保持。第 5 章会对实机验证做更具体的说明。这里先记住一个原则模拟器通过不等于可以发布实机通过才算基本可用。3. 黑城堡 2 的地图、对象和 tile 数据设计3.1 背景地图是 tile 编号不是像素颜色Game Boy 背景由 8x8 的 tile 铺成。一个 32x32 tile 的地图就是 1024 个字节的数组。数组里存的是 tile 编号不是颜色值。颜色由调色板寄存器统一决定。《黑城堡 2》的地图数组可以这样声明#define MAP_W 32 #define MAP_H 32 const unsigned char level_map[MAP_H][MAP_W] { {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, {1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}, {1,0,0,2,2,2,0,0,0,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}, // 实际关卡数据会很长这里省略中间行 {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}, };tile 编号的含义要靠独立的属性表解释。建议把“这个 tile 能不能碰撞”和“这个 tile 画成什么样”分开管理const unsigned char tile_property[] { 0x00, // 0 空白 0x01, // 1 墙实心 0x01, // 2 地面实心 0x02, // 3 单向平台只能从上方落下 0x04, // 4 出口 };这样设计的好处是修改某一关的碰撞属性时不需要改绘制代码修改地图布局时也不需要知道 tile 具体长什么样。碰撞检测只查属性表显示逻辑只查 tile 编号。3.2 角色和敌人的对象建模Game Boy 是 8 位机虽然 C 编译器支持int但在内存和 CPU 占用上能用UINT8和INT8就不要用 16 位。角色和敌人可以共用一个 Actor 结构typedef struct { INT8 x; // 精灵左上角 x INT8 y; // 精灵左上角 y INT8 vx; // 水平速度 INT8 vy; // 垂直速度 UINT8 tile_base; // 精灵 tile 起始编号 UINT8 hp; // 生命值 UINT8 state; // 状态待机、移动、攻击、死亡 UINT8 on_ground; // 是否站在地面上 } Actor;主角和敌人都复用它只是初始参数不同。敌人数量受“每条扫描线最多 10 个精灵”限制所以关卡里同时活跃的敌人不宜太多。设计《黑城堡 2》的关卡时一个屏幕内建议控制在 6 到 8 个敌人以内给主角、弹道和特效留出精灵余量。3.3 tile 数据生成png2asset 的使用思路在 GBDK 里tile 数据本质是“每个像素 2 位”的索引数组。一个 8x8 tile 共 16 字节。手写这种数组不现实常见做法是用 png2asset 把 PNG 转换成 C 数组。用法类似于png2asset assets/png/hero.png -spr8x16 -sw 16 -sh 16 -o src/hero_tiles.c这里把主角图片按 8x16 的方式切分因为 Game Boy 精灵支持 8x8 和 8x16 两种尺寸角色通常用 8x16 更自然。生成后的.c文件会包含 tile 数组在 main 里通过set_sprite_data交给显存。转换时要注意几个点PNG 必须按像素绘制不要期望引擎帮你缩放。颜色数量要控制在 4 级以内甚至可以先用黑白稿设计。转换后的数组大小、命名和内存布局以当前 GBDK 版本的 png2asset 输出为准。4. 用 GBDK 实现黑城堡 2 的最小可玩循环4.1 初始化顺序先关屏、再搬数据、最后开屏显示初始化最容易犯的错是边写显存边开屏这会导致画面出现半更新状态的撕裂。推荐顺序是关屏、加载调色板和 tile、设置背景地图、设置精灵、开屏。#include gb/gb.h #include hero_tiles.h #include level_map.h void main(void) { DISPLAY_OFF; // 调色板0xE4 是常见的四档灰阶配置 BGP_REG 0xE4; OBP0_REG 0xE4; // 加载背景 tile 和背景地图 set_bkg_data(0, 12, level_tiles); set_bkg_tiles(0, 0, MAP_W, MAP_H, level_map); // 精灵使用 8x16 模式 SPRITES_8x16; set_sprite_data(0, 2, hero_tiles); set_sprite_tile(0, 0); move_sprite(0, 24, 96); SHOW_BKG; SHOW_SPRITES; DISPLAY_ON; while (1) { // 游戏循环主体 wait_vbl_done(); } }DISPLAY_OFF的关键作用是避免在显存写入过程中产生画面残影。SPRITES_8x16必须在使用精灵前调用否则精灵属性解释方式不对画面会出现错位。move_sprite的参数是像素坐标不是 tile 坐标这个容易搞混。4.2 输入读取与按键状态机GBDK 提供joypad()函数读取按键状态返回的是一个位掩码。直接把这个值当作“按下事件”使用会出现按住时每帧都触发的问题。比如跳跃逻辑希望“按一下跳一次”就需要检测按键从“没按”到“按下”的上升沿UINT8 keys 0; UINT8 prev_keys 0; while (1) { prev_keys keys; keys joypad(); // pressed 表示这一帧新按下的键 UINT8 pressed keys (~prev_keys); if (pressed J_A) { // 跳跃 } if (keys J_RIGHT) { // 持续右移 } wait_vbl_done(); }这种按键状态机的价值在于区分“持续按住”和“新按下”。《黑城堡 2》里的移动用keys跳跃用pressed分别满足两种完全不同的交互需求。不要用同一个状态去处理两类逻辑。4.3 玩家移动和重力在横版动作游戏里重力不需要物理引擎用一个每帧累加的速度量即可。简单模型是每帧给vy加一个固定步长再把vy加到 y 坐标上最后做碰撞修正。void update_player(Actor *player, UINT8 keys) { player-vx 0; if (keys J_LEFT) player-vx -1; if (keys J_RIGHT) player-vx 1; // 重力累积 player-vy 1; if (player-vy 4) player-vy 4; // 先移动 x再移动 y分轴处理更容易定位碰撞问题 player-x player-vx; if (check_collision(player)) { player-x - player-vx; } player-y player-vy; if (check_collision(player)) { if (player-vy 0) { player-on_ground 1; } player-y - player-vy; player-vy 0; } }这里注意两个要点分轴移动而不是同时把 x 和 y 加上去这样当碰撞发生时可以明确知道是哪一轴发生了碰撞方便分别处理水平阻挡和落地。速度上限要控制。Game Boy 每帧只有约 16.7ms速度值过大时物体可能直接穿过薄墙出现“隧穿”问题。4.4 基于 tile 的碰撞检测碰撞检测最简单的做法是检查角色四个角所在的 tile 是否实心。像素坐标除以 8就得到 tile 坐标UINT8 get_tile(UINT8 px, UINT8 py) { UINT8 tx px 3; UINT8 ty py 3; if (tx MAP_W) tx MAP_W - 1; if (ty MAP_H) ty MAP_H - 1; return level_map[ty][tx]; } UINT8 is_solid(UINT8 tile) { return tile_property[tile] 0x01; }判断角色是否碰到实心区域时检查左上、右上、左下、右下四个角UINT8 check_collision(Actor *player) { UINT8 l player-x; UINT8 r player-x 7; UINT8 t player-y; UINT8 b player-y 7; return is_solid(get_tile(l, t)) || is_solid(get_tile(r, t)) || is_solid(get_tile(l, b)) || is_solid(get_tile(r, b)); }这种检测方式在《黑城堡 2》这种 tile 平台上足够稳定而且每帧计算量很小。需要优化的地方是不要对场上每个对象都重新遍历整个地图数组而是直接通过坐标索引到对应 tile复杂度是 O(1)。4.5 敌人巡逻、道具拾取和过关判定敌人 AI 先做最简单的巡逻模式向前走撞墙则转身。对应代码可以写成void update_enemy(Actor *enemy) { enemy-x enemy-vx; // 撞墙或走到地图边界时反向 if (check_collision(enemy)) { enemy-x - enemy-vx; enemy-vx -enemy-vx; } }道具拾取和过关判定都依赖距离判断也就是两个 AABB 是否相交。比如钥匙在某个 tile 上主角碰到钥匙后打开出口出口 tile 从不可通过变为可通过最后主角站到出口 tile 上进入下一层。UINT8 player_reached_exit(Actor *player) { return get_tile(player-x, player-y) 4 || get_tile(player-x 7, player-y) 4; }这一层逻辑要放在主循环里每一帧执行保证玩家按键后的下一帧就能反馈。4.6 主循环节奏控制Game Boy 的刷新率约 59.7fps也就是每帧大约 16.7ms。所有计算、显存更新、声音更新都要尽量在这一帧内做完。GBDK 里最基础的做法是wait_vbl_done()等垂直同步到来时再进入下一帧while (1) { read_input(); update_player(); update_enemies(); check_pickups(); check_win(); update_sprites(); wait_vbl_done(); }update_sprites()这一线要保证在 VBlank 期间搬精灵数据否则可能出现画面撕裂。使用 GBDK 时常用的set_sprite_tile和move_sprite会写入影子 OAM再由 OAM DMA 在 VBlank 期间搬运。不要在非 VBlank 阶段频繁直接写 OAM 区域。5. 构建、模拟器验证和实机烧录5.1 编译并检查 ROM 产物构建命令不复杂make clean make ls -l build/black_castle2.gb编译成功后先检查 ROM 文件的基础信息文件大小是否正常。基础 ROM 是 32KB 的整数倍使用 MBC 后按卡带规格继续增大。打开模拟器查看 Cartridge Info确认 ROM 名称、MBC 类型、RAM 大小等 header 字段是否和预期一致。如果 header 校验异常优先使用 RGBDS 工具链里的rgbfix重算 ROM 头字段。具体参数以当前版本rgbfix -h的帮助信息为准。这一步看起来很基础却是实机无法启动的常见原因。很多自制游戏不是代码写错而是 ROM 头不规范。5.2 模拟器里的验证要点模拟器验证不能只看“能走能跳”。建议按下面的顺序检查冷启动画面是否正常Nintendo 引导 Logo 是否花屏。主角移动、跳跃、落地和碰撞是否稳定快速操作是否出现穿墙。同屏敌人较多时精灵是否闪烁主角是否被错误遮挡。拾取钥匙、开门、进入下一关的切换是否完整。如果游戏有存档写入存档后关闭模拟器再打开确认数据不丢。SameBoy 是精度较高的模拟器适合做兼容性验证。Emulicious 适合做深入调试可以直接查看 VRAM 里的 tile 数据、OAM 里的精灵属性和每帧 CPU 占用。遇到怪问题时先用 Emulicious 的调试器看中断和显存状态比直接猜代码更高效。5.3 烧录到 flash cart 后的实机差异模拟器跑通之后至少要在一台实体 Game Boy 或兼容掌机上验证一轮。常见 flash cart 有 EverDrive GB、BennVenn 等成熟产品也有 FPGA 开源方案具体烧录方式以购买产品的说明书为准。实机和模拟器的主要差异集中在下面几点LCD 响应时间不同快速移动时模拟器看起来平滑实机可能出现残影感。精灵在每行超过 10 个时的遮挡顺序实机表现取决于 OAM 排序。存档写入 SRAM 后必须断电再开机验证模拟器里的“存档成功”不代表电池供电正常。按键手感和输入延迟模拟器无法完全模拟实体按键的抖动和回弹。如果实机出现黑屏、花屏或启动后白屏大概率不是玩法逻辑问题而是 ROM 头或 MBC 配置问题回到 5.1 检查。5.4 性能观察与资源余量用 Emulicious 或高精度模拟器观察每帧 CPU 占用。如果主循环接近 16.7ms 上限后面加内容一定会卡顿。优先优化顺序是减少非 VBlank 期间对 VRAM 的写入。减少每帧遍历的敌人数量对象更新尽量只在活跃区域内。精灵更新做到“变化才更新”不要每帧对所有精灵重新 move_sprite。关卡切换时的大批量 tile 写入拆到多个 VBlank 里完成。《黑城堡 2》这类动作游戏帧数稳定比分辨率提升更重要。稳定 59.7fps 的流畅感和偶尔掉帧的“高效果”玩家会第一时间感受到差别。6. 常见问题黑屏、闪烁、输入失灵和存档丢失6.1 黑屏或花屏现象是模拟器或实机启动后只有黑屏、白屏或杂乱条纹。可能原因很多按优先级排查现象可能原因检查方式处理建议模拟器打开即黑屏ROM header 校验错误查看模拟器 Cartridge Info用 rgbfix 重算 header确认 MBC 类型实机花屏显示初始化和显存写入时序不对检查 DISPLAY_OFF 到 DISPLAY_ON 的顺序先关屏再写 tile 和地图最后开屏画面停留在引导 LogoROM 大小不是卡带规格整数倍查看文件大小检查 build 配置和 MBC 设置黑屏问题最容易在“刚搭好环境”时出现。先不要怀疑代码逻辑先用模拟器的信息面板确认 ROM 头是干净可识别的。6.2 精灵闪烁和消失Game Boy 每行最多显示 10 个精灵超过的部分直接不显示这是硬件时刻不是 bug。但可以通过设计缓解同一屏内敌人数不超过精灵预算给主角和道具留位置。重要精灵在 OAM 里排前面保证优先显示。使用 8x16 模式一个角色由两个子精灵组成时总数量会翻倍要重新算预算。敌人从屏幕上边缘移出时主动隐藏其精灵而不是让系统处理越界。问题现象常见原因检查方式处理建议敌人多时主角消失每行精灵数超过 10在密集场景暂停查看 OAM限制同屏敌人数重排 OAM 优先级精灵出现残影影子 OAM 未同步查看精灵数据更新位置更新放在 VBlank或用 wait_vbl_done 同步6.3 输入没有反应或出现连跳输入问题的典型表现是“按下跳跃却跳一下后不再响应”或“按一次却跳两次”。前者的常见原因是逻辑里用了keys J_A这种持续判断而每次按键事件只在按下瞬间成立后者的常见原因是没有做上升沿检测。问题现象常见原因检查方式处理建议按住移动键不正常每帧用了 pressed 而不是 keys打印按键值或打断点移动用keys J_RIGHT跳跃用pressed J_A按一次跳两次上升沿检测缺失检查按键状态机用pressed keys (~prev_keys)实机按键手感奇怪缺少按键防抖对比模拟器和实机在状态机里加上短延迟或只读有效边沿实机上按键抖动和接触不良会更明显模拟器无法完全复现。做动作游戏时建议把输入读取收敛到一个函数里方便统一处理。6.4 存档丢失《黑城堡 2》如果需要保存已解锁的关卡就涉及 SRAM。Game Boy 的 SRAM 不是普通写入就能长期保存必须满足ROM header 里声明了正确的 RAM 大小。MBC 类型支持 SRAM例如 MBC1、MBC3 或 MBC5。写入前打开 SRAM 片选通常向特定地址写使能值。实体卡带需要电池供电或者使用支持铁电存储的烧录卡。问题现象常见原因检查方式处理建议模拟器存档成功实机丢失实机卡带电池没装或耗尽断电再开机验证更换电池或改用带 FRAM 的卡带存档读出来是乱码写入时未关 SRAM 片选查看存档文件长度确认 MBC 和 RAM 设置写入后关闭片选模拟器重启后存档为空模拟器存档文件路径未配置查看模拟器存档目录确认 .sav 文件与 ROM 同名存档是最容易在发布前遗漏的实机验证项。任何涉及存档的功能都要在实体硬件上做“写入-断电-开机-读取”的完整循环。6.5 一套通用的排查优先级遇到问题不要先改代码按下面的顺序缩小范围确认输入是否正确按键值、坐标值是否符合预期。确认文件路径和资源命名是否正确尤其是 tile 数组和地图数组是否被 linker 正确包含。确认 GBDK 版本和依赖版本是否匹配。确认配置是否生效比如显示开关、调色板、精灵模式。确认是否有边界条件比如数组越界、速度过快导致穿墙。看日志和调试器输出优先找明确异常。最后再考虑是否是框架或工具本身的版本限制。这套顺序能覆盖大多数自制游戏初期的报错。多数问题其实发生在第 1 到第 4 步而不是核心算法上。7. 让后续版本少踩坑可复用实践清单7.1 先把资源和性能预算做出来开发《黑城堡 2》之前先给资源做一张预算表比开发到一半发现塞不下再返工高效得多。资源上限参考分配VRAM tile384 个 8x8 tile背景约 256精灵约 128同屏精灵总数40 个主角 1敌人最多 8其余留给特效每行精灵数10 个密集场景下优先保证主角和关键敌人WRAM8KB多用 UINT8 和 INT8少用 16 位临时变量每帧时间约 16.7ms逻辑控制在 60% 以下留出余量这些数字不是建议而是硬约束。搭建 Demo 时就可以用精灵数量上限做压力测试尽早暴露溢出问题。7.2 数据驱动关卡而不是把玩法硬编码进逻辑关卡的地图、敌人出生点和道具位置都应该用数据数组表达而不是写在 if-else 里。比如敌人出生点可以这样定义typedef struct { UINT8 tile_x; UINT8 tile_y; UINT8 type; } SpawnPoint; const SpawnPoint level1_enemies[] { { 6, 5, ENEMY_WALKER }, { 12, 3, ENEMY_FLYER }, { 20, 8, ENEMY_WALKER }, };这样新增一个关卡只加一个数组不需要改动敌人逻辑。美术调地图时也不会误伤代码。这个习惯在项目变大后价值非常明显。7.3 构建可重复、版本可回溯至少做到下面几点源码进入 Git构建产物不入库。build目录可随时删除重建。ROM 文件名带上版本号比如black_castle2_v0.3.gb。每次构建记录 GBDK 工具版本方便后续复现旧问题。如果团队多人协作或需要长期维护可以考虑把 GBDK 放进可复现的构建容器中。重点是保证“同一份代码在任何人的机器上构建出的 ROM 逻辑一致”。7.4 发布前检查清单发布到社区或实机送测前按下表逐项检查检查项验证方式通过标准引导 Logo模拟器冷启动正常显示无花屏Header 校验模拟器 Cartridge Info无 error 标记ROM 大小文件信息与卡带规格匹配MBC 类型模拟器信息与存档需求一致存档读写实机断电重启数据完整保留精灵溢出密集场景实测不闪屏、不死机声音实机试听多通道播放正常手感实机试玩按键响应无诡异延迟这个清单可以贴在项目仓库的 README 里每次 release 前逐项勾选。它比“记得测试一下”这种模糊建议有用得多。7.5 后续扩展方向《黑城堡 2》的核心框架跑通后扩展方向可以按难度递增用 hUGEDriver 这样的音乐驱动库加入背景音乐和音效。增加多关卡和 BossBoss 可以复用 Actor 结构扩展状态机。实现基于 MBC5 的更大 ROM 和存档系统。研究 Super Game Boy 的边框和配色提升展示效果。对热点函数做汇编级优化把帧时间压得更稳。对新手来说最有价值的练习不是一开始就规划 60 分钟的大作而是先让一个方块能在屏幕上移动、跳跃、落地再逐步加上 tile 碰撞、敌人和道具。把这个最小闭环打磨稳定比堆砌大量未验证的功能更能支撑一个长期项目。《黑城堡 2》的下一关可以从一个真正能反复通关的完整关卡开始。