NEXORA Industrial Solutions NEXORA Industrial Solutions
A studio desk at eight in the morning, monitor dark, keyboard in the foreground, cool north light falling across the wall behind

Game Development

Six plates, pinned by your own scroll.

Making a game is a sequence of decisions that get harder to reverse — the engine, the platforms, the release window, the way players first hear about it. Here is how NEXORA Industrial Solutions works through them.

Talk to us about a game project See the full work process

The production pipeline

Six decisions, in the order they get harder to reverse

Each stage plate below carries one decision. Scroll past them and the stack assembles — the running stage is the one currently in build.

01 Engine

Engine choice, made early and documented

We evaluate the engine against the project rather than picking a house favourite. Open-source engines such as Godot offer 2D and 3D support, a lightweight workflow, and inspectable source — good for lean teams and experimental work. Commercial engines bring large middleware libraries and established console pipelines, which matters when the target list includes consoles. Either way, the reasoning gets written down: on a two-year project, the reason has to outlive anyone's memory of it.

02 Platforms

Target platforms and what PC-first means

Most of our game projects start with a PC release, because it's the cheapest platform to reach and the fastest to iterate on. That doesn't mean PC-only forever; it means PC is where the game becomes playable to real people soonest. Console and handheld targets get planned into the architecture from the start if they're likely, because retrofitting controller support, save systems, or certification later is expensive. Our rule: decide the target list before production, and revisit it only when there's a concrete reason.

03 Prototype

Prototyping before production

A prototype is a question with a build attached. We keep them short and narrow: one mechanic, rough visuals, and a clear decision at the end about whether to continue. Game jams are a useful version of the same practice, since the time limit forces a team to find the core of an idea fast. Most prototypes don't become products, and that's a feature. Killing something in week three is cheap; killing it in month nine is not.

04 Build

Production builds and the pipeline around them

Once a project is in production, the work shifts from invention to repetition. That means a build pipeline that produces a runnable version on a schedule, automated tests for systems that break quietly, and version control discipline that lets two people touch the same feature without a crisis. On the art side, it means an asset pipeline with agreed formats and naming — a project with three naming conventions is a project that will lose track of its own files. None of this is glamorous. All of it is the difference between shipping and not.

05 Storefront

Wishlisting and the storefront work

A store page is a production artefact, not a marketing afterthought. Screenshots, capsule art, a trailer, a short description that says what the game is in the first sentence — all of it takes time and all of it can be prepared while the game is still in development. Wishlisting on PC storefronts rewards an early, consistent presence more than a late burst. We plan storefront work into the schedule and revise the page as the game changes.

06 Support

Release, patches, and support after launch

A release is a milestone, not an ending. The weeks after launch are usually when the most useful bug reports arrive, and a project without a patch plan will struggle to respond. We plan for at least one post-release cycle from the start: a known-issues list, a build process that can produce a patch quickly, and a clear channel where players can report problems. If a game is going to have a public life, it needs someone able to answer it.

What we run

A build machine you can see the state of

Every project that reaches production runs through the same shape of pipeline. The rows below name what each stage produces — so a project's health can be read from its output rather than from a status meeting.

Build pipeline
Editor test build
Running now
week 41
Standalone player build, Windows
Passing
weekly
Standalone player build, Linux
Passing
weekly
Controller input regression set
Checked
nightly
Save-game round-trip test
Checked
nightly
Art asset validation
Checked
on commit
Localisation string parity
Checked
on commit

What we ship — three desktop targets

Target

Windows

Standalone builds and packaging for Windows are the default target on every PC release, because that is where the widest slice of players already are.

Target

macOS

A macOS target is planned in when it is likely, since signing and notarisation are easier to set up early than to retrofit onto a finished build.

Target

Linux

Linux builds are cheap to produce once the project is written without platform lock-in — worth pricing in from the start rather than adding later.

Studio reference

Where NEXORA's work sits in the Belgian scene

Belgium has small studios working on very different problems, and it helps to know which shape of project a studio is suited to before starting one. The three columns below show where the studio plays, which tools carry the work, and which marketplaces a project usually passes through.

Where the studio plays

  • RPG and systems-driven gamesCore
  • Strategy and card-game-adjacent workNeighbouring
  • PC-first releases, console when planned inDefault
  • Browser releases where the design fitsOptional

What carries the work

  • Godot for open-source, inspectable pipelinesEngine
  • Commercial engines when consoles are in scopeEngine
  • Version control with feature branchesProcess
  • Automated tests on quietly fragile systemsProcess

Where projects pass through

  • itch.io, for downloadable and browser buildsMarketplace
  • PC storefronts with wishlist pagesMarketplace
  • Browser-game platforms for web-first shapesMarketplace
  • Direct distribution for curated releasesDirect

Which shape of game fits which shape of studio

Belgium's ecosystem includes a strong strategy and systems segment; AAbrakam Entertainment in Angleur represents the strategy and card-game-adjacent end of it. Leuven-based CrazyGames operates one of the largest browser-game platforms globally and appears in Belgian industry directories as a major player. Those two examples pull in opposite directions — and both are real paths for a small studio.

Compare the engines we evaluate

Early access, browser, systems-heavy

Three extra questions worth asking before a release

Early access, browser platforms and systems-heavy design all change the shape of a project, and each one punishes a studio that chooses it without answering a clear question first. The rows below carry the question, the shape of game it fits, and the honest cost.

Early access

What decisions will player feedback inform?

Early access works when player feedback genuinely changes the game and the team can act on it. It does not work as a substitute for finishing a core loop, or as a way to fund a project that has not found its shape yet.

Verdict: answer first
Browser

Does the game survive the platform's constraints?

Not every project needs a download. Browser-game platforms reach players who will never install anything, and for certain game shapes a web release is the fastest path to a real audience. For others it is a poor fit, and the difference is usually the design itself — input, session length, and whether state can be kept small.

Verdict: design-dependent
Systems

Is there time budgeted for tuning after the loop works?

Simulation and systems-heavy games put weight on balance and readable state, which is different work from a linear action game. They also reward long-tail support, because a systems game tends to accumulate a community that keeps finding edge cases. We prototype these the same way, but budget more time for tuning once the core loop holds.

Verdict: budget the tune
Support

Does someone answer the game after launch?

Support after launch is part of the scope, not a favour. The weeks after release are when the most useful reports arrive, and a project without a patch plan will struggle to respond. At least one post-release cycle is planned from the start, with a known-issues list and a clear channel for players.

Verdict: always in scope

Next step

Starting a game project with NEXORA

A first conversation is usually enough to tell whether a project fits how we work: what the game is, which platforms it needs to reach, and whether the team is small enough that engine and process choices really matter. If it does, the next step is a written plan — engine, targets, prototype scope, and a first look at the store page. Reach the studio by email, or on the phone during working hours, and we can take it from there.

Reach the studio Desktop applications
Studio
Raveschoot 22, 9080 Lochristi, Belgium
Hours
Monday to Friday, 9:00 AM – 6:00 PM