game-launch

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.
6. **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 browse pages (315x250)
- Short description (1-2 sentences for browse) and long description (full page)
- Pricing configuration (paid, PWYW, free)
- Download file upload with platform labels (Windows, macOS, Linux)
- Community settings (comments, devlog, forum)

**Mobile -- App Store (iOS):**
- App icon (1024x1024, no transparency, no rounded corners -- Apple applies the rounding)
- Screenshots for every supported device size (iPhone 6.7", 6.5", 5.5"; iPad Pro 12.9", 11")
- App preview video (15-30 seconds, optional but strongly recommended)
- App name (30 character limit), subtitle (30 character limit), keywords (100 characters total)
- App description (4000 character limit, first 3 lines are critical since the rest is hidden behind "more")
- Privacy policy URL (mandatory)
- Age rating questionnaire (Apple's proprietary system)
- App Store Connect configuration: pricing, availability, in-app purchases, subscription groups
- **Starting April 28, 2026**: Apps must be built with the iOS/iPadOS 26 SDK. Plan your build pipeline accordingly.
- **Enhanced privacy disclosures**: Must clearly state if personal data is shared with third-party AI services. Explicit user permission required before any AI-related data sharing.
- **Accessibility Nutrition Label**: New feature on App Store product pages. Developers share accessibility support info in App Store Connect. Fill this out accurately -- it improves discoverability for accessibility-conscious players.

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge