To learn how to pitch a game to a publisher, prepare a concise playable proof, a deck that explains the game and audience, a credible production plan, and a specific request tied to budget, schedule and rights. The publisher should be able to understand what players do, why the opportunity fits its portfolio, what has already been proven, what remains risky and what decision you want next. Tailor every submission to the publisher’s stated process.
How to pitch a game to a publisher as a decision package
A pitch is not only a presentation. It is the smallest set of evidence a publisher needs to decide whether to decline, request more information, play the build, start diligence or discuss terms. Different publishers evaluate different genres, stages, platforms and business models, so research fit before polishing slides.
The package has four connected parts:
- The game: a clear player promise and representative proof.
- The market case: a defined audience, positioning and release context.
- The production case: a team, budget and schedule that match the scope.
- The ask: the exact funding, publishing services and next step requested.
If one part contradicts another, the publisher must resolve the uncertainty. A small premium game pitched with a huge live-service plan, or a polished trailer backed by an undefined team and budget, weakens the entire package.
Write the one-sentence game promise first
Describe the player, action, distinctive system and desired experience in plain language. Avoid a chain of genre labels and comparisons that make the reader reconstruct the idea. A useful sentence creates a picture of play, not just a category.
Then support it with three short elements:
- The repeatable core loop and the decisions that make it interesting
- The feature or production choice that makes the game meaningfully distinct
- The intended audience and the reason this experience fits them
References can create a shared vocabulary, but name the relevant dimension. “Combat readability similar to X” is more precise than “X meets Y.” Do not imply affiliation, shared audience or likely sales from a comparison alone.
Build a playable proof that matches the claim
The right build depends on the decision. A mechanic prototype can prove feel or feasibility. A vertical slice can demonstrate how representative gameplay, art, audio, UI and performance work together. A content-rich alpha can show progression and production maturity. Label the build honestly.
Use prototype versus vertical slice criteria to choose the evidence. Do not spend months polishing a slice if the unresolved question is technical feasibility. Do not present a narrow mechanic test as evidence that the team can produce final content at scale.
Prepare the build for an evaluator who does not know the controls or internal workarounds. Include:
- A stable route to the representative experience
- Clear controls and a short context note
- Known issues that could affect evaluation
- Target hardware and setup instructions
- A backup video capture if access or hardware fails
- A build date and contact for technical questions
Design the video game pitch deck around questions
The deck should work without a spoken performance. Keep each section focused on a decision question and use footage, screenshots or diagrams only when they carry evidence. Publishers may state their own required format, as Devolver Digital does on its submission page, so those requirements take priority over any generic template.
| Pitch section | Question to answer | Evidence to include |
|---|---|---|
| Game overview | What is the player experience? | One-sentence promise, genre, camera, mode, target platforms |
| Core loop | What does the player repeatedly do and decide? | Short loop diagram and build footage |
| Distinctive value | Why will the intended audience notice this game? | Specific mechanic, structure, theme or production approach |
| Audience and positioning | Who is it for and what alternatives do they choose? | Comparable products by relevant dimension and sourced signals |
| Current state | What has the team proved? | Build status, tests, production benchmark and open risks |
| Scope and roadmap | What remains to reach release? | Milestones, content plan, platforms and dependencies |
| Team | Why can this group deliver this scope? | Named roles, relevant work and explicit gaps |
| Budget and ask | What support is requested and what will it fund? | Use of funds, schedule, runway and desired services |
A deck does not need to hide uncertainty. Name the major open question and the milestone that will resolve it. This makes risk discussable and shows that the plan can absorb learning.
Make a market case without inventing certainty
Define the audience through behavior and preference, not only age or platform. Explain what players seek, which communities already discuss the underlying genre or theme, and where the game differs from available choices. Distinguish evidence from assumption.
Comparable games can help frame price, scope, feature expectations and launch context. Select them by a stated reason such as loop, audience, visual approach or business model. Do not present another title’s public sales estimate as a forecast for your game. If market data has limitations, state them.
Show the intended commercial model, target platforms, broad release window and current community activity if it exists. Use exact, sourced metrics and dates. Do not buy low-quality followers or treat views as demand. A small group that repeatedly plays and gives useful feedback can be more informative than a large passive count.
Present a production plan that can be challenged
Publishers need to understand how the team moves from its current proof to release. Break the plan into milestone outcomes, not generic phases. Each milestone should end with a build, content sample or operational result that supports the next funding decision.
Show roles rather than a total headcount. The game development team structure should reveal current owners, planned hires, external dependencies and leadership capacity. If a crucial discipline is unfilled, explain when it is needed and how the budget covers it.
Present the budget by category and period. Include team burn, external work, software and hardware, localization, QA, porting, marketing responsibilities, contingency and taxes or fees where relevant to the entity. A game development budget template can keep assumptions visible without exposing every payroll detail in the first deck.
Connect cash to milestones and runway. State what funding has already been secured, what has been spent and which costs are still estimates. A polished total with no assumptions is harder to evaluate than a range with a clear basis.
Make the publisher request specific commitments
State the funding amount or range, the production period it supports, and the services being requested. Those services might include financing, platform relationships, marketing, localization, QA, distribution, porting or release operations. Do not assume every publisher provides the same package.
Clarify what you are prepared to discuss regarding intellectual property, recoupment, revenue share, platforms, territories, sequel or option rights, creative approvals and delivery obligations. These are legal and commercial matters that require qualified advice. The pitch should show that the team knows they exist, not attempt to settle them in a slide.
End with one next action: play the build, schedule a review, request the data room or answer specific diligence questions. “We would love to partner” is a sentiment, not an ask.
Match the submission to the publisher
Before contacting anyone, review the publisher’s current portfolio, announced focus, territories, platforms and submission instructions. Confirm whether unsolicited pitches are accepted and which materials are required. Address the relevant submission channel rather than sending personal messages to unrelated employees.
Create a short fit note for each target:
- Why this game belongs in the publisher’s present portfolio conversation
- Which requested service appears relevant to its model
- Which part of the pitch may conflict with its known focus
- What must be customized in the deck, email or build access
Do not claim fit based only on a publisher having released one game in the same broad genre. Portfolio spacing, production stage and team relationship can matter as much as genre.
Prepare for the pitch meeting as diligence
Assign speaking ownership before the meeting. The creative owner explains the player experience, the production owner explains scope and budget, and the technical owner addresses build risk where needed. A small team may combine these roles, but the answers should remain consistent.
Expect questions about audience, retention or replayability where relevant, content volume, production velocity, hiring, technical dependencies, release platforms, rights and the consequences of a lower or later funding outcome. If the answer is unknown, name the test or document that can resolve it. Guessing under pressure creates inconsistent diligence later.
Prepare a controlled data room with the current deck, budget model, milestone plan, company and ownership information, contracts or rights records, build instructions and requested metrics. Share confidential material through appropriate access and only when the process requires it.
Audit the pitch for common rejection risks
| Weak signal | Why it creates doubt | Correction |
|---|---|---|
| The pitch starts with lore | The actual play remains unclear | Lead with player action and loop |
| The trailer hides the current build | Production maturity cannot be judged | Label footage and provide playable evidence |
| The audience is “everyone” | Positioning and acquisition assumptions are undefined | Name behavior, preferences and alternatives |
| The budget is one total | Scope and runway cannot be tested | Show categories, timing and assumptions |
| The roadmap has dates but no evidence gates | Progress cannot support funding decisions | Define playable milestone outcomes |
| The ask is only “publishing” | The desired relationship is ambiguous | Name funds, services and next action |
Use external support without losing pitch ownership
A team may use game prototyping and vertical slice support to produce evidence for a pitch, or broader game development outsourcing to close a production gap. Attribute the work accurately and explain who owns the source, pipeline and next phase. A publisher is evaluating the delivery system around the game, not only the demo.
The final pitch should sound like the people making the product. Use direct language, disclose what is representative, and remove claims the team cannot support. A strong publisher pitch does not eliminate risk. It shows a valuable game, evidence that deserves attention, and a team capable of managing the next set of risks with the requested support.
