Game Off 2026 主题 SHIFT：一个月 game jam 的可交付范围怎么定

先给结论：把 SHIFT 收敛成一个可演示的核心动作，再倒推一个月内必须完成的内容；不要先做“完整游戏”，最后再想主题怎么体现。对一个月长度的 game jam，可交付范围应包含一个可玩闭环、一个能重复启动的构建、一份说明和明确的删减清单。

先把 SHIFT 变成一个可测试的动词#

GitHub Blog 的公告摘要显示，Game Off 2026 是第 14 年、为期一个月的 game jam，于 2026 年 11 月举行，主题为 SHIFT；公告给出的方向包括换挡、换视角、弯折现实，或只是按下某个键（公告）。这些是主题提示，不是要求全部实现的功能清单。

从范围管理角度，建议把主题写成一句可测试的话：玩家执行某个动作后，哪个状态发生变化，这个变化如何影响玩法。例如“按下切换键后，同一关卡的平台与障碍互换位置，玩家要利用互换到达出口”。这句话能写清，才适合进入开发；写不清，说明核心机制还没定。

只选一个主 SHIFT。换视角可以做核心机制，换挡只做叙事或美术隐喻；反过来也可以。四个提示都做，通常会把一个月拆成四个半成品。

用范围表锁住“必须交付”#

开工前写两张清单：必须交付和优先删减。下面是一个内部范围表示例，不是赛事规则；提交要求仍需以官方页面和提交平台为准。

这张表的作用不是预测工作量，而是让每次新增功能都能回答：它替代了哪一项必须交付？如果替代不了，就进入删减清单。

按剩余时间倒排，不按灵感排#

截止时间本次材料未提供，无法给出具体日期。较稳妥的做法是从官方截止时间倒推，并把最后一段时间留给打包和阻断性修复。

1. 第一阶段：只验证核心动作。用占位图形做出“触发—变化—结果”，不写剧情，不做菜单。
2. 第二阶段：做一个完整片段。把教学、变化和收束放进同一关，确保能从头玩到结束。
3. 第三阶段：外部试玩。只记录玩家卡住的位置、误解的规则和无法继续的 bug；不要用“再多做一点内容”填满反馈。
4. 第四阶段：冻结内容。打包、在干净环境启动、补 README、把已知问题列清楚，然后提交；最后阶段不再改动核心机制。

外部 API 与素材：先写失败路径#

如果玩法依赖外部 API，把“接口不可用”当作正常分支，而不是上线前才处理的异常。至少要能说明：请求失败时游戏是否还能继续、是否展示可理解的提示、密钥是否只留在服务端。对 jam 项目，最稳的降级方案往往是本地缓存或离线演示模式；具体接口能力待核实，不要假设接口额度或稳定性。

素材同样属于范围。只使用能说明来源和许可的文件，并在 README 里记录；无法确认授权的素材，不进入提交包。公告摘要没有给出资产规则，因此这里只能作为内部检查项。

提交前只检查能被判定的项#

• 构建能在目标环境启动，并能重开、退出。
• README 写明操作、启动方式、已知问题和素材来源。
• 不用读代码也能完成一次“开始—切换—结束”的闭环。
• 删减清单上的未完成项没有伪装成已完成功能。

对 API.PLUS 的开发者读者，这套方法也可以迁移到小型 API 集成项目：先定义可演示的主路径，再列出失败路径和删减项，最后才补充表现层。Game Off 的具体规则、评审标准和提交格式，本次材料未提供，动手前应直接核对官方页面。