Remake or Remaster? A Technical Decision Checklist

"Should we remake it or just remaster it?" is usually asked as a creative question. In practice, it is mostly a technical one.

The answer rarely depends on how much the team loves the original, or on what the trailer should look like. It depends on what is actually left of the game: whether the source code still builds, whether the engine can reach modern platforms, whether the art exists at a usable resolution, and how tightly the gameplay is tied to hardware nobody ships anymore.

We covered the difference between the two approaches in Remaster or Remake? The Difference Is More Than a Marketing Term. This article is the practical follow-up: a checklist we use to turn that difference into a decision, before anyone commits a budget.

Remake vs remaster: the short definition

Before the checklist, it helps to agree on what the two words mean in engineering terms, because marketing uses them loosely.

There is also a middle ground worth naming: a remaster with an engine migration, where the original game logic and content are moved into a modern engine without redesigning them. It is more work than a classic remaster, but far less than a full remake. Many projects that start as "a remake" end up here once the checklist is done honestly.

How to use this checklist

Go through the eight areas below and score each one:

• 0 - points clearly to a remaster
• 1 - could go either way, or needs investigation
• 2 - points clearly to a remake

Add the scores up at the end. The total is not a formula that makes the decision for you, but it shows where the weight of evidence is - and, just as important, which areas you still don't know enough about. Any area you can't score yet is a task for technical due diligence, not a guess.

1. Source code: does it exist, and does it build?

This is the first question, and sometimes the last one. A remaster is built on the original code. If there is no code, there is no remaster in the strict sense.

Check:

• Is the complete source code available? Not just the game code, but tools, build scripts, shaders and any custom middleware.
• Does it build today? On a modern machine, with a compiler you can still install, into a binary that runs.
• Is it the shipped version? Source archives often contain an older branch, a later patch, or a version that never matched the release.
• Who knows it? Is anyone from the original team available, and is there documentation beyond comments?

Score 0 if the full source builds and runs the shipped game. Score 1 if it exists but needs source recovery or serious code archaeology to build. Score 2 if the code is missing, badly incomplete or cannot be legally used.

A missing codebase does not kill a project - it just changes it. Without source, the shipped game becomes the specification, and you are effectively in remake territory.

2. Engine: can it reach the platforms you need?

Even when the code builds, the engine underneath it has to survive the journey to modern hardware.

Check:

• Is it a commercial engine or a custom engine? An old version of a commercial engine can often be upgraded. A custom engine has to be extended by your own team.
• What does the renderer depend on? Engines built around a fixed-function pipeline or a long-deprecated graphics API need a renderer rewrite before anything modern can happen.
• Is it 64-bit? Current consoles and stores expect 64-bit builds. A 64-bit migration of an old engine touches pointer arithmetic, serialization and third-party libraries.
• Can it support the platform requirements? Achievements and trophies, suspend and resume, user accounts, cloud saves, controller disconnects - all of these have to be integrated at engine level for certification.

Score 0 if the engine can be upgraded or extended to every target platform with a contained amount of work. Score 1 if one or two major subsystems - typically the renderer or the platform layer - need rewriting. Score 2 if the engine would effectively need to be rebuilt to ship on modern platforms. At that point, an engine migration to Unreal Engine is usually cheaper than an engine rebuild.

3. Middleware and licenses: what can you legally ship?

Old games are full of third-party code: physics, audio, video playback, networking, input. Some of it is no longer sold, supported or licensable.

Check:

• Which middleware does the game use, and which versions?
• Is each one still available for the target platforms? End-of-life middleware often has no console version for current hardware.
• Do the original licenses cover a new release? Middleware, fonts, licensed music and video often had per-title or per-platform terms.
• Is the IP chain clear? Who owns the code, the assets and the music today?

Score 0 if everything is available and licensable. Score 1 if one or two components need middleware replacement. Score 2 if the core of the game - physics, audio, or the engine itself - depends on components you can't ship anymore.

This area is the one most often skipped in early estimates, and the one most likely to turn a "quick remaster" into a much bigger project halfway through.

4. Assets: can the original art scale to modern screens?

A remaster lives and dies by its assets. Modern displays expose everything the original resolution was hiding.

Check:

