Cut the Trailer Before You Film It: A Shot List for Your Game's First 75 Seconds

Most first trailers from small teams open the same way: a studio logo, a slow camera pan across an empty landscape, a title card, and then — about eighteen seconds in — the first thing a player can actually do. By then the viewer has already decided, and the decision was made in silence, because the video was playing muted in a browser tab.

A trailer is not a victory lap you film after the game is done. It is a deliverable with a structure, a shot list and a capture plan, and the cheapest time to design it is before anyone opens an editor. Here is a workflow that fits a team of one to five people.

Decide the shape before the footage

Pick a length first, because length dictates how many ideas you are allowed to have. A good default for an announcement or Steam page trailer is 70–80 seconds. That is long enough to show three or four distinct systems and short enough that you never need a "slow section" to pad it.

At an average shot length of 1.2–2.5 seconds, 75 seconds is roughly 20–28 shots. Write that number down. It is a budget, and like any budget it should hurt a little.

Here is a beat sheet that works for most genres:

Time	Beat	What it does
0:00–0:05	The hook	One shot of the single weirdest, clearest thing in your game
0:05–0:20	The verb	The player's core action, three times, in three contexts
0:20–0:40	The variety	Second and third systems: building, dialogue, bosses, co-op
0:40–0:60	The escalation	Bigger stakes, faster cuts, the stuff from late-game
0:60–0:70	The peak	Your best single moment, held two beats longer than the rest
0:70–0:75	The card	Title, platforms, "Wishlist now" or a date

Two rules make this work. The logo goes at the end, not the start. And the first thing on screen is gameplay, not a camera move across scenery — a pan says "we have an environment artist," which is not what anyone is deciding.

Write the shot list as a document

Before capture, the trailer should exist as a table with one row per shot. Four columns are enough:

• Shot — a number you can say out loud ("shot 14 is broken")
• Description — "player parries the lantern-keeper, lantern shatters, room goes dark"
• Needs — the build, the level, the save state, the enemy, the weather
• Status — not captured / captured / picked / cut

The Needs column is the one that saves the week. A shot that requires a late-game weapon in an early-game area, at night, with two enemies alive is not a recording session — it is a small engineering task, and you want to discover that while you are writing, not while a capture build is running.

This is a natural fit for a task board: one card per shot, grouped by the level or save state it needs, so you capture everything that shares a setup in one sitting. A trailer shot list and a sprint board are the same artifact wearing different clothes. If you keep reference clips of trailers you admire, a mood board next to the shot list is more useful than a folder of links nobody opens — note why a reference is there ("cut lands on the drum hit, not the impact") rather than just pinning it.

Capture rules that save the edit

Most trailer pain is capture pain. A few rules remove almost all of it:

1. Pin the build. Capture from one tagged build, and write the build ID next to every clip. If you have to re-shoot one shot in three weeks, you need that exact version — later builds will have different UI, different balance, different lighting. Build tracking exists for bug reports, but trailer footage is the other reason to care.
2. Record long. Start recording five seconds before the action and stop five seconds after. You will want the handles for speed ramps and dissolves.
3. Turn off the HUD, then decide. Capture a clean pass and a HUD pass of the same action where you can. Health bars read as clutter at 1080p on a phone, but an ability cooldown can be the clearest way to show a mechanic.
4. Capture at your target frame rate or above. Film at 60 fps and edit on a 60 fps timeline; it gives you half-speed slow motion without resampling, and fast action survives compression better.
5. No debug overlays, no placeholder text, no programmer art in frame. Check the corners of every clip. The most common trailer bug is a leftover FPS counter.
6. One hand on the game, one eye on the frame. Play shots badly on purpose if it looks better: the trailer is not a skill demonstration, and a deliberate near-miss reads clearer than a flawless clear.

The muted problem

Assume no audio. Steam starts the first video on your store page automatically with sound off, and most social feeds do the same. A trailer that only makes sense with the music is a trailer that only works for the people who already clicked.

So: every important idea needs to be legible as an image. If your game's pitch is "a detective game where lying has a cost," the lie has to be visible — a face changing, a relationship meter dropping, a door that no longer opens. Then put two to four short text cards in the cut, three to six words each, on screen long enough to read twice ("Every lie closes a door"). Text cards are not a failure of craft; they are the subtitles of the muted web.

Then cut the whole thing to music anyway, for the people who do unmute. Place your cuts on the beat and the big reveal on the downbeat — a cut that lands 100 ms off the rhythm reads as cheap even to people who could not tell you why.

Versions you actually need

One master is not enough, and five is too many. Export these:

• 16:9 master, 1080p — the Steam page, YouTube, press
• A 15-second cutdown — the hook, the verb, the card; for social posts and ads
• A 6-second loop, no text, no audio — for a store page background or an embedded preview
• A vertical 9:16 version of the 15-second cut — reframed, not letterboxed; recompose the shots that break

Keep the project file and a folder of named source clips (shot14_parry_lantern_build0912.mp4). The second trailer is always built from the first one's leftovers.

Pre-export checklist

• First frame is gameplay, and it reads at thumbnail size
• Logo and title card are at the end
• No debug text, placeholder assets or watermarks in any frame
• Every text card is readable in under two seconds
• The core verb appears within the first ten seconds
• Nothing shown is a feature you might cut
• Audio peaks are checked at a normal listening level, not at 100%
• A call to action is on screen for at least three seconds
• Watched once muted, on a phone, by someone who has never seen the game

That last line is the whole test. Hand the file to someone outside the team, say nothing, and afterwards ask two questions: what do you do in this game, and what was the weirdest thing you saw? If they can answer the first, the trailer works. If they can answer the second, it will be remembered.

Treat it like a milestone, not a weekend

A trailer takes longer than anyone plans for, because it is three jobs stacked up: a design decision about what the game is, a production task with build dependencies, and an edit. Put it on the timeline with a real date and real predecessors — the level it needs greyboxed, the UI it shows finished, the build tagged — and schedule it to land three to four weeks before the moment you need it. Festivals, publisher calls and Steam page launches all want the file earlier than you think, and the version you cut in a panic the night before is the version that will represent your game for the next two years.