Publishing Strategy

What a publisher actually reads in your pitch deck

A publisher evaluates your game by building a risk model. Most developers present their pitch as a story about the game. The publisher reads it as a story about what can go wrong.

When a pitch came in at Raw Fury, the conversation around it was rarely about whether the game looked interesting. It usually did. The question was whether there was a viable path from that deck to a shipped game, and how much risk sat between here and there.

There are five categories of risk that come up in some form on almost every project. Knowing what they are doesn't change whether your game is a good pitch. But it changes how you prepare, and it changes which gaps in your deck are going to generate the most questions.

Creative risk

Every game has a few things it absolutely has to get right to reach its potential. The publisher is trying to work out what those are, and whether the team has identified them.

For one game it's the core loop: if the base gameplay isn't satisfying in the first ten minutes, nothing else matters. For another it's the writing, or the visual identity, or the pacing of the mid-game. A publisher reading a deck is looking for evidence that the team knows which parts need to be exceptional, treating that as separate from the launch feature list.

A prototype or vertical slice that demonstrates exactly the part of the game that needs to work is very useful at this stage. Not as proof that the whole thing is built. As proof that the team knows what the concept actually is and has already tested whether it lands.

Financial viability

Every publishing deal is a bet on whether the total cost to bring the game to market makes sense relative to the revenue opportunity. The publisher is doing that math before they get excited about the concept.

The proposed development budget, the publisher's own service costs (porting, QA, localisation, marketing), and a realistic projection of what the game can earn need to be in the right order of magnitude relative to each other. A game with a realistic lifetime revenue ceiling of 500,000 euros probably can't support a development budget of 400,000 euros plus full publishing services. The math doesn't close, and a publisher who has been doing this for a while can see that in about thirty seconds.

This is also where market awareness matters. A deck that includes comparable titles, their sales performance, and what the game is positioning against is a different conversation from one that relies on the game being good. Publishers have seen a lot of pitches that rely on the game being good.

Commercial opportunity

Is there an audience for this game, and is that audience reachable at a cost that makes the deal work?

Some genres are crowded in a way that makes break-through genuinely difficult and expensive. Others have clear player appetite and not many good options. A game in a saturated space needs a specific answer to why someone would buy this instead of the ten similar titles already available on sale. A game in a cleaner space has more room, though "cleaner space" can also mean "smaller audience," which is its own problem.

The timing and positioning questions matter here. Who is this game for? Where do those players go to find new games? Is there a community that already exists, or does one need to be built from nothing? A game that fits naturally into an existing conversation is cheaper and easier to launch than one that needs to create its own context first.

Technical risk

New technology, networked multiplayer, custom engine work, large open worlds, procedural generation at scale. All of these carry execution risk that's hard to assess from the outside and easy to underestimate from the inside.

A team pushing an engine well beyond its comfortable range, or implementing a technology they haven't used before, will hit unknowns. That's fine if it's accounted for in the schedule and the team has the experience to navigate it. It's a problem if the plan assumes everything goes smoothly, because it won't.

What publishers respond well to is honesty about the hard parts. A deck that names the technical challenges and explains how the team is approaching them is more credible than one that doesn't mention them. Everyone who has shipped a game knows the difficult parts always show up. A team that knows that too is easier to work with than one that's still finding out.

Team and execution

Underneath all of it is whether the team can make the game.

Has this team shipped something of similar scope before, in this engine, together? Not separately at previous studios. Not on projects that never released. Together. A team that has shipped once, even something small, has already solved most of the hard coordination problems. A team pitching their first project at this scale is asking the publisher to carry execution risk that doesn't show up anywhere in the budget.

Processes matter here too, though not in an abstract way. The publisher is trying to work out whether milestone updates will be reliable, whether scope decisions get made or argued about for months, and whether the people in the room will still be working together eighteen months from now. A clear lead with actual decision-making authority and a team that has functioned under pressure before is a different risk profile from a collaborative structure where no one is obviously accountable.

Team conflicts, unresolved co-founder dynamics, key dependencies on one person who is also the lead programmer and the art director. These things come out eventually. Better to surface them before the advance is signed.