Game Development

DNTB 地牢编排师 - Game Jam 开发回顾

项目概述

DNTB (Dungeon Arranger: Forbidden Keys / 地牢编排师) 是我在 2026 年 6 月参与开发的一个 Godot 4 战术 Roguelite 游戏原型。项目核心玩法围绕可编程方向键、派生武器技能、网格战斗和类遗物修改器系统。

这是一次特别的开发经历 - 我们团队都是同一所学校的朋友，之前互相认识，但这是第一次一起合作开发游戏。两周的密集开发让我们从陌生的协作者变成了默契的开发伙伴。

基本信息

  • 引擎: Godot 4.7
  • 类型: 战术 Roguelite
  • 开发周期: 2026-06-23 至 2026-07-06 (约 2 周)
  • 团队背景: 同校朋友，首次游戏开发协作
  • 我的贡献: 101 次提交 (占项目总提交的 41%)
  • 主要贡献者: LiaoZiqi-GZFLS (128 commits), Chen Jianye / DarkButSpark (101 commits), unnameduser5000 (12 commits)
  • 当前状态: 由于精力原因暂时停止更新

核心玩法创新

可编程键位系统

游戏最大的创新是可编程键位系统。玩家可以自定义 12 个物理插槽（QWER / ASDF / ZXCV）的按键映射，将方向令牌（U/D/L/R）和特殊动作令牌组合成复杂的战斗序列。

这不是简单的键位重绑定，而是一个可编程的战斗语言：

  • 方向链可以触发派生武器技能（如前前 = 冲锋刺击）
  • 动作追踪系统记录玩家的移动轨迹
  • 武器组合识别器实时分析动作序列

派生武器技能

武器技能不是固定的技能树，而是通过动作模式匹配动态触发：

1
2
前前 (FF) + 冲击盾 = 冲锋刺击
前左前 (FSL F) + 旋风斧 = 大扫掠

这创造了一个深度的战斗系统 - 玩家需要理解武器特性、记忆组合序列，并在战斗中流畅执行。

开发历程

第一阶段：核心架构 (6月23-24日)

任务: 建立可编程键位系统的基础架构

完成的工作：

  • 实现 ActionProgramController.gd 键位编程状态管理
  • 创建 ActionPreviewService.gd 用于动作预览
  • 构建 BattlePresentationController.gd 战斗表现层
  • 实现可等待的动作播放系统（同步测试模式 + 异步表现模式）

技术挑战: 如何让键位编程既灵活又易于测试？我们选择了分层架构 - 核心逻辑与表现层完全分离，支持无头测试和有头表现两种执行路径。

第二阶段：武器系统重构 (6月24-27日)

任务: 从固定技能改为派生武器技能系统

完成的工作：

  • 创建武器组合实验室用于测试
  • 实现自定义角色视图（PlayerActorView.tscn, EnemyActorView.tscn）
  • 构建战斗效果系统（Hit/Miss/Impact/Death 效果）
  • 重构技能系统为方向链驱动的派生技能

设计决策: 最初 lunge/sweep 是可拖拽的令牌，但这限制了战斗的深度。改为派生技能后，玩家需要学习每个武器的"语言"，这大大提升了策略性。

第三阶段：动作追踪 (6月27日)

任务: 实现组合识别的核心 - 动作追踪系统

完成的工作：

  • 创建 ActionTrace.gd 和 ActionTraceEntry.gd
  • 实现 ActionTraceRecorder.gd 追踪玩家动作
  • 构建 WeaponComboResolver.gd 武器组合识别器
  • 引入相对方向语义（F/B/SL/SR = 前/后/左侧/右侧）

技术亮点: 使用相对方向而非绝对方向，让组合识别与玩家朝向无关。这意味着无论你面向哪个方向，"前前"永远触发冲锋。

第四阶段：世界生成 (6月28-30日)

任务: 从小战斗房间扩展到 256×256 大地图

