A studio workbench from above: keyboard, mouse and an uncapped pen on a slate worktop in cool north light.

Nordic Bridge Solutions · Insights

Notes on production, tooling, and the local scene

Name: Nordic Bridge Solutions
Address: Raveschoot 22, Lochristi, 9080, BE
Telephone: +32 9 375 73 83

Short editorial pieces on the practical side of building games and desktop software, with an eye on the Belgian development scene. These are notes rather than thought-leadership, written from work in progress. Read whichever is relevant to what you're deciding.

Working notes, published as we go

Eight notes from the bench — on milestone builds, installer paths, simulation delivery, estimates, co-development interfaces, VR frame budgets and the shape of the Belgian scene.

Start with the first note Talk to us about a project

Three threads through these notes

Game production Milestones, builds, and the small rituals that hold them Five notes Desktop & VR delivery Installers, signing, simulation, and frame budgets Three notes The local scene Belgian studios as a network, not a cluster Two notes

Game production

Running a game project without surprises

Most of the friction on a project happens before anyone touches a controller — in the reviewable artifact, the changelog that goes with it, and the interface two teams agree on before the first commit. These four notes cover the parts we have watched make the difference on live production.

A designer's hands at a pine desk with a grey-box prototype running on a blurred monitor at frame right. — Reviewable, before anyone has to ask what changed

Game production

What a milestone build should contain

A milestone build is only useful if someone can review it without asking questions first. That means a runnable version, a changelog that says what changed since the last one, and a short list of known issues.

The changelog is the part teams skip. It shouldn't be. A reviewer who doesn't know what changed will either re-test everything or test nothing, and both are expensive.

Known issues matter for the same reason. A build with a documented list of problems reads as managed. A build with no list at all reads as untested.

A runnable version someone can open without setup help
A changelog written for the reviewer, not for the team
A known-issues list short enough to read in one pass

Note two

Reading a studio's estimate

An estimate without a written scope is not an estimate. It's a number. The scope is what tells you whether the number means anything.

When you compare quotes from different studios, compare the scopes first. A cheaper quote for a narrower scope isn't cheaper, it's a different project. This is the most common beginner mistake we see in commissioning software, and it's an expensive one to learn on a live project.

Ask what's explicitly out of scope. A studio that can answer that clearly has scoped the work properly.

Compare first

What is promised, what is excluded, and what the studio expects you to provide.

Note three

Co-development without merge pain

Two teams with different branch conventions will generate more merge conflicts than either would alone. That's the main risk in co-development, and it's a process risk rather than a skill risk.

The fix is a written interface document before the first commit: who owns which system, what the handover artifact looks like, how often branches merge, and who approves changes at the boundary.

Fishing Cactus in Mons built a business around this kind of hybrid work. It's a viable model, but only when the interface is defined before the work starts rather than negotiated during a conflict.

Note four

VR comfort is a design constraint, not a polish item

Framerate in VR isn't a performance target, it's a comfort requirement. A dropped frame on a monitor is a stutter. A dropped frame in a headset is disorientation, and it takes very little of that before a user stops trusting the experience.

That means visual ambition bends around the frame budget rather than the other way round. Cyborn's Hubris is a useful Belgian reference here, since an action-adventure in VR is a harder target than a seated experience.

The design lesson generalizes even outside VR: decide what the hardware can carry before deciding what to build, not after.

Desktop & VR delivery

The last mile is where paying users get lost

Shipping desktop software is a different trade from shipping a game. Installer paths, signing, IT departments and hardware floors decide whether the audience ever gets to see the features the team built.

Note five · Desktop shipping

The cost of an unsigned executable

If you ship Windows desktop software to end users, code signing is not optional. An unsigned executable triggers security warnings on modern systems, and a meaningful share of users will stop at the warning.

This is not a technicality. We've seen projects with solid features lose their audience at the installer stage for want of a certificate and a clean installer path.

The fix is cheap relative to the loss. It just has to be planned rather than discovered after launch.

Note six · Simulation work

Why simulation projects behave differently from games

Simulation clients don't buy novelty. They buy procedural accuracy and a stable delivery, which changes how you prioritize.

Priority

On a simulation

On an entertainment game

Failure states

Have to teach rather than punish — the user is being assessed, not entertained.

Can punish, can delight, can surprise.

Onboarding

Near-invisible — the user's job is the procedure, not the interface.

Can be a designed moment of its own.

Target hardware

Chosen by an IT department, not the studio.

Chosen by the studio for the experience it wants.

Get those priorities wrong and the software works technically while failing in use. That's a worse outcome than a bug, because it isn't fixed by a patch.

The local scene

Belgium's studios work as a network, not a cluster

Belgium's studios are spread across Ghent, Antwerp, Mons, Charleroi, Genk, and Kortrijk rather than concentrated in one city. That's a structural difference from countries with a single dominant hub.

The effect is that the scene works as a network rather than a cluster. Teams know each other across regions, and hiring or subcontracting happens across a wider area than it would in a single-city scene.

It also means there's no single place a client can visit to see "the Belgian game industry." The industry is a list of studios, not a district.

A working list, not a ranking

Humble Grove Ghent · narrative-driven indie
LuGus Studios Hasselt · serious games and VR
Cyborn Antwerp · VR and animation
Fishing Cactus Mons · co-development and simulation
Appeal Studios Antwerp · AAA support work
Glowfish Interactive Kortrijk · action and multiplayer

Before you enquire

Five questions worth answering first

The clearer the starting point, the more useful the first conversation. If most of these have answers, we can talk about the work. If they don't yet, the first job is narrowing the idea — a different engagement, and worth planning for on its own.

01

What is this for?

What problem does it solve, or what is it replacing? A sentence is enough.
02

Which platform matters most?

PC, VR headset, web, or an internal deployment on hardware you already own.
03

What is the budget range?

Even a rough band is enough. It shapes what gets scoped in the first place.
04

Is there a hard deadline?

A launch window, a funding report, a partner commitment — anything fixed.
05

Can the core idea be described in a sentence?

Not a pitch — just the shape of the thing. We will ask more in the first call.

A slate worktop edge with a grey USB drive and a plain folded paper sleeve in cool north light.

Next step

We build the game, then hand you the keys.

If you have read this far and one of these notes matches the decision you are working through, tell us which one. The quickest way in is a short message saying what you are building, which platform matters, and roughly when you need it.

Talk to us about a project See our production process

Where we are

Nordic Bridge Solutions
Raveschoot 22, 9080 Lochristi, Belgium

[email protected]
+32 9 375 73 83

Mon–Fri, 09:00–18:00 CET