game-jam

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Game Jam

Game Jam

Turn a theme and a fixed deadline into a finished, submitted game. This is a planning and scope-control playbook, not engine code: the win condition is something submitted and playable, not the game you imagined.
将主题和固定截止日期转化为一款可提交的成品游戏。这是一份规划与范围控制指南,而非引擎代码:成功的标准是提交一款可玩的作品,而非你想象中的完美游戏

When to use

适用场景

  • Use when entering a timed jam (Ludum Dare, GMTK Jam, Global Game Jam, a weekend jam), scoping a 48-hour build, or deciding what to cut to hit a deadline.
  • Use when the user asks "what can I actually build in a weekend" or "how do I submit to this jam".
When not to use: building the core loop in engine code (use the engine skill —
godot-2d-movement
,
phaser-core
, etc. — or a genre skill like
platformer
); throwaway experiments with no deadline (use
prototype-fast
); shipping a commercial release (use
steam-publish
/
itch-publish
).
  • 适用于参加限时开发Jam(Ludum Dare、GMTK Jam、Global Game Jam、周末开发Jam)、规划48小时开发任务,或决定为了赶截止日期需要削减哪些功能时。
  • 适用于用户询问“我周末实际能做出来什么”或“我该如何提交这个Jam的作品”时。
不适用场景: 编写引擎核心循环代码(请使用引擎技能——
godot-2d-movement
phaser-core
等——或类型技能如
platformer
);无截止日期的一次性实验(请使用
prototype-fast
);发布商业游戏(请使用
steam-publish
/
itch-publish
)。

Core workflow

核心工作流

  1. Read the rules before the theme drops. Confirm the jam's length, theme reveal time, submission deadline (with timezone), whether teams/pre-made assets/engines are allowed, and whether ratings require you to rate other entries. Missing one of these disqualifies an otherwise-finished game.
  2. Prep the boring parts in advance (allowed by most jams): empty project that builds and exports, input + a title/end screen stub, an export pipeline you've run once, and a font/SFX source you're licensed to use. Day-one time is too precious to spend here.
  3. Theme → one sentence. Brainstorm 10 ideas in 15 minutes, then commit to one expressible as: "You [verb] to [goal] while [constraint]." If you can't say it in one sentence, it's too big.
  4. Scope to the clock, not the idea. Use the budget table below. Pick one core mechanic and one "hook". Everything else is a stretch goal.
  5. Build the vertical slice first. Get a 30-second playable loop (start → play → lose/win → restart) running early. A complete tiny loop beats a half-built big one.
  6. Reserve the last ~20% of the clock for shipping, not features. Export, test the build on a clean path, capture screenshots, write the page. Builds always break at hour 47.
  7. Submit early, update if time remains. Upload a working build well before the deadline; most jam pages let you swap the file until it closes. A submitted mediocre game scores; an unsubmitted great one does not.
  1. 在主题公布前先阅读规则。确认Jam的时长主题公布时间提交截止日期(含时区)、是否允许组队/使用预制资源/指定引擎,以及评分是否要求你为其他作品打分。遗漏其中任何一项都可能导致你的成品失去参赛资格。
  2. 提前准备好繁琐的基础工作(大多数Jam允许这么做):可构建并导出的空白项目、输入控件+标题/结束界面模板、已测试过一次的导出流程,以及你拥有使用许可的字体/音效素材。第一天的时间太过宝贵,不应浪费在这些事情上。
  3. 主题→一句话提炼。15分钟内头脑风暴10个想法,然后选定一个可以用以下句式表达的想法:“你需要[动作]来达成[目标],同时受到[限制]。” 如果无法用一句话说清,说明这个想法太大了。
  4. 根据时间而非想法确定范围。使用下方的预算表。选择一个核心机制和一个“亮点功能”。其他所有内容都属于延伸目标。
  5. 先构建垂直切片。尽早实现一个30秒的可玩循环(开始→游玩→失败/胜利→重启)。一个完整的小循环胜过半成品的大项目。
  6. 预留最后约20%的时间用于提交,而非开发功能。导出项目、在纯净环境中测试构建包、截图、撰写作品页面。构建包总会在第47小时出问题。
  7. 提前提交,有余裕再更新。在截止日期很早之前就上传可运行的构建包;大多数Jam页面允许你在截止前替换文件。提交的平庸作品能获得评分,未提交的优秀作品则毫无意义。

