Screenshots, store art and listing copy in one pass: the marketing kit

A finished game is not a finished store page. Between the build and the button that says Publish there is a second project: screenshots at the exact sizes each store demands, an icon, a feature graphic, capsules for Steam in five shapes, and a page of copy that has to fit inside limits nobody remembers. The studio's Publish pane now does that project too. Tick the stores you want, press Generate, and the agent plays your game, takes real screenshots, composes the artwork and writes the listings. You get a folder you can browse in the studio and download as one zip.

This post covers what a marketing kit is, what the agent actually does to make one, three kits it produced on its first night for three very different games, and the list of things it refuses to fake.

What is a marketing kit?

A marketing kit is everything a store's submission form asks for, except the build itself. For the mobile stores that means an icon, a feature graphic, framed phone and tablet screenshots and two listings (Google Play and the App Store have different fields and different character limits). For itch.io it means a cover, a banner, a page background, a set of screenshots, the page copy and the exact settings for the edit form. For Steam it means the header, small, main and vertical capsules, the library capsule, hero and logo, at least five raw gameplay screenshots, the store text, and an editing brief for the trailer. The kit lays these out in one folder per store, with a README that says which file goes into which field and what you still have to supply yourself.

The kit is generated by the same agent that built the game, in the game's own workspace, on the same cloud machine. It has the project, the art, the fonts and a browser. What it does not have is permission to change anything: the game is read-only for the whole turn, and the only place it can write is the kit folder.

What the agent does

1. Learns the game. It reads the project, the scripts and the description, and writes itself a fact sheet: genre, mechanics, controls, modes, progression, whether there is touch or gamepad support, whether it is multiplayer. Every sentence of copy has to trace back to that sheet.
2. Plays it. It builds the web export if the current one is stale, then opens it in a headless browser at every size the stores care about: 1920x1080 for desktop, 1080x1920 as a phone, 2064x2752 as an iPad. On the phone sizes it emulates a touchscreen, so a game with on-screen controls shows them and a responsive layout switches to its portrait form. It drives the game with scripted input (press start, hold right for three seconds, tap here, screenshot) and reads every frame it captured as an image, throwing away loading screens, menus-only sets and anything with debug text.
3. Composes the artwork. Framed store screenshots with a headline and a subline, icons cut from the key art, feature graphics and capsules with the title set in the game's own fonts and palette, each at its exact pixel size, with no alpha channel where the store forbids one. It reads each composed image back before moving on.
4. Writes the copy. Name, subtitle, short and long descriptions, keywords, release notes, tags, category, the content rating answers, the data safety answers. It counts the characters and writes the count next to each field.
5. Checks its own work and writes the README. Every image is re-measured against the store's size table, the counts are recounted, the Steam screenshots are verified byte-identical to the raw captures they came from, and the README records it along with the honest caveats: this game is landscape-only so the portrait shots are framed; Steam still needs a trailer; Play needs a privacy policy URL from you.

The specs it works from are a skill document, not memory: the sizes, limits and rules for each store are written down and read at the start of every kit, so when a store changes its numbers we change one file.

Three games, three kits

Everything below is straight out of the kit folders the studio produced, unedited. The three games are an idle game, a kart racer and a merge puzzle, which between them cover most of the ways a store page can go wrong.

A pixel-art idle game for the phone stores

Nine Heavens Ascent is an 8-bit cultivation idle game with a one-thumb portrait layout, which makes it the easy case: the phone captures are the game as it is. The kit's mobile folder holds eight captioned phone screenshots in upload order, the same eight moments at the App Store's 6.9-inch and iPad sizes and at Play's two tablet sizes, the 512 and 1024 icons, an adaptive icon set for Android, a 1024x500 feature graphic and one listing file with the Play and App Store fields side by side, each with its character count. One hundred and twenty files, ten minutes.

A 3D kart racer for Steam

Frostline GP is split-screen kart racing on a frozen lake, landscape only. Steam is the strictest of the four stores: capsules may show only the artwork and the name, screenshots must be the game in play with no captions or frames, and every asset has a fixed size the upload form rejects otherwise. The kit found the chrome logo the game already shipped with and used it everywhere: the header capsule at 920x430, the small capsule at 462x174 with the logo still readable when Steam shrinks it by half, the vertical capsule at 748x896, the library capsule, hero and transparent logo, and eight raw 1920x1080 screenshots from an actual race.

