一个月游戏 Jam 的取舍清单：把 SHIFT 主题收敛成可交付原型
据 GitHub Blog 公告，Game Off 2026 为期一个月、11 月举行、主题为 SHIFT。文章建议先把主题定义成可判定的机制，再按四周倒推时间预算，并用取舍清单决定先砍什么、保留什么，同时把构建与提交材料计入范围。官方细则与提交要求本次材料未提供，需以活动页为准。
一个月 Game Jam 的难点通常不在想不出点子，而在于把点子压到能构建、能运行、能提交的范围内。据 GitHub Blog 的公告，Game Off 2026 是第 14 届，为期一个月，11 月举行，主题为 SHIFT（换挡、换视角、扭曲现实，或者只是按某个键）。来源 活动的具体规则、评审口径与提交要求，本次材料未提供，需以活动页面为准。
第一步：把 SHIFT 变成可判定的机制#
主题词越开放，越容易拖到第二周才发现“还没有玩法”。动手前建议用一句话写清四件事：玩家每次 shift 改变的对象是什么（时间、空间、视角、尺度、控制权）；代价是什么；可逆还是不可逆；失败条件是否随之改变。四问写清，机制就能收敛成一个状态机；写不清，说明还在概念阶段。
// 未执行的示例：仅示意“shift 是一次有代价的状态切换”
const shift = { from: 'ground', to: 'air', cost: 1, reversible: true };
function tryShift(state) {
if (state.energy < shift.cost) return state; // 代价不足，拒绝切换
return { ...state, mode: shift.to, energy: state.energy - shift.cost };
}这类示例适合用来验证“代价”和“可逆性”是否成立，不是可以直接使用的游戏逻辑。
按“可交付”倒推四周#
| 阶段 | 目标 | 冻结项 |
|---|---|---|
| 第 1 周 | 垂直切片，并完成一次导出构建 | 引擎与目标平台 |
| 第 2 周 | 核心机制完整，加入最小内容量 | 核心玩法与胜负条件 |
| 第 3 周 | 失败状态、音效、引导，修手感 | 机制不再新增 |
| 第 4 周 | 构建、说明、截图、提交，留 2—3 天缓冲 | 功能范围 |
第 1 周就做一次可发布构建，是为了让导出、分辨率、输入映射这类问题尽早暴露。它们往往不复杂，但会吃掉最后几天。
取舍清单：先砍什么，后砍什么#
- 优先砍：多人或联网、存档系统、程序化生成、多平台导出、本地化、成就与统计。
- 可以后砍：关卡数量、美术精度、音乐曲目数、额外模式。
- 不要砍：核心 shift 的手感、第一分钟的可理解性、能正常启动的构建。
判断标准不是“这个功能好不好”，而是“删掉它，玩家是否仍然能理解并完成一次完整的 shift”。
交付物本身也是范围#
README、操作说明、已知问题列表、第三方素材的许可说明，都属于要交出去的东西。占位资源应统一标注来源，避免临提交前才发现某个素材不可用。具体提交格式与截止时间，本次材料未提供，不要按推测执行。
结论：先定义 SHIFT 改什么、代价是什么，再用四周倒推范围，最后按“可理解性优先”砍功能。主题的开放性留给设计，不留给排期。
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
