Risk to test
The streaming and load loop
Before art is locked, we measure how much world can be streamed behind a doorway and what a transition costs. The prototype proves the loop you will run for the whole project.
Spectrum Innovation Solutions · PC Game Development
Plate 01 · 06
From prototype to a publisher-ready PC build
Most PC games do not fail because the idea was wrong. They fail because the build pipeline, the frame budget or the packaging decision was left until the end. This page describes how we take a PC title from a rough prototype to something you can hand to a publisher or put in front of players, and what we need from a team to do it.
Scope boundary
Scope is the first engineering decision
Before a line of production code, we set the scope boundary with you in writing: what the game does, what it deliberately does not do, and which features are in the first shippable version.
This is not a design document exercise. It is a way to keep a small team's calendar honest, which matters more in a compact market like Belgium than in a studio with a hundred people and room to absorb a wrong turn. Scope changes later, and that is fine, but the change should be visible and priced.
Scope notes
Never wider than the first shippable build
- In
- What the first shippable version of the game does, and which features reach players at launch.
- Fixed
- Out
- Features deliberately absent from v1, listed in writing so nobody assumes they are handled.
- Named
- Later
- Changes made after the boundary are shown as a visible change and priced against the calendar.
- Priced
A prototype that tests the risky part
The prototype is deliberately not a trailer. We pick the single most dangerous assumption and build the smallest thing that exercises it. That choice changes by game:
Risk to test — action
Input latency and hit response
Measured across different controllers and frame rates. Response time is a design input here, not a late tuning pass, and the numbers decide the animation budget.
Risk to test — systems
The save format
What happens when the schema changes after launch. The prototype proves migration paths early, while changing the format is still cheap.
You get a running build to click through and a short written read on what it told us.
Milestones that map to decisions
We break production into milestones defined by what can be decided at the end of each one, not by feature count.
That style suits teams who need to make funding or publisher conversations on evidence. It also gives you an honest early answer if something is not going to work, which is cheaper to hear in month four than month fourteen.
-
M1
The loop stands up
The core interaction is playable end to end with placeholders. Decision: is the loop worth building a game around.
-
M2
The vertical slice holds its frame budget
Real art budget, real lighting, real target hardware. Decision: which art direction can ship at the frame budget you named.
-
M3
The save system survives a migration
A v1 save file opens in a v2 build without losing player state. Decision: the storage format is settled before content scales.
-
M4
The release-candidate pipeline runs without a human
Any teammate produces a build from the current commit in one step on a clean machine. Decision: the build process is no longer the critical path.
The build pipeline and why it is a product feature
A reproducible pipeline means anyone on the team can produce a build of the current state in one step, on a clean machine, with the same result. It means a build from six weeks ago can be rebuilt when a storefront asks a question or a certification body needs a specific revision.
We set this up early because retrofitting it into a project that has been assembling builds by hand is far more expensive than doing it before the second milestone. The pipeline is part of what a publisher buys when they sign a PC title: reproducibility is the difference between "we think the build is fine" and "send us the exact revision".
What it fixes
Anyone on the team rebuilds the current state, on a clean machine, in one step.
What it repays
A six-week-old revision is rebuilt on request — for a storefront, a certification, or a patch.
Profiling: measuring instead of guessing
We profile on the machines your players actually have, not only on the workstation in the corner. That means CPU and GPU frame timing, memory behaviour over a long session, load times on a spinning disk as well as an NVMe drive, and what happens when the game has been running for three hours.
Optimization work is scheduled like any other milestone, because treating it as polish is how teams end up cutting content in the final month.
Target hardware matrix
Measured
CPU frame time
Per-thread timing across the game loop, not average frame time.
GPU frame time
Frame timing on entry-level through to high-end cards, at honest settings.
Long-session memory
Behaviour after three hours of play, on a real save file.
DirectStorage and level pacing
Microsoft highlighted new DirectStorage capability updates in its 2026 game-development notes, and the technology is designed to improve asset streaming and loading performance as part of the Windows performance stack.
For large-world projects this is a design input: how much can stream behind a doorway, how long a transition can honestly take, whether a hub can load while the player walks. Deciding that in pre-production is much cheaper than discovering it during a certification build.
Our Windows tech stack notes the specific tools we lean on when a streaming budget has to be proven, not estimated.
Read about our Windows stack
Pre-production questions
Settled before certification
- How much world can stream behind a doorway Paced
- How long a transition can honestly take Paced
- Whether a hub can load while the player walks Paced
Packaging format decides your update story
The packaging format determines patch size, how updates reach players, which storefronts you can use easily, and how much disk space your game occupies in someone's library.
We plan it alongside the build pipeline, not in the week before release. If a game is going to run for years with seasonal content, the format and the patching approach need to be chosen together, and both need to survive a change of plan.
What the format decides
Chosen with the pipeline
- Patch size
- How large a seasonal content drop is to download, and whether patches are incremental.
- Delivery
- How updates reach players, including how a storefront handles a hotfix.
- Storefronts
- Which storefronts you can use easily, and where a format decision narrows your options.
- Disk fit
- How much room the game occupies in someone's library, which shapes the install-and-play decision.
Release preparation and the last weeks
The final stretch is logistics: storefront metadata, build variants, localisation handoff, crash reporting set up before launch rather than after, and a documented process for hotfixes.
We prepare a release checklist with you and work through it. If the title launches with LiveOps or multiplayer, the backend plan has to exist well before this point, because launch week is not the time to be choosing services.
-
Step one
Storefront metadata and build variants agreed with each partner before the branch is cut.
-
Step two
Localisation handoff scheduled against a frozen string table, not against the deadline.
-
Step three
Crash reporting wired before launch so the first week's signal is real, not anecdotal.
-
Step four
A documented hotfix path the team can run without us, if you would rather keep it in-house.
What a LiveOps plan actually changes
If a game is intended to run after launch, that decision reaches back into the architecture: how content is delivered, how player state is stored, how a patch that changes save data is handled.
Teams often plan LiveOps as a marketing calendar. We treat it as an engineering constraint that shapes the build pipeline and the packaging format from the start. The backend services question, which ones and why, is worth answering during pre-production.
Content delivery
Architecture
How new content reaches players: over a patch, a separate channel, or bundled with the game build.
Player state
Architecture
Where progress lives, how it survives a patch, and how it recovers when a client is offline for a week.
Save-data patches
Architecture
What a patch that changes save data has to do to an existing player without losing them.
What we need from you
A project brief, a rough sense of the deadline, and a named person on your side who can make decisions. Access to your existing code or design material if there is any.
Beyond that, we can work with a team of any size, from a solo developer with a publisher deal to a product group inside a larger company. Contact is the place to start, and Our Process explains what the first weeks look like once we begin.
Studio correspondence
Mon to Fri · 9:00 – 18:00
- Studio
- Raveschoot 22, 9080 Lochristi, Belgium
- Briefs
- [email protected]
- Phone
- +32 9 352 91 28
Send the brief at any stage — a one-page pitch, a playable prototype, or a project already in production. We reply with a read on what the pipeline needs first.