A Prototype, Not a Pitch Deck: How We Actually Start New Game Projects

I've seen a lot of pitch decks. Some of them were beautiful: mood boards, key art, a confident one-line hook, a feature list, a market slide with a big number on it. And almost all of them had the same problem.

You can't play a pitch deck.

A deck can tell you what a game is supposed to be. It can't tell you whether it's fun, whether the core loop holds up after twenty minutes, whether the camera works in tight spaces, or whether the idea fits the budget. Those are the questions that decide whether a game succeeds - and they only get answered when someone can pick up a controller.

That's why every full development project at LYNXBYTE GAMES starts with a working prototype, not a pitch deck. In this article I'll explain what that means in practice: what we build, what goes into it technically, how to judge it, and how it turns into a production plan.

Why a pitch deck is a weak decision tool

I'm not against pitch decks. They're useful for explaining a vision, aligning stakeholders and getting a first "yes, let's look at this". The trouble starts when a deck is used to make the big decision - the one that commits a budget, a team and a release window.

A deck is good at answering what: what the game is, who it's for, what it looks like. It's bad at answering does it work:

• Is the core loop fun? A deck describes it. Only playing it shows whether it's satisfying the tenth time, not just the first.
• Does it feel right? Movement, camera, input response, the weight of an attack - none of that exists on a slide.
• Does the space work? Scale, sightlines, pacing between encounters - a level that looks great in concept art can be miserable to move through.
• Is it buildable for this budget? A feature list doesn't show which feature is secretly the hardest one.
• Is the technical plan realistic? The riskiest assumption - performance on target hardware, a new system nobody has built before - is usually invisible in a deck.

When those questions stay open, they don't disappear. They come back in production, when changing direction is many times more expensive.

What we build instead: a playable greybox

Our prototype is a greybox: a playable version of the game's core, built with simple placeholder geometry instead of final art. It tests four things before a single final asset is made:

1. Layout - how the space is built and how players move through it.
2. Scale - how big things feel relative to the player and the camera.
3. Pacing - the rhythm of action, exploration and rest.
4. The core loop - the thing players will do again and again, and whether it holds up.

It's deliberately not pretty. Grey boxes, placeholder characters, temporary UI. That's not a shortcut - it's the point. When a prototype looks unfinished, everyone in the room judges what matters: how it plays. Nobody falls in love with a texture.

It's worth being precise about what a prototype is not, because these terms often get mixed up:

A prototype comes first because it's the cheapest moment to be wrong.

How we actually start: step by step

Here is the path of a new project, from the first message to the moment we commit to full production.

1. Free assessment

You tell us about the IP, the idea and the platforms you want to reach. You don't need a full design document - even a rough idea and the IP behind it is enough. Within 3 business days, we come back with a scoped estimate, a timeline and the engagement model that fits: a full external team, a dedicated team working directly with your studio, or senior engineers plugged into your existing pipeline.

2. Concept and discovery

Before anyone opens an engine, we dig into the franchise, the audience and what players said about previous releases. Then, together with you, we shape three things:

• The pillars - the few principles every later decision gets checked against.
• The core loop - what players actually do, minute to minute. (Our glossary entry on the gameplay loop explains why it matters so much.)
• The scope - what is in the first version of the game and what is not.

If the game builds on an existing IP, this stage also covers what makes that IP work and what must be preserved. My colleague Sylwester wrote about that part in detail in Before the Engine: Building a Game on an Existing IP.

3. The prototype

This is where the deck would normally go. Instead, we build the greybox.

The most important rule is the one we take from all our prototyping work: prototype the riskiest thing first, not the most impressive one. If the biggest risk is the combat feel, the prototype is about combat. If it's whether a large open area runs well on the target hardware, the prototype tests exactly that. A prototype that only shows the parts we already know will work is a demo, not a test.

4. The decision

The prototype ends with a decision - and it's yours. Because it's the cheapest moment to change direction, we make sure it's the moment you decide. There are usually three outcomes:

• Go: the core works. We move to pre-production.
• Adjust: something works and something doesn't. We change the direction and test again, while changes are still cheap.
• Stop: the idea doesn't hold up. That's a good outcome too - a failed prototype at this stage saves months later.

5. Pre-production

Only now do we plan the full build: art direction, technical architecture, tools and a production roadmap with clear milestones. Each milestone has a flat fee and acceptance criteria, so you always know what the next stage costs and what "done" means.

6. Production, QA and launch

Design, engineering, art and QA work as one team, with transparent reporting and builds you can play at every milestone. Testing covers every target platform, followed by first-party certification on each console, handled by the same team that built the game. After launch, release management, publishing support, patches, updates and new content continue for as long as the game needs it.

What goes into a prototype, technically

"Build a prototype" sounds simple. In practice, a useful one is the result of a few deliberate technical choices.

It's built in the target engine. We work in Unreal Engine, Unity and Godot, and the prototype is built in the engine the game will ship on. That way, what we learn about performance, tools and workflow carries straight into production instead of being thrown away.

