《便当勇者传》是六人团队在 48 小时 Game Jam 中完成的游戏，以饭盒构筑和自动战斗为核心循环。我在项目中兼任组长、策划与程序，参与开发范围确定、系统设计、实现整合和最终验收。玩家承担队伍后勤职责，通过购买食材、分配共享资源和安排饭盒空间，为战士、猎手和法师配置战斗能力。最终版本包含市场、食材管理、三名角色的饭盒构筑、自动战斗、关卡推进和 Boss 战，能够完成从准备到战斗、再到后续关卡的完整流程。借助 AI 辅助的资料整理、任务拆分和程序实现，团队在两天内完成的内容量与完成度超过了最初预期；相应地，需求描述、任务衔接和验收也成为开发中需要集中处理的问题。
构筑机制
玩家的主要决策集中在战前准备阶段。战士、猎手和法师分别拥有独立饭盒，但共享食材仓库，因此每次购买和分配都涉及队伍内部的资源取舍。食物按照形状拖入饭盒，可以旋转和重新排列；饭盒初始为 3×3，后续可在 6×8 的范围内扩张。空间、价格和角色定位共同限制构筑：能够买到的食物未必适合当前布局，能够放入的食物也未必符合角色需要。共享仓库使三份饭盒之间产生联系，玩家需要同时考虑单个角色的配置和整支队伍的资源分配，而每次扩张又会改变可容纳的形状与组合范围。
游戏共包含 54 种食物和 6 类羁绊，三件同类别食物可以触发羁绊，其强度进一步受到占用格数影响。因此，构筑需要同时处理形状排列、类别组合和角色分工：同一种食物用于战士时可能侧重生存，分配给猎手或法师时则会进入不同的搭配。准备结束后，三名勇者自动战斗，购买与摆放的结果体现为伤害、承伤和技能表现。设计上，我希望这一阶段能够反馈构筑效果，让玩家根据实际战斗结果判断食材分配与组合是否合适，并将这些判断用于后续购买、整理和路线选择。
需求定义
48 小时的排期要求团队尽早确定可交付范围。我们先在策划案中明确核心循环、系统关系、内容范围、数据格式和验收条件，并区分当前版本的必要内容与尚待讨论的想法。三名角色的分工、食物分类、羁绊触发条件，以及市场与掉落的连接方式，都需要形成可供程序、美术和 AI 共同使用的规则。只停留在口头讨论中的需求，拆成多个开发任务后容易产生不同解释，进一步影响数据和界面的接入。前期将这些关系写清楚，减少了后续反复说明与返工，也让美术能够根据确定的界面用途和资源规格开始制作，程序按相同规则并行实现。
开发流程
策划案交给 AI 后，先整理为设计说明，确认系统关系，再生成阶段计划，将市场、饭盒编辑、食物效果、自动战斗、关卡推进和界面接入拆成单项任务，在 Godot 工程中逐步实现。每项任务明确修改文件、预期行为和验收方式，完成后经过自动检查与人工试玩，再记录进度并提交 Git。以食物旋转为例，验收需要检查旋转后的形状是否越界、占格是否正确、重新载入后状态是否保留，以及界面反馈是否清楚。这样，一项功能的完成状态就能对应到具体行为；出现问题时，也可以追溯到相应的设计说明、实现任务和修改记录。
策划案
-> 设计说明
-> 阶段计划
-> 单项实现
-> 自动检查与人工验收
-> 进度日志
-> Git 提交进度日志采用只追加、不覆盖的方式，Completed 记录已完成内容，Next 标记可接手的任务，Blockers 保存需要策划或其他成员确认的问题，Files Touched 列出本轮修改文件。这些记录主要解决任务切换和上下文丢失：成员接手其他工作，或 AI 开始新一轮开发时，可以先读取项目状态与历史记录，再继续实现。Git 提交提供代码变更，日志补充任务进度和待确认事项，两者结合后，可以查明某项需求在哪轮实现中发生变化，也能区分已经完成、等待接入和仍受阻的工作。
协作复盘
我的前期工作主要是确定开发范围、跟进进度、对接美术需求，并将饭盒构筑、角色定位、食物系统和战斗循环写入策划案；文档稳定后，重心转向核心系统的实现、整合和最终验收。策划、程序和美术围绕已经确认的文档并行工作，遇到规则冲突或资源依赖时，由我集中确认取舍，避免不同任务各自采用不同解释。这种安排要求策划在规则、数据关系、优先级和验收方式上提供更明确的约束，也要求组长持续处理任务之间的依赖，保证已完成的内容能够接入同一个可玩版本。
这是我第一次较完整地以这套流程组织 AI 辅助开发。就本次项目的体验而言，资料整理、任务拆分和部分程序实现的速度提高后，团队可以在有限时间内尝试更多内容，但需求歧义也会更快进入实现。过去能够在开发中口头补充的规则，需要更早落实到文档，并与数据和验收要求一起交给执行者。因而，这次协作中策划案的作用很具体：它确定了三份饭盒如何共享资源、各系统怎样连接，以及功能做到什么程度才可验收。前期在这些问题上的投入，减少了后续沟通和返工，也支撑了六个人在两天内并行完成游戏。