Belgium · Lochristi, East Flanders
A game and PC application studio in East Flanders. We take on indie titles, co-development blocks, simulation and serious-game work, VR and XR builds, and desktop software that ships outside the entertainment aisle.
Lochristi · workshop hours 09:00–18:00 CET
Prototype bench · the smallest build that answers one question
How a game engagement starts
A typical game engagement starts with a playable slice, not a design document that runs forty pages. We build the smallest version of the core loop that answers one question: does this feel right for ten minutes? If it does, we scope the rest. If it doesn't, we change the loop while it's still cheap to change.
From there the work moves into vertical slice, content production, and release preparation across PC and console. Cross-platform is a planning decision, not a late port: we flag input, resolution and save-system differences on day one, because those are the things that blow up a schedule two months before launch.
Four stages, one groove
Projects move through four visible stages: scoping, prototype, production, and handover. Each one ends with something you can look at. If a stage needs to run longer, we say so and re-scope rather than quietly stretching the estimate.
Scoping
The first stage produces a written brief and a rough schedule. We read what you have, ask the awkward questions about platform, budget and deadline, and put the answer in writing so that everyone is working from one description of the project.
Prototype
The second stage produces a build. This is where the loop is tested against real hands and real time, and where we decide — with you in the room or on the call — whether what exists on screen justifies the content work that follows.
Production
The third stage produces milestone builds with a changelog. A build goes out, someone breaks it, and we fix it before the next build goes out. That sounds obvious until you work with a team that doesn't do it.
Handover
The fourth stage produces source, documentation, and a session where we walk your team through the repository. You leave with the code, the build pipeline, and a written record of why the system is shaped the way it is.
The production process page walks through each stage with the artifacts involved
Two lanes, one pipeline
Our work splits into two lanes that share the same pipeline. Both lanes run through the same revision discipline, and the same test at the end of each stage.
Lane one
Original indie titles, publisher-linked production support, simulation software used for training, and VR/XR experiences. The game lane is the one most people arrive through, and it is the lane most of our Belgian studio network works in too.
Lane two
From internal tools to customer-facing utilities that need a real installer and a real update path. Windows desktop builds with the same versioning and testing structure we use on games, because the failure modes are similar.
Most of our partners are in Belgium or neighbouring countries, which helps when a project needs a workshop day instead of another video call. A build goes out, someone breaks it, and we fix it before the next build goes out.
Desktop work tends to live longer than a game does, so maintainability matters more than a clever one-off trick. Some clients arrive with a game-shaped problem that turns out to be a software problem: a simulation that talks to a real sensor rig, a training tool running on locked-down office machines.
Co-development, and what it changes
Co-development is not outsourcing with a nicer name. When a Belgian studio brings us in, or when we bring in another team, the risk is almost always coordination rather than capability. Two pipelines, two naming conventions, two ideas about what "done" means.
We run co-dev blocks with a written interface: who owns which system, what the handover artifact looks like, and how often the branches merge. Fishing Cactus in Mons built a business on exactly this model, mixing service work with original titles, and it's a reasonable template. The hybrid structure keeps a team solvent between pitches and keeps its tooling sharp.
If your project needs a block of production rather than a whole team, this is the section that matters most.
Before a co-dev block starts
A written list of which systems we would own, and which systems stay with your team.
The exact artifact each side hands over, and what shape it arrives in.
How often branches merge, and who is on the hook when two lines collide.
A short paid technical review of the codebase before we commit to a block.
We would rather have that conversation in week two than in month seven.
One groove, read left to right
Five frames from the working week: the bench, the milled face, the keyboard under monitor glow, the headset on the table, and the curve drawn by hand. Each one is something a partner has actually seen in a review.
Scroll left or swipe on touch — the strip reads in the order the work happens
Simulation and serious games
Simulation work is a real lane in Belgium, not a side experiment. LuGus Studios in Genk built its profile around it, and the reason is simple: a client who needs a training simulator pays for correctness, not for novelty.
The software has to reproduce a procedure accurately, log what the trainee did, and survive being used by someone who is not a gamer. Onboarding has to be near-invisible. Failure states have to be instructive rather than punishing. And the build often has to run on hardware chosen by an IT department rather than by us.
A frame dropped in a flat-screen game is a stutter; a frame dropped in a headset is a person reaching for a wall that isn't there. Comfort, framerate, and interaction design are the whole job, and visual ambition has to bend around them. We take on VR and XR work where the interaction model is settled, or where a client wants help settling it. We are honest when a project would be better as a flat-screen build with optional headset support.
Serious games also tend to have shorter iteration windows with the client in the room, which is genuinely useful. You find out what's wrong in a week instead of a milestone review. Cyborn in Antwerp is the clearest Belgian example of the harder VR target, having shipped Hubris as a VR action-adventure rather than a seated experience.
Where we sit in the Belgian scene
Belgium's studio base is small and geographically spread. Ghent has a cluster. Mons, Charleroi, Antwerp, Genk, and Kortrijk all have working teams. Nordic Bridge Solutions operates from Lochristi, close enough to Ghent that a meeting is a short drive and far enough that rent doesn't eat a project budget.
The scene here is export-oriented. Belgian teams sell into international publishers and international clients because the domestic market isn't large enough on its own, and that shapes how everyone works. English is the working language on most projects, documentation included.
Studios working in the same country
Fishing Cactus
Co-development blocks mixed with original titles.
Mons
LuGus Studios
Simulation and serious-game work for training.
Genk
Cyborn
VR action-adventure production at scale.
Antwerp
Nordic Bridge Solutions
This studio — games, co-dev, simulation, VR/XR, PC applications.
Lochristi
The list is short on purpose. The point is that working with a Belgian studio is a coastal-network decision, not a leap of faith — the same time zone, the same working week, and a short drive when a problem needs a room instead of a call.
Who we work with
What those groups share is a tolerance for directness. We'll tell you when a feature is out of scope for the budget you have, and we'd rather have that conversation in week two than in month seven.
Independent developers
Teams that need production capacity, or a technical partner for a specific system, rather than a whole studio to hand the project to.
Studios running co-dev
A block of production from a team that can read your naming conventions, join your build pipeline, and merge on your schedule.
Non-entertainment clients
Training providers and software companies that need interactive software built to a real installer-and-update standard.
What we don't do
No marketing campaigns.
No app-store publishing as a standalone service.
No projects where the brief is "make something like that other game".
No equity in place of fees.
Saying no to work is part of keeping a pipeline honest. A studio that accepts everything ends up with three half-finished projects and no reputation.
Starting a conversation
The first step is a written description of what you want built, even if it's rough. From that we can say whether it's a fit, what a realistic first stage looks like, and what it would cost to find out if the idea works.
There's no pitch deck and no discovery fee for the initial exchange. We come back with a straight answer, including a no if that's the honest one.
Project enquiry
Questions worth answering up front
These are the questions that come up most often on a first exchange, and it is quicker to answer them here than to schedule a call to ask them.
Yes. Most of our documentation and communication is in English, and our working hours overlap with the rest of Europe. On-site visits happen at milestone points rather than weekly.
Often, yes. It depends on how the codebase is structured and whether there's a clean interface for the system we'd own. We usually ask for a short paid technical review before committing to a block.
Yes, if the scope is honest. A two-month tool build with a clear deliverable is a fine project. A two-month build of a game that needs a year is not, and we'll say so.
Windows desktop is the default. Console and VR/XR support depends on the project and on which platform holders we can get access to. Cross-platform decisions get made during scoping, not at the end.
Where to go next
Pick the page that matches what you actually want to ask about. If you are not sure, the contact page reaches us either way.
