Game Off 2026 主题 SHIFT 怎么收敛：一个月 jam 的范围与交付设计

先把 SHIFT 收敛成一个玩家能反复操作、能观察结果的核心切换，再倒排一个月的交付；不要把“切换”理解成内容越多越好。GitHub Blog 的标题与摘要显示，Game Off 2026 是第 14 年、为期一个月的 game jam（限时游戏开发活动），2026 年 11 月主题为 SHIFT，摘要中列举了换挡、切换视角、弯曲现实或按下某个键（来源：GitHub Blog 的 Game Off 2026 主题公告，标注日期为 2026 年 11 月 1 日）。具体提交截止、资格与评审规则，本次材料未提供，待核实。

SHIFT 先变成一条可测试规则#

主题词不是设计文档。建议用一句话写清：玩家在什么条件下触发切换，切换后哪条规则改变，玩家如何看到结果。示例可以是切换视角、重力或时间线，但这些只是演示方向，不是官方要求。

判断标准可以很具体：建议在 10 秒内能完成一次切换；切换前后画面或规则可区分；失败时玩家能说出“我切错了”还是“我切晚了”。如果做不到，说明核心机制还没收敛。

一个月怎么排：先交付可玩，再交付完整#

按官方时间表倒排，具体日期待核实。建议的四周节奏是：

• 第 1 周：只做核心循环，保证从启动到第一次切换不需要复杂前置。
• 第 2 周：做一个完整关卡或场景，包含失败、胜利和一次教学。
• 第 3 周：补反馈、音效、可读性和边界情况，不加新机制。
• 第 4 周：冻结功能，反复构建，准备操作说明、主题说明和已知问题。

这个节奏是建议，不是 jam 规则。它的作用是让“可玩构建”从第一周就存在，而不是最后一周才出现。

范围预算：保留一个机制，砍掉三类依赖#

表中的取舍是建议。若删掉某个功能后 SHIFT 仍能演示，它大概率不属于最小交付。

技术交付：把外部依赖放在可替换层#

优先使用熟悉的引擎和工具链，减少自研物理、存档和网络。若项目需要外部接口（例如配置或排行榜），可以先写可替换的请求层，让游戏在接口不可用时仍能离线演示；密钥用占位符，不写进客户端。下面只是未执行的示例，用于说明边界，不代表实际运行结果。

// 未执行示例：浏览器/JavaScript 伪代码
// YOUR_KEY 是占位符；真实密钥不应放在客户端
async function loadConfig() {
  const res = await fetch("https://example.com/api/config", {
    headers: { "Authorization": "Bearer YOUR_KEY" }
  });
  if (!res.ok) return { mode: "offline" }; // 失败时保留可玩路径
  return res.json();
}

示例中的 example.com 和 YOUR_KEY 均为占位，未发起真实请求。实际接口契约与可用性待核实。

交付检查#

• 有一个可运行构建，启动后能完成一次切换。
• 有一句话说明游戏如何回应 SHIFT，而不是只写“主题是 SHIFT”。
• 有操作说明、已知问题和素材来源记录。
• 规则、截止时间、提交入口与资格要求以官方页面为准；本文材料未提供，待核实。

结论：SHIFT 的范围收敛，不是把“切换”堆成很多系统，而是让一个切换在有限时间内可演示、可失败、可解释。先做到这一点，再谈完整。