Don't Panic: Game Platform Publishing

Game platform publishing is the slightly bureaucratic art of turning a game project into a product a platform can sell, distribute, review, and support. The game is not launched because a file reached a server. The file has merely arrived at the door, possibly wearing a hat and asking whether anybody remembered the pricing.

The useful shape is four connected packages. The business package carries agreements, identity, payout details, and account roles. The commercial package carries the store page, media, prices, regions, ratings, and offers. The technical package carries an identified build, product configuration, and test evidence. The release package carries submission, review feedback, a date, and an operator. Keeping them separate prevents the build engineer from attempting legal work with a compiler, which remains an unreliable legal instrument.

The part that surprises people is that the store page and the build are one promise. A claim about a supported system or selected feature is not decorative copy. It describes behavior that the release candidate must show. A release candidate is the named, near-final build plus its matching configuration. Once it has that name, feedback has somewhere concrete to land instead of wandering around the project looking for a responsible adult.

Each platform has its own portal, requirements, review stages, and release controls. Steamworks, the Epic Games Store, PlayStation, and Xbox share a broad pattern, but they do not share interchangeable rules. A platform matrix keeps the differences visible: account owner, business gate, store package, build identifier, test evidence, review state, and release owner. An unknown cell is a blocker, not an invitation to borrow a rule from another platform.

Start with the Intro when the four packages need more explanation. The Slides show the path from onboarding to operations and make the handoffs visible. The Cheatsheet is the compact release-room reference. The Practice Reference turns that into a platform matrix and a promise-to-build review. Then use the Exercise to assemble a dossier for one fictional release candidate, where configuration, feedback, and decision agree. The goal is knowing exactly what product is about to become live, and who can prove it.