完成的工作：

  • 实现基于 FOV 的世界切片系统
  • 构建程序化地图生成器（山脉/河流/地形/建筑）
  • 创建建筑足迹系统和 POI 放置服务
  • 优化渲染性能（有界 FOV + 固定活动窗口）

性能优化: 最初的连通性检查需要 161 秒，通过打包掩码优化降至 23 秒。渲染从全地图绘制改为仅渲染当前视口，帧率提升 10 倍。

第五阶段：UI/UX 改进 (6月30日-7月4日)

任务: 让复杂系统变得可用

完成的工作：

  • 重做背包页面为实时键位编辑器
  • 实现固定网格布局（告别动态拉伸）
  • 添加设置菜单（音量滑块、键位绑定、地图缩放）
  • 切换到 Camera2D 居中的世界地图

UX 教训: 键位编程系统很酷，但如果玩家不理解如何使用它，就毫无意义。我们花了大量时间打磨背包 UI，让拖放操作直观、令牌悬停显示说明、战斗区域锁定编辑。

第六阶段：内容扩展 (7月3-6日)

任务: 填充游戏循环 - 升级、奖励、内容

完成的工作：

  • 实现首杀攻击令牌奖励
  • 添加 XP/升级系统和随机永久 buff 选择
  • 扩展动作令牌库（钩拉、盾击、锤击、旋风斧、穿刺线）
  • 升级 Boss 节点为大型地牢层
  • 实现 POI 交互和自动寻路
  • 完成保存/加载功能

内容设计: 我们添加了 10+ 种新动作令牌和永久修改器。每个修改器都是一个"构建块" - 玩家可以叠加它们创造独特的构建（如"收割回生" + “追电步” = 击杀治疗 + 移动电击）。

技术架构

分层设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
游戏层次:
├── 数据层 (scripts/data/)
│   ├── ActorDef, WeaponDef, TechniqueDef
│   └── MapData, MapCell, BuildingPattern
├── 运行时层 (scripts/runtime/)
│   ├── GameState, TurnController
│   ├── ActionResolver, ActionTrace
│   └── WeaponComboResolver
├── 控制器层 (scripts/controller/)
│   ├── ActionProgramController
│   ├── BattlePresentationController
│   └── WorldSliceController
└── 表现层 (scripts/view/)
    ├── ActorView, BoardView
    └── BattleEffectController

测试策略

项目包含 3 个自动化测试套件：

  • SmokeTest.gd - 核心战斗循环测试
  • ActorPresentationSandboxSmoke.gd - 表现层测试
  • BattleEffectSandboxSmoke.gd - 效果系统测试

我们使用 GitHub Actions 运行无头测试，每次提交都会验证核心功能。这在快速迭代时至关重要 - 我们可以大胆重构，因为测试会捕获回归。

已知问题与反思

⚠️ 诚实地说

这个项目仍然有大量 bug。作为一个两周的原型，我们优先实现新功能而非打磨现有系统。以下是主要问题：

核心系统

  • 武器组合识别在边缘情况下可能失效
  • 敌人 AI 在复杂地形中会做出不合理决策
  • 保存/加载系统无法完全持久化运行时状态

世界生成

  • 偶尔生成无法到达的 POI
  • 建筑可能生成在不合理位置
  • 敌人流式生成密度不一致

UI/UX

  • 拖放操作在某些情况下响应不准确
  • Camera2D 在地图边缘可能抖动
  • 快速连续输入可能导致动作丢失

性能

  • 256×256 地图在低端设备上卡顿
  • FOV 计算在密集战斗中造成帧率下降
  • 长时间游玩可能出现内存泄漏

如果重来，我会做什么不同？

  1. 更早关注核心循环: 我们在世界生成上花了太多时间。一个小但完善的战斗系统比一个大但粗糙的地图更重要。

  2. 简化键位系统: 12 个物理插槽太多了。8 个就足够，这会让新手入门曲线更平缓。

  3. 先打磨，后扩展: 我们添加了太多动作令牌，但每个都不够完善。5 个打磨好的技能胜过 15 个半成品。

  4. 更多时间在音频上: 我们几乎没有音效。战斗缺乏冲击感，这是个巨大的遗憾。

