Choosing an engine without locking your project in
The engine question gets more airtime than it deserves and less rigour than it needs. What follows is how we actually make the call with a team: what the project's content surface looks like, how the team works, and which middleware decisions are cheap to make now and expensive to change later.
One week of thinking, one or two conversations, one written recommendation.
Engine-led or custom
Engine-led and custom are not rivals
An editor-driven engine gives you a large amount of tooling on day one and a set of assumptions you inherit. A custom or framework-based approach gives you a smaller codebase and the freedom to build exactly what the game needs, at the cost of building everything the game needs. Neither is the professional choice. Both are tools, and the right one falls out of what the project is made of.
Editor-driven engine
- Scene-based content pipeline and visual tooling from the start
- Strong fit for large art teams shipping lots of scenes
- You inherit the engine's assumptions along with its editors
- Upgrade cycles are negotiated with the engine's roadmap, not your own
Framework-based approach
- Small codebase you can hold in your head end to end
- Suits unusual mechanics and data-heavy, tool-driven games
- You build the pieces you would otherwise inherit for free
- The content pipeline is a design problem the team owns
When a framework fits
When MonoGame fits better than an editor
MonoGame is an open-source framework for 2D and 3D game development, listed by Microsoft among current .NET game-development options and built around flexible C#-based workflows. It suits lightweight, custom-engine-style projects where an editor would be scaffolding around a small, well-understood set of mechanics.
A puzzle game with hand-authored levels, a systems-heavy simulation, a tool-driven game where the content is data rather than scenes: these are the cases where we reach for it. If your art team is large and your content pipeline is scene-based, the calculus usually flips.
- Good fit
- Puzzle with hand-authored levels, systems heavy simulation, data-driven tool
- Weak fit
- Large art team on a scene-based content pipeline
The middleware audit
The cost is not the licence fee
Before production we list every third-party dependency the game is likely to need: audio, physics, networking, animation, UI, save and localisation. Each one is a decision with a cost, and the cost is not the licence fee.
It is the integration time, the upgrade path, the debugging when something goes wrong inside a black box, and the risk that the vendor is no longer active when you need a patch. A short list of audited dependencies beats an impressive stack.
See how we run pre-productionDependencies we price, not praise
- AudioAudited
- PhysicsAudited
- NetworkingAudited
- AnimationAudited
- UIAudited
- Save & localisationAudited
Asset streaming
Asset streaming is an architecture choice
How assets move from disk to memory shapes level design, scene structure and loading screens. DirectStorage is designed to improve asset streaming and loading performance as part of the Windows performance stack, and for large-world or asset-heavy PC projects it changes what a level can be.
Middleware that assumes a traditional loading model can fight a streaming architecture. This is one of the decisions we would rather make early, with the level designers in the room.
-
01
Level boundaries can be drawn around what the player can see and reach, not around what fits in memory at once.
-
02
Scene structure has to be authored in chunks the runtime can predict, which is a design habit, not a plug-in.
-
03
Loading screens become a fallback for cold starts rather than the shape of the whole level flow.
DirectStorage sits inside the Windows performance stack, not beside it.
Cross-platform trade-offs
Priced honestly, week by week
A project that runs on Windows and one or two adjacent platforms is a different project from a Windows-only title. The engine, the middleware, the input layer and the packaging format all shift, and each shift has a cost in weeks.
We will tell you what that cost looks like for your specific project rather than quoting a general figure. If a platform is aspirational rather than funded, we plan the architecture so that it stays possible without paying for it now.
| Layer | Windows only | Plus adjacent platforms |
|---|---|---|
| Engine | One target, one build chain, fewer forced framework choices. | Rendering and platform layers get narrowed; the weakest supported target sets the floor. |
| Middleware | Fewer dependencies to audit; vendor terms negotiate on one platform. | Every dep needs a per-platform licence check, plus a fallback if one is not supported. |
| Input & packaging | Keyboard, mouse, controller on one input scheme; one installer shape. | Another input map, another storefront format, another set of submission rules. |
| If it's aspirational | Ship the Windows build without pre-paying for platforms nobody has funded. | Keep the abstraction seams where they cost least now, so a later port is scoped, not re-architected. |
Build the boring middle
Runtime, toolchain and the boring middle
The parts nobody demos are where projects get slow: build times, hot reload, asset import, editor extensions, the runtime that loads and unloads scenes. We invest in these because a team that waits four minutes per iteration loses a shocking amount of a year.
PowerToys is included in Microsoft's 2026 Windows game-development workflow guidance for exactly this reason: reducing daily friction, speeding access to command palette and workspace tools. Small wins, accumulated across the project, are what make the difference on a long production.
Switching engines mid-project
Survivably scoped, painfully expensive if it isn't
It happens, and it is survivable if it is scoped. The question is what is genuinely worth carrying across: design data, content, code, or just the decisions. We have moved projects from an editor-driven engine to a framework-based one and back, and the honest answer is that the transition costs more than the team expects and less than the fear suggests. What makes it work is deciding early which parts of the old project are throwaway.
Making the call with a team
A week of thinking, then one written recommendation
We run the engine decision as a short, structured exercise: the content surface, the team's existing skills, the platform targets, the middleware list, and the two-year outlook. It usually takes about a week of thinking and one or two conversations, and it ends in a written recommendation that names the trade-offs rather than hiding them.
If you want to talk through a project's engine choice before committing, the contact page is the right entry point.
What the exercise covers
- Content surface Session 1
- Team skills today Session 1
- Platform targets Session 1
- Middleware shortlist Session 2
- Two-year outlook Session 2
- Written recommendation Deliverable
Straight answers
Things teams ask before the first workshop.
Can you start a project on an engine we have not used?
Yes. The engine is a tool, and the team gets up to speed on it. What matters more is whether the engine fits the content surface and the platform targets, because a poor fit costs the project far more than a learning curve does.
Do you write custom engines from scratch?
Rarely, and only when the game's requirements genuinely cannot be met by an existing engine or framework. In most cases a framework-based approach gives you the small codebase and the freedom without rebuilding rendering, audio and input from nothing.
Which backend services should we plan for if the game needs LiveOps or multiplayer?
That depends on what the game does after launch: content delivery, player state, matchmaking, telemetry. We treat it as an architecture question during pre-production, and we pick services based on what the build pipeline and packaging format can support, not on which provider has the loudest marketing.
A Belgian studio, working on PC first
Spectrum Innovation Solutions is a Belgian PC game and application development studio based in Lochristi, working with teams on the engine choice, middleware stack and Windows runtime that a specific project actually needs.
If you want to see how the studio thinks about the rest of the pipeline, the pages below carry the same detail.