Summary of "Don’t Ship the Wrong Game: A Framework for Choosing What to Finish | René Habermann | GCF 2025"
“Don’t Ship the Wrong Game: A Framework for Choosing What to Finish” — René Habermann (GCF 2025)
Make commercially viable games sustainably as an indie studio by validating early and often. Use a repeatable framework of prototype → core-fancy → demo → release and decide at each validation point whether to continue, pivot, or kill the project.
Core thesis
- Validate early and often to make commercially viable games sustainably.
- Follow a repeatable pipeline: jam prototype → prototype refinement → core-fancy → demo → production → release.
- At each exposure/validation point, choose to continue, pivot, or kill the project — and adjust scope accordingly.
Case studies / examples
Dome Keeper
- Premise: you’re a miner/astronaut who digs for resources, returns them to a dome to buy upgrades, and defends the dome against monsters. Loop: mine → upgrade → defend.
- Origin and timeline:
- 3-day Ludum Dare jam prototype
- Strong jam feedback
- ~8 weeks of prototype refinement
- Demos and further exposure
- ~9 months production
- Successful release (~1.4M sales, ~90% positive rating, reached top sellers)
- Key lessons:
- Early demos led to a sudden YouTube pickup and a massive wishlist spike.
- Staying playable and exposed to players from day 3 was crucial.
PBK / PVK (current project referenced)
- Started from an older prototype.
- Refined into a “core-fancy” — roughly 30% of final features but polished enough to convey the experience.
- Early announcement itself validated demand, allowing the team to pace demos and production.
Framework & process (stages and timings)
- Typical pipeline:
- Game jam prototype (3 days)
- Prototype refinement (~8 weeks)
- Production (~9 months)
- Release & post-release
- Progressive exposure: open the build to more players over time (jam peers → itch → small demos → Steam demo/announcement → release).
- Treat each exposure as a decision point: continue / pivot / kill, and adjust scope to meet experience goals.
Three types of “wrong game” to avoid
- Undesired
- Symptoms: no market demand, low wishlists/followers, little positive validation.
- Cause: poor or no market validation.
- Response: kill or pivot early.
- Misaligned
- Symptoms: early interest exists but the shipped game doesn’t match player expectations.
- Causes: communication/marketing mismatch, closed testing groups, poor first-time UX.
- Response: define clear experience goals, test first-time players, align team and messaging.
- Overdeveloped
- Symptoms: good interest but production costs exceed likely returns.
- Causes: scope creep, excessive polish (often art), repeated reworks.
- Response: iterate by validation points, keep prototyping mentality, enforce flexible scope or hard deadlines, cut by experience goals.
Prototype guidelines and practical tips
- Speed > polish: ship simple, fast solutions to learn quickly.
- Clarify only what’s necessary early; avoid building generalized tech before requirements are known (e.g., don’t invest in full procedural systems until needed).
- Prefer “good enough” (80%) implementations and pragmatic shortcuts — many placeholders never get reworked.
- Play and playtest early and often — even harsh internet playtests are valuable.
- Retain the prototype’s spirit during production: flexible scope and fast iteration.
How to validate a prototype (holistic view)
- Use multiple validation sources — combine qualitative and quantitative signals; no single metric is definitive:
- Jam ratings and comments (e.g., Ludum Dare)
- Itch.io plays, ratings, and collections — use engagement ratios (plays → rating/collection)
- Steam wishlists/followers and SteamDB charts
- YouTube pickup: presence of videos and view performance relative to channel averages (viral videos often drive rapid wishlist growth)
- Press coverage (e.g., Rock Paper Shotgun)
- Expo floor testing and Discord/tester groups (watch for closed-group bias)
- Interpret player comments:
- “Type A” (polite praise): often low signal for real demand
- “Type B” (demanding, asking to expand or bring to Steam): strong signal of player investment
- Gauge emotional resonance early by discussing the idea before building (a la Chuck Palahniuk’s test).
Design discipline & team alignment
- Define experience goals (how the game should feel), not only feature lists; use them to prune scope.
- Build for players (respect feedback) while balancing the team’s vision.
- Explicitly test and optimize the first-time-user experience.
- Avoid overspending on art unless it materially affects commercial success.
Practical validation examples and metrics
- Release jam prototypes on itch.io and the jam site; measure plays, ratings, and collections.
- Track Steam wishlist spikes and correlate them with demos, trailers, or YouTube coverage.
- Use playtests (expos, Discord, friends) and interpret the data qualitatively — larger absolute attention (more players/reviews) typically beats small-sample positive ratings.
Final advice
- Kill or pivot projects that show no traction.
- Avoid huge, prolonged bets without external validation.
- Keep making prototypes (game jams, internal sprints) to discover resonant ideas and maintain creative momentum.
Gamers / sources / names mentioned
- René Habermann (speaker)
- Bipin Bits (studio)
- Dome Keeper (game) — originally “Dome Romantic” (jam name)
- PBK / PVK / PBKK (prototype / current game referenced)
- Lavender Fields (game jam project)
- Ludum Dare (game jam)
- itch.io
- Steam, Steam NextFest, SteamDB
- “Games Made in Germany” (Steam sale / event)
- YouTubers: Redformation (first pickup), Clammy Games (shout-out), Tristan (viral example)
- Rock Paper Shotgun (press)
- Fury (publisher mentioned)
- Chuck Palahniuk (author, referenced method)
Category
Gaming
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...