AlterLab GameForge -- Pre-Release Launch Pipeline

The distance between "done" and "launched" is longer than most teams expect. And the distance between "launched" and "sustained" is longer still. A game that is feature-complete, bug-free, and fun can still fail because the store page was not optimized, the press kit was missing, the age rating was not filed, or the day-one patch pipeline was not tested. Worse -- a game that launches perfectly can die in week two without a post-launch strategy.

Hades did not become a cultural phenomenon on launch day. It became one through 18 months of Early Access with a meticulously planned patch cadence. Stardew Valley did not stop at 1.0 -- ConcernedApe's free content updates built a community that still plays eight years later. This workflow covers both sides: the exhaustive pre-launch pipeline AND the post-launch operations that determine whether your game survives past the first week.

Purpose & Triggers

Invoke this workflow when:

• The game is entering the final milestone before release and a structured launch plan is needed
• A storefront submission deadline is approaching and the team needs to verify all requirements are met
• Marketing assets need to be prepared and coordinated across platforms
• Legal and compliance requirements (age ratings, privacy policies, licenses) need auditing
• The team needs a go/no-go framework for making the launch decision
• A soft launch or early access release is being planned (same process, adjusted scope)
• Post-launch support infrastructure needs to be established before launch day

Do NOT use this workflow when:

• The game is still in active development with significant features incomplete (finish building first)
• You are launching an internal playtest build (use game-playtest instead)
• The game is a game jam submission with no commercial intent (streamline to just build validation)

Critical Rules

1. Every phase is gated. Do not advance to the next phase until the current phase is signed off. Skipping a phase to save time is how launches implode. Vampire Survivors launched without a press kit and still succeeded -- but that was 2021 lightning in a bottle, not a replicable strategy.
2. Storefronts are not optional. A store page that is missing screenshots, has a vague description, or uses the wrong tags will kill discoverability. The store page IS the game's first impression. Treat it as a design deliverable, not a checkbox.
3. Legal compliance is not a suggestion. Missing an age rating or privacy policy can result in the game being pulled post-launch. This is a catastrophic outcome that is entirely preventable.
4. Plan for failure. The launch plan must include a rollback strategy. If the answer to "what if launch goes wrong?" is "panic," your launch plan is incomplete.
5. Day-one patches are expected, not shameful. Between going gold and launch day, new issues will be found. The question is not "will we need one?" but "how fast can we deploy one?"
6. Launch day is day one, not the finish line. Dead Cells shipped its 1.0 and then delivered 6 major content updates over 4 years. Hades had 18 months of Early Access patches before 1.0. Your post-launch strategy matters as much as your pre-launch checklist.
7. Reference docs/game-design-theory.md for player psychology considerations in storefront presentation and first-time user experience.

Workflow

Phase 1: Build Validation

This is the final technical gate. The game must be provably stable, performant, and complete before any launch activities begin.

Clean Build Verification:

• Perform a clean build from source control on a machine that has never built the project before. This catches missing dependencies, local-only files, hardcoded paths, and environment-specific configurations.
• Verify that the build process is documented and reproducible. A build that only one person on the team can create is a single point of failure.
• Confirm the build version string is correct and matches the intended release version.
• If the game has a launcher or auto-updater, verify it points to the correct update servers.

Automated Test Suite:

• All unit tests passing: zero failures, zero skipped (unless permanently excluded with documented reason).
• All integration tests passing: game systems interact correctly.
• All platform-specific tests passing: each target platform builds and runs without platform-specific failures.
• Smoke tests for critical paths: new game start, save/load cycle, all main menu options, final boss completion, credits roll.

Performance Validation:

• Frame rate meets target on minimum specification hardware. Test on actual min-spec hardware, not a developer workstation set to reduced settings.
• Load times are within budget. First load, level transitions, and respawn times should all be measured and logged.
• Memory usage stays within platform limits across a full play session. Run a 2+ hour continuous play session and track memory allocation. If memory grows monotonically, there is a leak.
• Disk space usage is within platform limits (particularly relevant for console and mobile).
• Network performance (if applicable): latency, bandwidth usage, reconnection handling.

Bug Triage:

• Zero P0 bugs (game-breaking: crashes, data loss, progression blockers).
• Zero P1 bugs (severe: major features broken, significant visual glitches, frequent soft locks).
• All P2 bugs (moderate) reviewed and either fixed or explicitly accepted as shippable with documented reasoning.
• P3 bugs (minor: cosmetic issues, edge cases) catalogued for day-one patch consideration.

Save/Load Integrity:

• Save files created on the release build load correctly.
• Save files from the most recent public build (if applicable, for early access) migrate correctly.
• Corrupted save file handling: the game recovers gracefully, does not crash, and informs the player.
• Cloud save synchronization works across devices (if applicable).

Extended Play Session:

• One team member plays the complete game start-to-finish on the release build. This catches issues that only manifest in long play sessions: memory leaks, cumulative state corruption, softlocks from unusual player choices.
• Record the full session and note any anomalies, even minor ones.

Phase 1 Gate: All automated tests pass. Zero P0/P1 bugs. Performance within budget on target hardware. Extended play session completed without critical issues.

Phase 2: Storefront Requirements

Each storefront has specific asset requirements. Missing or non-compliant assets will delay submission or cause rejection.

Steam:

• Header capsule image (920x430)
• Small capsule image (462x174)
• Main capsule image (1232x706)
• Vertical capsule image (748x896)
• Hero graphic (3840x1240) for top of store page
• Library capsule artwork (600x900)
• At least 5 screenshots (1280x720 minimum, 1920x1080 recommended). These should be curated moments that communicate the core experience -- not random gameplay captures.
• At least one gameplay trailer (60-90 seconds, embedded or YouTube link)
• Store description: hook paragraph, feature list, system requirements. Write this as marketing copy, not a design document. Lead with the emotional experience, not the feature list.
• Tag selection: choose tags that match your game accurately. Mis-tagging for visibility backfires when players expecting genre X find genre Y.
• System requirements (minimum and recommended): test these on actual hardware that matches the stated specs.
• Review/community settings: configure discussion boards, review visibility, and beta branch settings.
• Steamworks integration: achievements, cloud saves, trading cards (if applicable), Remote Play Together (if applicable).
• Coming Soon page should be live at least 2 weeks before launch for wishlist accumulation.

itch.io:

• Page banner image (630x500 recommended)
• At least 3 screenshots
• Cover image for