学到的经验

Godot 4 的强大之处

  1. GDScript 的迭代速度: 修改代码 → 按 F5 → 立即测试。这种快速反馈循环让实验变得轻松。

  2. Scene 系统的模块化: 每个系统（战斗效果、角色视图、建筑足迹）都是独立的 Scene，可以单独测试和迭代。

  3. 信号系统: Godot 的信号让解耦变得自然。我们的战斗表现层完全通过信号驱动，无需硬编码依赖。

团队协作

这是我第一次参与真正的游戏开发协作项目。学到的教训：

  1. 频繁沟通: 当你重构核心系统时，告诉团队。否则会出现合并冲突。

  2. 测试先行: 在添加新功能前先写测试。这听起来慢，但长期来看节省了大量调试时间。

  3. 文档很重要: 我们维护了一个详细的 DEVELOP_LOG.md (10 万字节！)。这让新加入的开发者能快速理解系统。

项目统计

代码量

  • 开发日志: 101,681 字节
  • 我的提交: 101 次
  • 开发天数: 14 天密集开发
  • 核心脚本: 30+ 个新系统脚本

功能完成度

  • ✅ 可编程键位系统（12 物理插槽）
  • ✅ 派生武器技能系统
  • ✅ 动作追踪与组合识别
  • ✅ 256×256 世界生成
  • ✅ 建筑足迹与 POI 系统
  • ✅ 升级奖励循环
  • ✅ 保存/加载功能
  • ❌ 完整的 Boss 战机制
  • ❌ 音频和音乐集成
  • ❌ 最终艺术资产

未来展望

项目目前处于"可玩的原型"阶段。如果要推向完整游戏，需要：

短期 (1-2 个月)

  • 修复高优先级 bug
  • 改进武器系统稳定性
  • 优化大地图性能
  • 完善 Boss 战机制

中期 (3-6 个月)

  • 添加更多敌人类型和 AI 变体
  • 扩展令牌和技能库
  • 实现更多永久修改器
  • 集成完整音频系统

长期 (6-12 个月)

  • 替换为最终艺术资产
  • 平衡调整和玩法打磨
  • 多语言支持
  • Steam 发布准备

结语

DNTB 是一次疯狂的两周冲刺。我们从零开始构建了一个复杂的战术 Roguelite 系统，实现了一些我们自己都感到惊讶的功能（256×256 世界生成真的能跑！）。

项目远未完成，但它证明了核心概念是可行的。可编程键位系统很有趣，派生技能创造了深度，网格战斗感觉不错。

关于暂停更新

由于学业和其他项目的精力分配，DNTB 项目目前暂时停止更新。这并不代表项目的结束，而是一个"暂停键" - 我们都希望有一天能回来继续完善它。

对于一个首次合作的团队来说，能在两周内完成这样一个原型已经是很大的成就。更重要的是，这次经历让我们积累了宝贵的协作经验，为未来的项目打下了基础。

最重要的收获

我学到了很多。关于 Godot，关于游戏设计，关于团队协作，关于在有限时间内做出取舍。但最大的收获是：和朋友一起做游戏真的很快乐，即使过程中有无数的 bug 和熬夜，即使最终项目没能完成，这段经历本身就很有价值。

如果你对项目感兴趣，可以查看我们的 GitHub 仓库。代码是开源的（Apache 2.0 许可证），欢迎 fork 或参考！

项目链接: GitHub Repository
许可证: Apache License 2.0
引擎: Godot 4.7

参与项目的朋友们

LiaoZiqi-GZFLS
LiaoZiqi-GZFLS
大佬
unnameduser5000
unnameduser5000
大佬
DarkButSpark
DarkButSpark
喵喵喵
wentao DAI
wentao DAI
项目贡献者
Jaeger0624
Jaeger0624
项目贡献者
Crab-Dave
Crab-Dave
项目贡献者
DNTB 项目仓库
DNTB 项目仓库
Godot 4 战术 Roguelite 原型