Patterns

实用模式

1. Scope budget by jam length (plan backwards from the deadline)

1. 根据Jam时长规划范围预算(从截止日期倒推)

text
              | 48-hour jam            | 72-hour jam           | 1-week jam
--------------|------------------------|-----------------------|------------------------
Core mechanic | 1, proven by hour 6    | 1-2                   | 2-3 interacting
Levels/content| 1 hand-made or gen'd   | 3-5                   | 8-12 + progression
Art           | placeholder/1 palette  | cohesive 1-artist set | themed set + UI
Audio         | 3-5 SFX + 1 loop       | SFX + 1-2 tracks      | adaptive music
SHIP BUFFER   | last 8-10 h            | last 12-16 h          | last full day
text
              | 48-hour jam            | 72-hour jam           | 1-week jam
--------------|------------------------|-----------------------|------------------------
Core mechanic | 1, proven by hour 6    | 1-2                   | 2-3 interacting
Levels/content| 1 hand-made or gen'd   | 3-5                   | 8-12 + progression
Art           | placeholder/1 palette  | cohesive 1-artist set | themed set + UI
Audio         | 3-5 SFX + 1 loop       | SFX + 1-2 tracks      | adaptive music
SHIP BUFFER   | last 8-10 h            | last 12-16 h          | last full day

2. The 48-hour timeline (concrete blocks)

2. 48小时 timeline(具体阶段)

