Source metadata

Key takeaways

  • Who it is for. Ismail says many existing decks are “made by publishers to benefit publishers (ie. starting with the budget) to help them filter faster”, or are too complicated. His template is “optimized for developers on their first or second game” and aims to give them “the most opportunities to prove credibility and ability to execute on the idea” (Ismail, Pitch Template post).
  • How it was tested. He describes running the deck past publishers for criticism and past developers for usability, and the post says it carries “the blessings of” people at several indie studios and “two dozen publishers”. This is his own account of the review process; the wiki has not seen that feedback.
  • The goal of a pitch. The deck should “generate interest and further conversation, not to be exhaustive nor to sign the contract right after the presentation” (Ismail, Pitch Template post).
  • Sell the business case. The template’s guidance slide says “Your goal here is to sell the business case – not the game”, because the developer is selling a collaboration that results in the funder selling the game.
  • The deck must work without you. Many publishers ask for the deck before any meeting, so the slides must make sense unpresented. Speaker notes can hold extra context and links, but “Nothing critical should be in the notes”.
  • Presentation matters. “Pretty works.” Ismail recommends styling the deck in the game’s own visual mood, and recommends using the template as a guideline and then rebuilding the presentation from scratch around the game.

The five-part structure

Ismail names the structure “Who, saw which opportunity, to make what, how can you benefit, & what do we need?“. Each section carries a guide time, slide count and depth.

SectionGuide time and slidesJob in the pitch
Who1–3 minutes, 1–3 slides, medium depthEstablish trust: who is on the team if funded, relevant people, and shipped work
Saw Which Opportunity1–2 minutes, 1–2 slides, conciseThe “artistic why” (why this team chose this game) and the “business why” (the opportunity or “problem” the game addresses)
To Make What2–5 minutes, 2–5 slides, in depthThe game itself, split into the Dream, the Proof and the Work
How Can You Benefit?1–2 minutes, 1–2 slides, conciseAn honest comparative analysis that shows a market exists and justifies the budget
What Do We Need?2–3 minutes, 1–2 slides, medium depthThe ask: timeline and budget, followed by a one-slide summary and contact details

The order is deliberate. The template “assumes your biggest weakness is relevant experience”, so it leads with the team. More experienced teams may move “Who” to after “How Can You Benefit”. Ismail does not recommend moving the ask: ending with the budget means the publisher has seen the whole offer before money enters their thinking, and “A great pitch will have them going ‘perfect’ at your budget”.

Section guidance

  • Who. “For young studios, the biggest risk a funder can identify for your project is going to be you.” Teams without relevant experience can still pitch, but must show realism through the prototype, budget and timeline. Listed games “do not need to be successful! Having shipped is good enough”; sales figures matter little unless the team had a major hit, although mobile KPIs are important. “Relevant” means work “of similar or aspirationally similar scale”.
  • Saw Which Opportunity. This section acts as a logical bridge from the team to the game (for example, a team that has always played RTS games pitching an RTS). Ismail notes that a “strange” bridge, such as curiosity without experience, can also work.
  • To Make What: the Dream. Establish the game through familiar elements (genre, mechanics, art style), then show what is new. Focus on “what” and “why”, not “how”, unless the technique is transformational. Sell the final game, not the current build: mock-ups are better than screenshots of an early prototype. Embed any trailer as a video file rather than relying on YouTube.
  • To Make What: the Proof. Show existing work (prototype or vertical slice). “Nothing on the ‘Proof’ slide should be speculative.” The less proof a team has, the more likely the answer is “come back later”, which Ismail treats as better than a “no”.
  • To Make What: the Work. Show how the game delivers its promises, with short videos or GIFs rather than still images. “Numbers are not interesting unless they’re really remarkable. 1 billion characters is remarkable. 12 levels is not.” The template offers optional example slides for a gameplay loop, a narrative overview, retention goals for longer or live-service games, and a technology stack.
  • Lean into strengths. “Aim to pitch something people could hate”: trying to make everyone love the game dulls what makes it distinctive.
  • How Can You Benefit? Use three honest comparables, scaled to the asking budget: one with estimated revenue of about 70% of the budget (between 50% and 100%), which the pitched game should clearly beat; one at about 130% (100–200%), which it should compete with; and one at about 300% (no more than 500%), which it could believably reach. “Nobody cares that Minecraft & Among Us made a lot of money. They’re not comparables.” An optional positioning grid helps in busy genres.
  • What Do We Need? Timeline. Ismail states that most competitive indie games need 1.5–2 years after signing; that timelines between 9 months and 2.5 years are “generally viable”; that “Content Complete” to “Launch” is usually about three months; and that a 30% margin per milestone “tends to be safe”. He also says pitches “are most likely to succeed if you start pitching between Prototype and Vertical Slice”. Funders judge the ratios between milestones (for example, an RTS is feature-heavy, an open-world RPG content-heavy).
  • What Do We Need? Budget. “Too high is better than too low.” A low budget “just shows you are not qualified to make the game”. Build a roughly 30% margin into expenses rather than listing it separately, and let the funder push the number down. The budget slide includes a break-even calculation: total asking budget divided by 70% of the target price. Funders also judge the ratios between disciplines.
  • Summary slide. Game name, asking budget, genres or tags, projected release date, platforms, engine, links to builds and contact details.