It starts from the question, not the feature list. Before building anything, we write down what the prototype has to answer. "Is the traversal fun?" "Can the camera handle co-op in tight interiors?" "Does the crafting loop make players want to go back out?" Every hour spent on the prototype should serve one of those questions.

The core loop is real, everything else is placeholder. The thing being tested is implemented properly - controls, camera, timing, feedback. Around it, everything is as simple as possible: grey geometry, capsule characters, debug UI. Spending time on final-looking assets at this stage would only make the build harder to change.

Game feel gets the attention it deserves. Input response, acceleration, camera lag, hit feedback - these small details decide whether a game feels good or "off", and they're impossible to evaluate on a slide. A greybox is the perfect place to tune them, because nothing else distracts from them.

Technical risks are tested on purpose. If the concept depends on something technically uncertain - a large number of characters on screen, a physics-heavy system, performance on a specific console - the prototype includes a focused test of it. Finding a hard limit now costs little. Finding it in production can cost the release date.

It's playable by people who didn't build it. The best feedback comes from people seeing the game for the first time. A prototype is only useful if the client's team can pick it up and play it without someone standing behind them explaining what's supposed to happen.

How to judge a prototype

For many decision-makers, playing a greybox is unusual - it's easy to be distracted by what's missing. Here are the questions I suggest asking while you play:

• Do I want to keep playing? Not "is it finished?", but "is there something here that pulls me back?"
• Is the core loop clear without explanation? If players need a tutorial for the basic action, that's a signal.
• Does it feel good to control? Movement, camera and response should feel intentional even without final art.
• Did the riskiest question get answered? The prototype should give a clear yes, no or "not yet" on the biggest risk.
• What surprised me? Surprises - good or bad - are the most valuable output of a prototype.
• What would I cut? A prototype often shows which planned features the game doesn't actually need.

And one question for the team that built it: what would you change if you started over tomorrow? The answer usually tells you more than any presentation.

When a prototype fails

I want to be clear about this, because it's the part people find hardest to accept: a prototype that fails is a success.

If the core loop isn't fun in a greybox, it rarely becomes fun just because the art gets better. If a technical assumption doesn't hold, it won't hold in production either. Learning that at the prototype stage costs a fraction of what it would cost later - and it leaves room to adjust the idea instead of abandoning a half-built game.

The worst outcome isn't a failed prototype. It's a project that skipped the prototype, went straight from a deck into production, and discovered the same problem six milestones in.

Why this matters for the business side

I work on the business side of our projects, so let me be direct about why we start this way.

It protects the budget. The prototype is the cheapest moment to change direction. Every decision made there - go, adjust or stop - is made with real evidence, before the big spend.

It makes the plan honest. Pre-production plans are built on what the prototype proved, not on what a deck promised. That's what makes it possible to commit to a flat fee per milestone with clear acceptance criteria - the same predictability we bring to our porting work.

It replaces opinions with something to play. Internal debates about whether an idea works tend to go in circles. A playable build ends them faster than any meeting.

It keeps you in control. You set the vision and approve the milestones. Day to day, you work with your dedicated team through a private Discord channel and a shared ClickUp project, with a producer who always answers and a lead developer for technical questions - no account managers standing between you and the people writing the code.

It means one partner from start to finish. The team that builds the prototype is the team that builds the game, tests it, takes it through certification and supports it after launch. Nothing learned in the prototype gets lost in a handover. We wrote more about that model in One Studio for the Whole Game.

What to bring to the first conversation

You don't need a pitch deck to start with us - and you definitely don't need a full design document. What helps most is:

• the idea, in a few sentences, and what makes it different,
• the IP behind it, if there is one, and what fans love about it,
• the platforms you want to reach,
• any existing assets, code or design documents we could build on,
• the biggest question you'd want a prototype to answer,
• your target timeline and the engagement model you have in mind.

If you have a game idea - or an IP that deserves a new game - tell us about it. We'll come back with a scoped estimate within 3 business days, and the first thing we'll propose won't be a slide. It'll be something you can play.

Frequently Asked Questions

Why does every LYNXBYTE GAMES project start with a prototype?

Because a working prototype answers questions a pitch deck can't. It lets you validate the fun and the core loop before committing to full production, which is the cheapest moment to change direction.

What is a greybox prototype?

A playable version of the game's core built with simple placeholder geometry instead of final art. It tests layout, scale, pacing and the core loop before a single final asset is made.

What's the difference between a prototype and a vertical slice?

A prototype tests whether the game works and answers the riskiest questions, using placeholder art. A vertical slice shows one piece of the game at finished quality, to prove the team can build it at that standard. The prototype comes first.

Do I need a full game design document to start?

No. Even a rough idea and the IP behind it are enough to get started. Concept and discovery, and then the prototype, shape the details together with you.

What happens after the prototype?

You decide: go, adjust or stop. If it's a go, pre-production turns what the prototype proved into art direction, technical architecture, tools and a production roadmap with milestones, each with a flat fee and acceptance criteria.

Which engines do you prototype in?

Unreal Engine, Unity and Godot - the same engine the game will ship on, so what we learn carries straight into production.

How is full development priced?

As a flat fee, agreed before we start and billed per milestone, so you always know what the next stage costs.