The mobile folder for the same game shows the honest version of a hard case. Frostline GP has no portrait layout, so the kit frames a landscape capture, with the on-screen steering and boost controls visible, on a phone-shaped canvas with the logo above it. Its README says the portrait browser test was rejected, and why: the layout crowded the steering label against the boost meter and never left the countdown. The alternative would have been a screenshot of a layout the game does not have.

A cozy merge puzzle with a real portrait layout

Potion Pile is a physics merge puzzle in a moonlit apothecary, built with touch controls and a layout that stacks into portrait on a phone. This is where the touchscreen emulation earns its place: the same build that shows a side-by-side cauldron and recipe card on a desktop rearranges itself into a tall phone screen when the browser reports a touchscreen, and the kit captures that layout, not a squeezed version of the desktop one. The phone screenshots come out of a real session, three brews bottled, a recipe ready, ingredients settling in the cauldron.

What it refuses to fake

• No invented screenshots. Every frame comes from the playable build in a browser. Concept art is never passed off as gameplay, and a layout the game does not have is never shown.
• No invented features. The copy says "gamepad support" only if the input map binds a gamepad, "touch controls" only if they exist, "online" only if the game has it. The Frostline GP kit goes as far as warning that the decorative ice pattern on lap one must not be captioned as damage.
• No review quotes, award badges, platform logos or prices baked into images. Stores reject them and readers distrust them.
• No overrun. Thirty characters for a Play title, eighty for its short description, one hundred for App Store keywords, three hundred for a Steam short description. Counted, recounted, and written beside each field.
• No silent gaps. A trailer, a privacy policy, a release keystore, a Team ID, measured system requirements: what the store still needs from you is listed in the README rather than left for the submission form to discover. The kits deliberately do not invent minimum PC specs.

The trailer

Every Steam kit ends with a file called trailer-plan.md: a 45-second beat list with timings, the exact inputs that produce each shot, the caption for every shot, the copy cards that go between sections, the closing splash, and which of the game's own music tracks to use where. It is written as instructions to an editor who has the project but none of the agent's context. A finished kit then gets a second button, Make trailer, and that editor is the agent again.

The footage is not a screen recording. The trailer stage copies the project to a scratch folder, adds an input script that plays the game frame by frame, and renders each shot with the engine's own movie-maker mode: every frame at a fixed 30 frames per second, with the game's real audio, however slow the machine is. Late-game shots are reached by playing. The Nine Heavens Ascent trailer needed a lightning trial at Mortal IX and a reincarnation at Nascent Soul, both of which the plan had marked as "still needs recording"; the agent got there through the normal economy and said so in the trailer's README, along with a check that the project's 106 source files were untouched.

The cut follows a fixed shape. It opens on gameplay, because Steam insists, with a large caption over it. Every gameplay shot carries a caption in the game's title font, faded in and out over a gradient band. Between every two or three shots there is a full-frame copy card, a headline and a line drawn from the kit's own listing copy, on blurred key art. It closes on a splash: the key art, the logo or title, the tagline, and the music resolving. The game's own tracks are mixed under the game's own sounds, ducked where the plan says so. Out come a 45-second 1920x1080 file for Steam, itch.io and YouTube, and when the game has a real portrait layout, a 15-to-30-second App Store preview at 886x1920 recorded in that layout, plus every card as a PNG and a README with the beat list and what could not be recorded.

How to run it

Open a deployed game, switch the right-hand pane to Publish, and scroll past the exports to Marketing kit. Tick Mobile, itch.io, Steam or any mix; add notes if there is something the copy should say or avoid, and pick the model if you want one other than the game's own. Press Generate. The kit runs in the background like a build turn, with the same live feed, and lands in the pane ten to forty minutes later as a browsable folder: image grids per store, listing files rendered in place, a download link per file and a Download zip button for the lot. Once a kit is done, Make trailer starts the video stage on top of it; the finished MP4 plays in the same browser and lands in the zip. Kits are kept per game, so you can generate a fresh one after a big change and compare.

Two rules. One kit runs per game at a time, and the game has to be deployed first, because the screenshots come from the playable build. The kit never modifies the game.

Where it hands off

The kit gets you to a filled-in store form, not through review. The export pipeline produces the builds the stores want (how exports work), and the guides cover the rest of each road: itch.io, which the studio can finish for you; Google Play; the App Store; and Steam. The kit is the part of those guides that used to say "now make eight screenshots and write four hundred words", done.