Prepare a game pitch that makes the next decision easier

Know what you are asking the meeting to do

A pitch meeting rarely resolves everything. Its immediate purpose might be to secure a longer evaluation, obtain feedback on fit, or reach the people who can discuss funding. Define that next step before building the deck. A presentation for a short introductory call needs different detail from a production review with a publisher already playing the build.

Research the recipient's actual portfolio, platforms, audience, and submission process. Explain why this game fits their work using specific examples, without claiming that similarity guarantees demand. A publisher seeking console action games may not be the right partner for an experimental browser tool. Microsoft's pitch guidance also makes clear that particular funding opportunities have their own eligibility and submission requirements; a convincing deck does not replace those steps.

Lead with the experience someone can picture

Describe the player, the repeated activity, and the interesting decision in plain language. 'A cooperative salvage game where every piece of recovered machinery changes the route home' communicates more than a stack of genre labels. Show the game promptly. A short, readable sequence of actual play should establish the action before you explain the larger world.

Use comparisons to orient the reader, then explain the difference. If you refer to two familiar games, name which qualities you mean: session structure, camera, social dynamic, or combat rhythm. Avoid implying that combining popular names establishes a market. A useful test is to remove every adjective from the opening slide. The remaining nouns and verbs should still explain what the player does and why choices matter.

Build a deck with a clear chain of evidence

The deck should connect promise to evidence and evidence to the production request. It can remain short while an appendix holds supporting detail. Treat the following order as a rehearsal aid, not a fixed slide-count rule. Move the demonstration earlier if the game's appeal is difficult to describe without seeing it.

• Game and player promise: one understandable experience, with a representative image.
• Core play: decisions, feedback, session structure, and a concise gameplay demonstration.
• Audience and positioning: relevant comparisons, differences, and evidence you actually possess.
• Current state: what is playable, what is representative, and what remains provisional.
• Team and production: relevant work, responsibilities, missing capabilities, and dependencies.
• Plan and request: milestones, budget assumptions, amount or support sought, and the next step.

Let the demo answer the riskiest question

A pitch demo is not necessarily a tiny version of the entire finished game. Choose a slice that demonstrates its strongest repeatable experience and addresses a genuine concern. For a movement game, that might mean a readable route with several expressive solutions. For a strategy game, it might be a short scenario in which the central tradeoff becomes visible without a lengthy tutorial.

State what the demo represents. A polished environment does not prove that your team can produce twenty equally polished environments at the proposed rate. Explain which assets are final, temporary, purchased, or bespoke, and which systems are functional. Do not quietly substitute a rendered sequence for gameplay. Capture an offline video as a backup, test the build on another machine, and prepare a reset point that survives a failed demonstration.

Show the production arithmetic

Build a budget from named work and time, rather than choosing an attractive round number. Separate development labor, external art or audio, equipment, software, testing, localization, porting, certification work, and marketing assumptions. Identify what the publisher is expected to provide. Include overhead and contingency explicitly so neither disappears inside an unexplained total.

A simple illustrative calculation is people multiplied by months multiplied by a realistic fully loaded monthly cost, plus external costs and contingency. This is a planning structure, not a claim that every worker has the same rate. A cash-flow schedule matters as much as the total: a milestone payment arriving after payroll is due leaves a real gap. Distinguish funding already secured from applications, conversations, and hoped-for revenue.

Milestone: representative playable slice.
Deliverables: one complete scenario, controller support, settings, save/load, and target-hardware performance report.
Acceptance evidence: downloadable build plus a short walkthrough of the stated criteria.
Dependencies: contractor animation delivery and access to target hardware.
Main uncertainty: encounter content takes longer than estimated.
Response: test the content pipeline before committing to the full level count.

Use market evidence without turning guesses into facts

Document the source, date, and context of every audience number. Separate wishlists, mailing-list signups, demo downloads, active testers, survey responses, and purchases; they answer different questions. A small set of highly engaged testers can teach you about usability, but it cannot establish a reliable sales forecast. Avoid presenting an assumed conversion rate as a measured result.

For comparison games, explain why each is relevant and acknowledge the differences in budget, release timing, platform, and existing audience. Public visibility does not reveal every commercial detail. Use a range of scenarios for your own forecast, with assumptions someone can inspect. If you have little market evidence yet, say which experiment will produce it and what decision the result would change. Clear uncertainty is more useful than confident arithmetic built from unknown inputs.

Rehearse the questions you would rather avoid

Expect questions about scope, team availability, ownership of assets, technical dependencies, platform access, multiplayer infrastructure, and what happens if a key person leaves. Prepare factual answers with an owner for anything unresolved. 'We have not measured that yet; this is our test plan' is stronger than inventing a number under pressure.

Rehearse to the meeting's actual duration, leaving time for discussion. Have one person present while another watches the clock and records follow-up questions. Practice without the internet and on the display setup you expect to use. Remove text that requires the audience to read while you explain something else. Keep detailed spreadsheets and production notes ready, but do not make every attendee study them before understanding the game.

Finish with a usable next step

End with the specific support you are seeking, your timing, and the action you hope follows. Afterward, send a concise recap, the agreed materials, build instructions, known issues, and an accessible point of contact. Date the deck and build so an older version is not mistaken for the current plan. Keep distribution and access arrangements deliberate when sharing unreleased work.

Record which questions changed your understanding of the project. A rejection may reflect portfolio fit, timing, budget, or evidence gaps rather than a universal judgment on the game. Review patterns across conversations before rewriting the entire design. When a discussion reaches commercial terms, get qualified advice suited to the proposed agreement; the preparation here is about presenting and evaluating a project, not interpreting a publishing contract.