After the deck

  • Outreach. Ismail suggests using “Alan Dang’s List” of publishers, setting aside your five favourite publishers, and emailing every other publisher on your target platforms: “Don’t filter them, let them filter you.” Game World Observer’s coverage reports the same advice.
  • The email. Use a subject such as “Game Title – Looking for Publisher”, a short store-page-style description, and links to playables or trailers. Host the deck somewhere it can be updated and link to it.
  • Iteration. Test the pitch on industry contacts and note what they do not remember. “Pitching is iterative. Don’t try and wait until you have everything perfect.”

Notable claims

  • “These are common red flags publishers named for pitches”: Ismail’s post says publishers named weak credibility, failure to showcase the game’s strengths, and the lack of a “realistic production mindset” as common red flags, and that the template is designed to help developers avoid them.
  • “If you end up too high – there’s room to negotiate. If you end up too low, you’ll fail the pitch immediately.”
  • “There is no set formula for a good pitch. There are, however, general things that make a bad pitch.”
  • “Your presentation should work without you.”

Relevance

This source primarily informs:

It also supports:

Evidence limits

This is one experienced practitioner’s advice, refined (by his account) with feedback from publishers. It is valuable because it is specific, free and written for first-time teams. It is not research evidence. The numeric rules of thumb (the 70% / 130% / 300% comparables, the 30% margin, the 9-month to 2.5-year timeline range, and the 70% revenue share in the break-even formula) are Ismail’s heuristics. They are not industry-wide standards, they date from 2023, and they assume a commercial publisher pitch for a game in progress. They should be presented to students as one consultant’s working rules, cross-checked against Della Rocca’s pitching articles (see source-game-pitching-to-publishers) and current publisher guidance.

The template is a live Google Slides file and could change. The guidance slide recommends “10 - 14 slides” with up to 15 minutes of speaking, while the introductory post describes “15-20 high impact slides” for a 10–15 minute pitch. The wiki records both figures. Game World Observer’s statement that the file has 18 hidden slides was not counted independently.

The linked newsletter articles that the template treats as prerequisites (Budget Viability, Milestones, Anti-Bullet-Points and A Good Pitch) were not ingested here.

Open questions raised

  • How should the comparable-revenue bands be adapted for student assessment pitches, where there is no real budget or revenue estimate?
  • Does leading with “Who” still help a student team with no shipped work, or should such a team lead with the prototype?
  • How far do Ismail’s 2023 timeline and budget heuristics hold in a tighter publishing market?