《钉身》是一款以 “随机房间战斗” 和 “武器流转” 为核心的 2D 横版 roguelike 动作游戏，玩家在被钉固定的世界中夺取武器、清理房间，并通过不断变化的房间组合完成一局局循环挑战。
设计思路
《钉身》是我的毕业设计。我最初想做的是一款打起来足够爽快的动作游戏。我很喜欢《迈阿密热线》中快节奏的战斗体验，所以在《钉身》中，我希望保留这样“快节奏”的动作体验。玩家需要在横版空间中快速接近敌人、躲避攻击、拾取或更换武器，并在一次次战斗中得到直接的打击反馈。
同时，因为我的论文方向是二维横版游戏中的随机生成式关卡设计研究，所以我需要在保证动作体验足够丰富的前提下，将关卡结构、房间组合、敌人配置和奖励内容做成可以变化的系统。
所以《钉身》的制作目标变成：
在一个爽快动作游戏的基础上，加入随机生成关卡，让玩家每次进入关卡时都能面对不同的路线、战斗节奏和资源选择。
根据目标，我将项目目标拆成三个部分：
稳定的关卡结构
该游戏需要有主路径、分支路线、房间连接点和边界规则，来维持稳定的关卡结构，保证每局的体验在约束范围内有所不同。
可组合的玩法内容
敌人、武器、奖励、陷阱等内容通过生成点和配置规则放入不同房间，让每次流程产生不同的战斗压力。
便于迭代的制作方式
由于我同时负责玩法、关卡、程序原型和美术内容，而项目需要不断测试和调整，所以我在制作时尽量使用 Inspector、Prefab、场景标记点等组织内容，让后续修改配置时不需要重写大量代码。
系统拆解
随机关卡与房间模板
为了服务论文中的随机生成方向，我参考《以撒的结合》的关卡生成方式，让整个关卡根据关卡生成规则由预制房间块自动生成。
首先，为了保证关卡的稳定生成，我采用主线+可选支线的关卡整体结构。同时确定会出现的房间类型（入口房、战斗房、陷阱房、奖励房、Boss房等），关卡按照生成规则从对应类型的房间池抽取预制房间块进行生成。
预制房间块在制作时，我会根据功能确定与其他房间块的连接位置、平台布局、敌人位置与机关位置，从而保证单个房间在局部层面也具备可玩性。
武器与战斗反馈
游戏玩法主要围绕战斗进行设计。游戏内，手中一次只能持有一件武器，因此拾取新武器意味着对当前攻击方式的替换。这样的设计一方面简化了复杂的装备管理，另一方面也使武器选择本身成为即时决策的一部分。
在武器系统设计中，我让玩家与敌人共用同一套武器配置。武器的伤害、攻击范围、冷却时间、投射物、掉落规则等参数统一由配置管理，玩家拾取后可以作为当前武器使用，敌人则可以根据配置调用对应的攻击方式。这样既减少了重复制作，也让敌人死亡掉落武器、玩家拾取替换武器的循环更加自然，武器系统同时服务于玩家战斗、敌人配置和关卡奖励。
武器 | 攻击类型 | 伤害 | 攻击范围 / 射程 | 冷却时间 | 投射物速度 | 投射物生命周期 | 击退 | 掉落规则 |
羊角锤 | 近战 | 10 | 约 1.2 格 | 0.45s | 无 | 无 | 中 | 可由近战敌人死亡掉落 |
长钉 | 近战 | 20 | 约 2 格 | 1s | 无 | 无 | 高 | 可由近战敌人死亡掉落 |
钉枪 | 远程 | 20 | 约 6–8 格 | 0.35s | 10–12 | 1.2–1.5s | 低 | 可由远程敌人持有并掉落 |
钉子投射物 | 远程命中单位 | 1 | 由生命周期和速度决定 | 跟随钉枪冷却 | 10–12 | 1.2–1.5s | 低 | 不单独掉落，由钉枪生成 |
武器拾取 / 替换 | 交互 | 无 | 触发范围约 1 格 | 无 | 无 | 无 | 无 | 玩家靠近后拾取，新武器替换旧武器，旧武器掉落 |
为了做出更明确的打击感，我将武器的攻击表现相关需求拆分：
武器 / 功能对象 | 玩法定位 | 美术资源 | UI资源 | 动画 / 表现资源 | 对应系统联动 |
羊角锤 / 近战武器 | 近距离高反馈攻击，适合贴身战斗 | 场景掉落物 Sprite、角色手持 Sprite、挥击特效、命中特效 | 当前武器图标 | 近战攻击动画、敌人受击动画、命中反馈 | 玩家/敌人近战攻击、武器拾取替换、死亡掉落、血量系统 |
长钉 / 近战武器 | 中距离攻击，前后摇较长，需预判攻击 | 场景掉落物 Sprite、角色手持 Sprite、挥击特效、命中特效 | 当前武器图标 | 近战攻击动画、敌人受击动画、命中反馈 | 玩家/敌人近战攻击、武器拾取替换、死亡掉落、血量系统 |
钉枪 / 远程武器 | 远距离安全输出，强调走位和射击节奏 | 钉枪掉落物 Sprite、角色手持钉枪 Sprite、钉子投射物 Sprite、发射特效 | 当前武器图标、剩余子弹药数量 | 远程攻击动画、敌人受击动画 | 玩家/敌人远程攻击、武器拾取替换、死亡掉落、弹药数量 |
钉子/远程武器弹药 | 远程武器的实际命中单位 | 钉子 Sprite、命中特效 | 不单独显示，作为钉枪武器的一部分 | 投射物飞行、碰撞消失、命中反馈 | WeaponProjectile、墙体碰撞、血量系统 |
武器数据可以配置，场景中可以生成拾取物，玩家持有武器后 UI 会同步显示，后续也可以继续扩展更多攻击方式。
敌人与房间内容
敌人和陷阱并不是单独存在的功能，而是影响房间节奏的内容。
同样大小的房间，如果放入近战敌人、远程敌人、爆炸桶或尖刺，玩家的行动路线和战斗压力都会不同。
所以我在配置敌人与交互物时，会把它们和房间空间一起考虑：
房间是否适合近距离战斗？
玩家是否有足够反应空间？
敌人分布是否能形成压力？
奖励是否能让玩家愿意进入分支？
AI辅助开发
我是美术背景出身，因此选择用 AI 辅助补足代码实现能力，把更多精力放在原型验证和功能验收上。在《钉身》的原型制作中，我使用 Codex 辅助完成基础功能开发。
每次开始任务前，我会要求Codex先阅读项目状态和代码索引，只处理当前需求相关的文件，不做全仓扫描，不删除、不重命名、不移动已有文件，也不擅自运行命令。这样可以避免 AI 为了完成一个小功能而改动太多无关内容，也能保证项目结构稳定。
其次，我会让 Codex 在每轮完成后自动更新项目日志。比如
STATUS.md 记录当前完成了什么、下一步是什么、有哪些已知问题、测试步骤是什么；CODEBASE_INDEX.md 只记录新增或职责变化的核心脚本。这样下一次继续制作时，不需要重新解释整个项目，也不需要让 AI 重新扫描所有文件，减少上下文成本。
在具体制作上，我先让 AI 协助完成最基础、最小可验证的原型功能。按照《钉身》的实际制作过程，大致是先建立可以运行的基础框架，再逐步加入玩家移动、攻击、武器拾取替换、HUD 显示、敌人行为、敌人掉落、房间模板、生成标记、奖励房、机关和循环流程。每一轮我都会先验证这个功能是否能独立运行，再继续拆下一个需求。
验证成功后，我会继续把更大的玩法目标拆成更小的系统任务。比如“做武器系统”不会一次性要求完成所有内容，而是先做武器数据，再做拾取替换，再做攻击逻辑，再做 HUD 刷新，再做敌人掉落。这样每一步都有明确的输入、输出和验收标准，出问题时也更容易定位。
如果功能不符合预期，反馈时我会尽量使用这种格式描述问题：在什么场景下做了什么操作，实际发生了什么，预期应该是什么，我怀疑可能是哪一块逻辑的问题。这种反馈能让 AI 更快定位问题，也减少反复试错和无效 token 消耗。
所以我的 AI 工作流可以概括为：先约束 AI 的工作边界，再让它协助制作最小可验证功能；功能通过验证后，再继续拆分需求逐一扩展；每轮结束后自动更新日志；遇到问题时用复现现象、预期结果和可能原因进行精准反馈。 在这个过程中，AI 主要提高实现效率，而玩法目标、需求拆解和最终验收仍然由我负责。
游戏展示/Demo试玩
Demo下载试玩：