#playtesting

A useful board-game starter pack should include one engine for formalizing turn logic, one prototype platform, one rules-teaching channel, and one set of component-layout references. That combination helps a designer move from notebook enthusiasm to a game that can survive contact with other humans.

The kinds of materials worth saving in this space:
- rules examples that show clarity without flattening the game
- prototype references for decks, tokens, and modular boards
- playtest logs that connect feedback to actual design changes

Read:
- boardgame.io: boardgame.io/
A smart reference when readers want to formalize turn structure and game state clearly.
- Tabletop Simulator custom deck guide: kb.tabletopsimulator.com/custom-content/custo...
Practical documentation for moving prototype cards and components into a usable test table.
- Tabletop Simulator video tutorials: kb.tabletopsimulator.com/getting-started/vide...
A good bridge for readers who learn prototype workflows better through motion than prose.

Documents and downloadable guides:
- boardgame.io documentation: boardgame.io/documentation/
Worth saving once a designer wants to model phases, moves, and turn order explicitly.
- Tabletop Simulator custom deck reference: kb.tabletopsimulator.com/custom-content/custo...
A practical build note for anyone turning printable components into a shared playtest table.

Watch:
- Watch It Played video archive: youtube.com/@WatchItPlayed/videos
A durable library for seeing how rules explanations land when clarity actually matters.

Build or inspect:
- boardgame.io source: github.com/boardgameio/boardgame.io
A readable open-source engine for state management, phases, turns, and multiplayer logic.

Image references:
- Tabletop Simulator custom deck examples: kb.tabletopsimulator.com/custom-content/custo...
Useful component-sheet visuals for cards, tokens, and print-and-play layout ideas.

A common mistake is polishing components before the decision space is stable. Another is collecting opinions after a playtest without preserving the exact moment where a player hesitated, misunderstood, or disengaged, which is the part the next prototype actually needs.

Common traps to watch:
- making component art feel finished before the decision space is stable
- collecting impressions without saving the moment the confusion happened
- rewriting whole systems when a rules explanation problem was the real bottleneck

References that help correct the drift:
- Tabletop Simulator custom deck guide: kb.tabletopsimulator.com/custom-content/custo...
Practical documentation for moving prototype cards and components into a usable test table.
- Tabletop Simulator custom deck examples: kb.tabletopsimulator.com/custom-content/custo...
Useful component-sheet visuals for cards, tokens, and print-and-play layout ideas.

This folio post is meant to be saved and revised. Add examples from your own work whenever one of these mistakes keeps resurfacing.

A dependable board-game workflow begins with a short rules explanation, a prototype that can survive being misunderstood, and a playtest log that records where the table drifted or stalled. You do not need art first; you need a version that teaches you what players are actually doing.

A sequence I would actually hand to a teammate:
1. Write the shortest rules explanation you can, then build the roughest prototype that can test it.
2. Run playtests that record hesitation, confusion, and timing, not just general reactions after the session.
3. Revise the prototype, rules, and component layout together so the next table teaches you something specific.

Useful operating references:
- Tabletop Simulator custom deck guide: kb.tabletopsimulator.com/custom-content/custo...
Practical documentation for moving prototype cards and components into a usable test table.
- boardgame.io source: github.com/boardgameio/boardgame.io
A readable open-source engine for state management, phases, turns, and multiplayer logic.

If your team has a better workflow, post it with the context around team size, constraints, and exactly where the process tends to break.

Before I scale an indie game strategy, I want to see a stable core loop, consistent playtest notes, and a launch plan that exists before the final month. If those are missing, more content or more code usually just hides the uncertainty.

Three evaluation axes to compare:
- scope discipline
- quality of the playtest learning loop
- readiness of the launch pipeline

Review materials:
- Itch.io creator getting started guide: itch.io/docs/creators/getting-started
A useful counterweight for smaller launches, demos, and community-first releases.
- Steamworks documentation: partner.steamgames.com/doc/home
One of the few places where platform realities and release logistics are spelled out clearly.
- Godot engine source: github.com/godotengine/godot
The open source engine itself, useful even if you only read around the edges.

Save the strongest examples, scorecards, and decision memos in this folio so future teammates can see what good evaluation looked like at the time.

The real debates are about when to cut polish versus features, how early public marketing should start, and whether wishlists, demos, or creator coverage deserve the most attention. The right answer depends on genre, runway, and how readable the game is in ten seconds.

Three questions worth debating:
- when solo developers should cut features versus cut polish
- how early a game needs public marketing to matter
- whether wishlists, demos, or creator coverage create the strongest launch leverage

Background reading before you take a strong stance:
- Godot documentation: docs.godotengine.org/en/stable/
A strong open engine reference with a good balance of basics and production detail.
- Steamworks store documentation: partner.steamgames.com/doc/store
Essential reading for anyone who wants launch prep to be more than vibes.
- Godot official video archive: youtube.com/@GodotEngineOfficial/videos
Engine walkthroughs and announcements that are genuinely helpful for small teams.

When you respond, include the environment you are optimizing for. Advice changes a lot across stage, regulation, team size, and user expectations.

The classic indie mistake is adding features every time feedback arrives instead of asking what actually improves the loop. Another is treating marketing and community updates as work that starts after the game is already exhausted.

Common traps to watch:
- expanding scope every time feedback arrives
- running playtests without a consistent note format
- treating launch marketing as something to start after the build is finished

References that help correct the drift:
- Steamworks store documentation: partner.steamgames.com/doc/store
Essential reading for anyone who wants launch prep to be more than vibes.
- Steamworks release docs: partner.steamgames.com/doc/home
Useful screenshots and checklists for release prep, store setup, and update flow.

This folio post is meant to be saved and revised. Add examples from your own work whenever one of these mistakes keeps resurfacing.

The numbers I want are core-loop retention in playtests, scope stability across milestones, and conversion on launch-facing assets like demos or store pages. Those reveal whether the game is getting clearer or just getting larger.

Three metrics worth pressure-testing:
- playtest retention through the core loop
- scope stability across milestones
- conversion performance for launch and store assets

Source material behind the scorecard:
- Godot documentation: docs.godotengine.org/en/stable/
A strong open engine reference with a good balance of basics and production detail.
- Itch.io creator getting started guide: itch.io/docs/creators/getting-started
A useful counterweight for smaller launches, demos, and community-first releases.

If your team has a sharper dashboard, share the metric definitions and the decisions they actually change. That is what makes numbers reusable.

Godot's docs and demo projects are useful because they make shipping feel concrete. Steamworks documentation matters because launch quality is partly a store page and distribution problem, not just a code problem.

The stack categories worth comparing here:
- production planning and milestone tracking
- playtest note and bug review systems
- store-page and launch asset workflows

Open materials worth opening side by side:
- Godot engine source: github.com/godotengine/godot
The open source engine itself, useful even if you only read around the edges.
- Godot demo projects: github.com/godotengine/godot-demo-projects
One of the best public libraries for learning from small, runnable examples.
- Godot documentation: docs.godotengine.org/en/stable/
A strong open engine reference with a good balance of basics and production detail.

Working documents and guides:
- Steamworks documentation: partner.steamgames.com/doc/home
One of the few places where platform realities and release logistics are spelled out clearly.
- itch.io creator docs: itch.io/docs/creators/faq
A good counterpart for teams releasing small games outside the big-platform default.

Milestone and playtest log:

milestone:
  goal: "prove the first 10 minutes"
  must_have:
    - core movement
    - one repeatable reward loop
    - tutorialized fail state
  playtest_notes:
    friction_points: []
    moments_of_delight: []
    cut_list_before_next_build: []