Game Off 2026 的 SHIFT 命题：一个月 Game Jam 的取舍顺序

能确定的部分很少，但足够开工。据 GitHub Blog 的活动公告摘要，Game Off 2026 是第 14 届，为期一个月，在 11 月举行，主题为 SHIFT；公告给出的方向包括换挡、切换视角、弯曲现实，或者“按某个键”（GitHub Blog）。提交平台、截止时刻、评审口径、是否需要公开仓库等具体规则，本次材料未包含，须以活动页面为准，不能从本文推断。

需要先说明来源边界：本次抓取到的网页正文片段实际是另一篇文章的内容，并未包含该公告正文。因此下面关于“怎么取舍”的部分属于工程建议与示例，不是官方要求。

把四个提示翻译成机制，而不是美术#

主题在 Jam 里最常见的浪费，是把它做成一层皮肤：加个切换键，画面变色，玩法不变。评审和玩家都能看出来。更稳的做法是先把提示落到一个可测试的机制上：

• 换挡：适合连续参数。速度、重力、时间步长共用同一套更新循环，切换只改参数表。
• 切换视角：成本最高的一项，因为要同时处理相机、输入映射和可见性剔除。若只有一个月，建议限定为两个固定机位。
• 弯曲现实：本质是坐标变换或规则表替换。先确认引擎是否支持在运行时替换碰撞层，否则容易变成纯视觉。
• 按某个键：实现成本最低，也最容易变成装饰。要让它成立，切换前后必须产生玩家必须应对的差异，而不只是表现差异。

一个月的取舍顺序#

以下节奏是建议，不是活动安排：第一周做出可玩的垂直切片（vertical slice，指打通完整流程的一小段），第二、三周补内容与打磨，最后几天只做构建、页面素材与提交。取舍的原则是先砍掉“失败时无法降级”的模块：

• 多人联机、账号系统、云存档——联机调试的排错成本不可控。
• 程序化无限内容——难以判断何时算“够了”。
• 自研引擎或自研物理——除非它本身就是参赛作品。

反过来，值得优先投入的是启动时间、输入响应和退出保存这类“看起来不酷但会直接影响体验”的部分。

把切换做成一个显式抽象#

如果 SHIFT 是核心机制，就别让切换逻辑散落在各处 if 里。下面是一个最小骨架，未执行，仅作结构示意，语言为 TypeScript：

// 未执行的示例：仅示意结构，未在项目中运行
interface ShiftRule {
  enter(): void;
  exit(): void;
  update(dt: number): void; // 两种模式共用同一调用点
}

class ShiftController {
  private current: ShiftRule;
  private other: ShiftRule;

  constructor(a: ShiftRule, b: ShiftRule) {
    this.current = a;
    this.other = b;
    this.current.enter();
  }

  toggle(): void {
    this.current.exit();
    [this.current, this.other] = [this.other, this.current];
    this.current.enter();
  }

  update(dt: number): void {
    this.current.update(dt);
  }
}

好处是切换点只有一个，便于加限制条件（冷却、消耗、不可逆）和录制回放。代价是多一层间接调用，原型阶段通常可以忽略。

提交前核查#

表格中的具体口径均待核实，本文不提供数值或日期。

结论#

SHIFT 这个命题的技术难点不在实现切换，而在让切换产生玩家必须回应的后果。一个月的窗口里，先冻结范围、砍掉不可降级的模块，再把切换收敛到一个显式的状态入口，比增加内容更能提高完成度。活动细则请回到公告原文核对。