• Do source assets exist? Original high-resolution textures, layered art files, sculpts, uncompressed audio and video - not just the compressed versions that shipped.
• What resolution are the textures and models? Assets authored for 480p or 720p often fall apart at 4K, even with careful upscaling.
• Is the art pipeline recoverable? Can the files still be opened, exported and converted? Asset conversion from proprietary or discontinued tools can be a project of its own.
• Do animations hold up? Low frame-count animation and simple rigs are often the most visibly dated part of an old game, and animation retargeting to new rigs is real work.

Score 0 if source assets exist at a resolution that can be cleaned up and upscaled to the target. Score 1 if a selective rebuild is needed - for example, characters and key environments, while the rest is upgraded. Score 2 if most of the art has to be recreated anyway. When that happens, the visual cost of a remaster approaches the cost of a remake, without the benefits of a modern engine.

5. Gameplay code: how tied is it to the old hardware?

This is the most technical part of the checklist, and the one that most often decides between "keep the code" and "rebuild it".

Check:

• Is game logic tied to frame rate? Many older games run physics, input and timers per frame. Unlocking 60 or 120 fps then changes how the game plays - jumps get shorter, enemies move faster, timing windows break. Fixing this means decoupling simulation from rendering and controlling frame pacing.
• Does it rely on deterministic behavior? Replays, lockstep multiplayer and some puzzle or physics systems depend on deterministic physics, which can break when the compiler, the CPU architecture or floating-point behavior changes.
• Is the code full of platform-specific shortcuts? Hand-written assembly, assumptions about memory layout or hardware timing, and console-specific hacks all have to be found and replaced.
• How are saves handled? If players expect old saves to work, save migration has to be planned from day one.

Score 0 if the gameplay code is reasonably clean and can be decoupled from timing and hardware with targeted fixes. Score 1 if large parts need refactoring but the design can stay. Score 2 if the logic is so entangled with the old hardware that rewriting it is safer than untangling it.

Note that a score of 2 here does not mean the gameplay itself has to change. A faithful remake can reproduce the original behavior exactly - it just does it in code that can be maintained.

6. Design: should it play exactly the same?

Not every question on this list is technical. This one is about intent, and it changes the weight of everything else.

Check:

• Do players expect the original experience, unchanged? Some audiences want the exact game they remember, including its quirks.
• Are there design problems the community has complained about for years? Camera, controls, save systems, difficulty spikes, missing quality-of-life features.
• Does the game need to compete with modern releases, or does it mainly need to be available again?
• Do you want to add content, such as new levels, modes or characters?

Score 0 if the goal is preservation - the same game, running well on modern hardware. Score 1 if you want quality-of-life improvements without touching the core design. Score 2 if the design itself needs gameplay modernization, or if significant new content is planned.

A remaster can absorb small design fixes. Once the changes go deeper than that, you are paying for remake-level scope while still carrying the original code's limitations.

7. Platforms and performance targets

Where the game needs to ship shapes what the technology has to do.

Check:

• Which platforms are required at launch? PC only, current consoles, Nintendo Switch 2, mobile?
• What are the performance targets? Resolution, frame rate, loading times, and whether a docked and handheld profile are both needed.
• Which modern features are expected? Ray tracing, HDR, DualSense haptics, cross-save, crossplay.
• Does the original even fit the memory and streaming model of the targets? Some older games relied on loading screens and tiny memory budgets in ways that feel wrong today, but are hard to change without restructuring the game.

Score 0 if the targets are close to what the original engine can do with upgrades. Score 1 if specific features - HDR, haptics, faster loading - need deeper engine work. Score 2 if the targets demand a modern rendering, streaming and platform stack that the original engine cannot realistically reach.

8. Budget, timeline and team

Finally, the practical constraints. They don't change what the game needs, but they decide what is realistic.

Check:

• What is the release window? A remaster can often ship in months. A remake is closer to a full development cycle.
• What is the budget? A remake costs significantly more, and that cost needs a matching commercial case.
• What expertise is available? Maintaining a 20-year-old custom engine requires people who can read and safely change it. A modern engine has a far larger hiring pool.
• What happens after launch? If the game will receive updates, DLC or ports to future platforms, a maintainable modern codebase pays for itself over time.

