Building a Game on an Existing IP: Where Full Development Begins

Building a game based on an existing IP? The first step isn't opening the game engine.

It's understanding what makes the original IP work - and how to translate it into a playable experience.

That sounds obvious, but it is the step most often rushed. There is a strong pull to start building straight away: the IP is known, the audience exists, the publisher has a release window in mind. Why spend weeks on analysis when you could be making the game?

Because on an established IP, almost every expensive mistake is made before the first line of code is written. A misread of what players love about the original. A codebase assumed to be reusable that isn't. A scope that quietly grows to include everything the franchise has ever done. None of these show up on day one. All of them show up later, when changing course costs months instead of days.

Quick facts: At the start of full game development on an existing IP, we focus on five areas: IP analysis, technical assessment, scope definition, technical prototyping and production planning. The goal is to reduce uncertainty before it becomes expensive, so that the game feels right to the people who love the original and works technically on every target platform.

1. IP analysis: what actually makes it work?

Every IP has a set of core pillars - the things that, if you removed them, would make the game stop feeling like itself. They are rarely the things on the box art.

Sometimes it is a mechanic: a specific movement feel, a combat rhythm, a resource loop that players have spent hundreds of hours inside. Sometimes it is the world: its tone, its rules, the way it rewards exploration. Sometimes it is something harder to name - the pacing between tension and relief, or the way the game respects the player's time.

So we start by identifying those pillars across four dimensions:

Identity - the tone, the style and the emotional promise of the franchise.
Mechanics - the systems players actually engage with, and which of them are essential rather than incidental.
World - the setting, lore and rules that a new game has to stay consistent with.
Audience expectations - what the existing community expects, what it would welcome, and what it would reject.

That last point matters more than it seems. An established IP comes with an audience that already has opinions. A new game can surprise them, but it should not betray them. Knowing where that line is before production starts is far cheaper than discovering it from the reaction to a reveal trailer.

2. Technical assessment: what are we really starting from?

Once we know what the game needs to be, we look at what already exists to build it with.

That means evaluating the existing codebase, tools, assets, dependencies and platform requirements. Is there a previous game whose systems can be reused? Which engine and version is it on? Are the build pipeline and tooling still working, or did they live on one machine that nobody has turned on for five years? Which middleware is still supported, and which licences still cover a new release? This is closer to technical due diligence than to a quick code review.

Reusable is a word worth testing rather than assuming. Code written for one game, one hardware generation and one team's habits often carries assumptions that only become visible when you try to build something new on top of it. Sometimes a previous codebase is a genuine head start. Sometimes it is technical debt with a familiar name.

And sometimes there is no reusable codebase at all - the original was built on a custom engine, the source is incomplete, or the new game is simply too different. That is not a problem in itself. It just means the assessment shifts to what needs to be built from scratch, and how long that realistically takes.

Platform requirements belong here too. A game planned for PC, PlayStation 5, Xbox Series X|S and Nintendo Switch 2 has different technical constraints from day one than a PC-only release, and those constraints are much easier to design for than to retrofit.

3. Scope definition: reuse, adapt or build new?

With the IP pillars and the technical picture side by side, we can define the scope honestly. Every part of the game ends up in one of three groups:

Reuse - systems, assets and tools that can carry over with little or no change.
Adapt - things that exist but need significant rework to fit the new game, the new engine or the new platforms.
Build new - everything that requires entirely new development.

This split is where most of the budget is decided. "We already have that" is one of the most expensive sentences in game development when the thing in question actually belongs in the adapt column. Being explicit about each feature, rather than estimating the project as one big block, is what keeps scope under control later.

It is also where the IP analysis pays off. When you know which pillars are essential, it becomes much easier to say no to features that are nice to have but don't define the experience - and to protect the ones that do.

4. Technical prototyping: test the riskiest assumptions first

Every project has a handful of assumptions that, if wrong, would change everything. The new traversal system will feel as good as the original. The streaming approach will hold up on handheld hardware. The old animation data can be retargeted to the new rig. The combat will still feel responsive at 30 frames per second on the lowest target platform.

Before committing to a full production pipeline, we validate those assumptions with focused technical prototypes. Not a polished demo, and not a vertical slice yet - just enough to answer a specific question with evidence instead of optimism.

The rule we follow is simple: prototype the riskiest thing first, not the most impressive one. A beautiful environment shot tells you very little about whether the game will work. A grey-box test of the core gameplay loop on target hardware tells you a lot.

When a prototype fails, that is a good outcome. It means the problem was found while it was still cheap to change direction.

5. Production planning: turning findings into a roadmap

Only after the first four steps do we turn everything into a plan: milestones, resource estimates and a realistic production roadmap.

Because the plan is built on what we have actually learned, it can be specific. Each milestone has a clear outcome. The team composition matches the reuse, adapt and build-new split. The known risks are written down with a plan for each, rather than discovered halfway through production. And the timeline reflects the real starting point, not the one everyone hoped for.

This is also the point where a publisher or IP holder gets something they can genuinely plan around: what will be delivered, when, by whom, and what it depends on.

Reducing uncertainty before it becomes expensive

None of these steps are about slowing the project down. They are about making sure the speed comes later, when the team is building the right game on the right foundations.

Working with an established IP isn't just about recreating what already exists. It's about understanding its foundations well enough to build something that feels right - and works technically.

That's where full development begins.

If you own an IP and are thinking about what the next game could be, tell us about it. We'll start where we always start: by understanding what makes it work.

Frequently Asked Questions

What is the first step when building a new game on an existing IP?

IP analysis: identifying the core pillars of the original experience - its identity, mechanics, world and audience expectations - before any development starts. Everything else, from scope to technical choices, is built on that understanding.

Can the original game's codebase be reused for a new game?

Sometimes. A technical assessment of the existing codebase, tools, assets, dependencies and platform requirements shows what can be reused, what needs to be adapted and what has to be built from scratch. If there is no reusable codebase, the assessment focuses on what needs to be built new.

Why prototype before full production?

Technical prototypes validate the riskiest assumptions - such as game feel, performance on target hardware or reuse of old data - while changing direction is still cheap. A failed prototype at this stage saves months later.

What does a production plan for an IP-based game include?

Milestones with clear outcomes, resource estimates, a team plan based on what is reused, adapted and built new, a list of known risks, and a realistic development roadmap based on the project's actual starting point.