text
H0-2    Ideate -> lock ONE-sentence concept -> name the core mechanic + win/lose.
H2-8    Core loop in code with primitives (boxes/circles). Make it playable, no art.
H8-12   Sleep. (Tired code is tomorrow's bug list.)
H12-24  Content: 1 level/encounter, tune difficulty, add the "hook" feature.
H24-30  Sleep + playtest with one other person; cut anything not landing.
H30-38  Art + audio pass. Juice: screenshake, hit-stop, tween, particles, SFX.
H38-44  Bug-fix freeze: no new features. Fix only crashes + soft-locks.
H44-48  EXPORT, test the build clean, screenshots, write page, SUBMIT (by ~H46).
text
H0-2    构思 -> 锁定单一一句话概念 -> 明确核心机制+胜负条件。
H2-8    用基础图形(方块/圆形)编写核心循环代码。实现可玩状态,无需美术。
H8-12   睡觉。(疲惫时写的代码会成为明天的bug清单。)
H12-24  内容制作:1个关卡/遭遇战,调整难度,添加“亮点”功能。
H24-30  睡觉 + 找他人玩测;砍掉不受欢迎的内容。
H30-38  美术+音效优化。添加细节:屏幕震动、击中停顿、补间动画、粒子特效、音效。
H38-44  冻结功能只修bug:不添加新功能。仅修复崩溃+软锁问题。
H44-48  导出,在纯净环境测试构建包,截图,撰写作品页面,提交(建议约第46小时完成)。

3. Feature triage — decide fast, decide out loud

3. 功能筛选——快速决策,明确取舍

text
For every feature ask, in order:
  1. Does the core loop work WITHOUT it?   -> if yes, it's a stretch goal, not MVP.
  2. Can a player tell it's missing?       -> if no, cut it.
  3. Is it < 30 min of work?               -> if no, defer past the ship buffer.
Default answer under deadline pressure is CUT. You can always add in a post-jam version.
text
对于每个功能需求,按以下顺序提问:
  1. 没有它核心循环还能正常运行吗?   -> 如果能,它是延伸目标,而非最小可行产品(MVP)。
  2. 玩家能察觉到它缺失吗?       -> 如果不能,砍掉它。
  3. 实现它需要不到30分钟吗?               -> 如果不是,推迟到提交缓冲期之后。
在截止日期压力下,默认答案是砍掉。你总能在Jam结束后再添加这些功能。

4. Pre-submission build check (run on a clean copy, not your dev folder)

4. 提交前构建包检查(在纯净副本上运行,而非你的开发文件夹)

text
[ ] Build runs from an extracted zip on a path with NO engine/IDE installed.
[ ] Controls are shown on-screen or on the page (jurors won't read your mind).
[ ] No dev console errors; no soft-lock; restart works.
[ ] Web build (if any) is set to the platform's playable-in-browser mode.
[ ] Page has: 1-line pitch, controls, screenshots, credits + asset licenses.
[ ] File uploaded and the submission is actually attached to the JAM, not just the page.
text
[ ] 构建包在未安装引擎/IDE的路径下,解压后可正常运行。
[ ] 控件说明显示在屏幕上或作品页面中(评审不会凭空猜测)。
[ ] 无开发控制台错误;无软锁;重启功能正常。
[ ] Web构建包(如有)设置为平台支持的浏览器可玩模式。
[ ] 作品页面包含:一句话介绍、操作说明、截图、 credits + 素材许可信息。
[ ] 文件已上传,且提交内容确实关联到Jam,而非仅上传到作品页面。

Pitfalls

常见陷阱

  • Scope creep is the #1 jam killer. If the core loop isn't playable by the first third of the clock, cut features now, not later.
  • No ship buffer. Exporting, zipping, and writing the page reliably takes 1-3 hours and always surfaces a build bug. Treat the deadline as ~2 hours earlier than it is.
  • Submitting to the page but not the jam. On itch.io a jam entry is a separate submission linked from the jam page — uploading the game alone does not enter it.
  • Untested export. "Works in the editor" is not "works in the build." Test the exported artifact on a clean path; missing assets and wrong working directories are classic.
  • Unlicensed assets. Music/fonts/sprites pulled from the web can violate jam rules and break later distribution. Use assets you're licensed for and list them in the credits.
  • Polishing before the loop is fun. Juice multiplies fun; it can't create it. Get the loop right with placeholders first.
  • 范围蔓延是Jam的头号杀手。如果核心循环在Jam前三分之一时间内还无法运行,立刻削减功能,不要拖延。
  • 没有提交缓冲时间。导出、压缩和撰写作品页面通常需要1-3小时,而且总会暴露出构建包的bug。把截止日期当成比实际时间早2小时来对待。
  • 仅上传到作品页面而非Jam提交入口。在itch.io上,Jam参赛作品是从Jam页面跳转的独立提交项——仅上传游戏并不会完成参赛报名。
  • 未测试导出包。“编辑器中能运行”不等于“构建包能运行”。在纯净环境中测试导出的成品;缺失素材和工作目录错误是典型问题。
  • 使用无许可素材。从网上随意获取的音乐/字体/精灵可能违反Jam规则,还会影响后续分发。使用你拥有许可的素材,并在credits中列出。
  • 核心循环无趣就开始打磨细节。细节能放大乐趣,但无法创造乐趣。先用占位符实现有趣的核心循环,再进行打磨。

References

参考资料

  • For the throwaway-vs-keep prototyping mindset and greyboxing technique, read the
    prototype-fast
    skill.
  • For the actual upload mechanics (project page, channels,
    butler push
    ), read
    itch-publish
    .
  • 关于“取舍式原型”思维和灰盒技术,请阅读
    prototype-fast
    技能文档。
  • 关于实际上传机制(项目页面、渠道、
    butler push
    ),请阅读
    itch-publish
    技能文档。

Related skills

相关技能

  • prototype-fast
    — validate a mechanic quickly before committing jam hours to it.
  • itch-publish
    — create the page and upload the build (most jams are hosted on itch.io).
  • Engine cores (
    phaser-core
    ,
    love2d-core
    ,
    godot-gdscript
    , …) and genre skills (
    platformer
    ,
    roguelike
    , …) — build the actual loop the jam scopes around.
  • prototype-fast
    —— 在投入Jam时间前快速验证机制。
  • itch-publish
    —— 创建作品页面并上传构建包(大多数Jam都在itch.io上举办)。
  • 引擎核心技能(
    phaser-core
    love2d-core
    godot-gdscript
    等)和类型技能(
    platformer
    roguelike
    等)—— 构建Jam规划的核心循环。