Score 0 if the timeline is short and the goal is a one-off release. Score 1 if there is room for a larger project but the commercial case is still being proven. Score 2 if the game is meant to become a long-term product - with updates, sequels or a franchise relaunch built on top of it.

Reading your score

Add up the eight scores. The maximum is 16.

Two caveats matter more than the totals.

First, some single answers override the score. A missing codebase or an engine that cannot reach your platforms can decide the project on its own, even if everything else points to a remaster.

Second, unknowns are not zeros. If you could not answer an area, it doesn't count as a remaster point. It counts as risk - and risk in old codebases almost always costs more than it first appears.

Red flags that settle the question early

Some findings are strong enough that you can stop scoring:

• No buildable source code and no realistic way to recover it. You are building a remake.
• The game logic only works at the original frame rate and is spread across the whole codebase. Rewriting is usually safer than untangling.
• Core middleware cannot be licensed for current platforms, and the game is built around it.
• Most of the art would need to be recreated anyway. You are paying remake costs for remaster results.
• The plan includes major new content or design changes. That is a remake brief, even if it is called a remaster.

And a few that point firmly the other way:

• The source builds, the engine is extensible, and players want the original experience. That is a strong remaster case.
• The release window is short and fixed. A remake rarely fits into a few months, no matter how it is scoped.
• The value is in preservation - making a well-loved game available and playable again, exactly as it was.

Validate the decision before production

Whatever the checklist says, test it before committing the full budget.

For a remaster, the most useful early test is a build of the original game running on one target platform, at the target frame rate, with its gameplay timing intact. If that works, most of the remaining risk is in content and certification.

For a remake, the equivalent is a gray-box vertical slice of the core gameplay loop in the new engine, with placeholder art. If it doesn't feel like the original when it's ugly, better graphics will not fix it. We wrote more about that in How Do You Remake a Game Built on a Custom Engine?.

In both cases, the goal is the same: replace assumptions with evidence while changing direction is still cheap.

The checklist at a glance

1. Source code - does it exist, build and match the shipped game?
2. Engine - can it reach the target platforms, or does it need a rebuild?
3. Middleware and licenses - can every component legally ship again?
4. Assets - do source assets exist at a resolution that scales?
5. Gameplay code - how tightly is it tied to frame rate and old hardware?
6. Design - preservation, quality-of-life fixes, or modernization?
7. Platforms and performance - how far are the targets from the original tech?
8. Budget, timeline and team - a one-off release or a long-term product?

The right answer is not always the bigger project. Plenty of games are best served by a careful remaster that respects the original and ships on time. Others genuinely need to be rebuilt to have a future. The checklist exists so that choice is made on evidence, not on how the trailer should look.

If you have an older title and aren't sure which path it needs, our remake and remaster team can run this assessment with you - starting from the code and assets you actually have. Send us the details and we'll tell you what we see.

Frequently Asked Questions

What is the difference between a remake and a remaster?

A remaster keeps the original game's code, systems and content and upgrades its visuals, performance and platform support. A remake rebuilds the game, usually in a modern engine, using the original as the specification - the gameplay can stay faithful or be modernized.

When should a game be remastered instead of remade?

When the original source code builds, the engine can be extended to the target platforms, the source assets can be upscaled, and the goal is to preserve the original experience. A short, fixed release window also favors a remaster.

When does a game need a full remake?

When the source code is missing or cannot be built, the engine cannot reach modern platforms without being rebuilt, most assets would have to be recreated, the gameplay is tightly tied to old hardware, or the design needs modernizing or significant new content.

Can you remaster a game without the original source code?

Not in the strict sense. Without source code, the shipped game becomes the specification and the project is effectively a remake, even if it aims to recreate the original exactly.

What is a remaster with an engine migration?

It is a middle path: the original game logic and content are moved into a modern engine such as Unreal Engine without redesigning them. It costs more than a classic remaster but much less than a full remake, and it leaves a maintainable codebase for future updates and ports.

How do you decide between a remake and a remaster quickly?

Score eight areas - source code, engine, middleware and licenses, assets, gameplay code, design intent, platforms and performance, and budget and timeline - from 0 (remaster) to 2 (remake). A total of 0-5 usually means a remaster, 6-10 a remaster with engine migration or a scoped remake, and 11-16 a remake. Single red flags, such as missing source code, can decide it on their own.