Engineering 2 July 2026 · 1 min read

One engine, eight titles: what standardising actually bought us

Shared RGS, shared certification stack, shared maths harness. The pitch is faster integration — but the bigger return turned out to be somewhere else entirely.

The catalogue runs on one engine. Every title shares an RGS, a certification stack and a maths harness, and the usual reason given for that is integration speed — one technical conversation with an operator covers the whole roster instead of eight.

That is true, and it is not the main benefit.

The compounding part

The return that actually compounds is that a fix lands everywhere at once. A rendering bug found in one title's bonus round is a bug fixed across the catalogue in the same release. A certification finding raised against one submission becomes a change the next seven inherit before they are ever submitted.

Studios that build each title on its own stack pay that cost eight times, usually at the worst moment — after launch, under a live incident, in code nobody has read for a year.

Where it constrains us

Standardising is not free. A shared engine makes the unusual title genuinely harder: anything that wants a mechanic the harness does not model is a change to the harness, reviewed against every existing title, rather than a local decision. That is the right trade for a catalogue this size, and it would be the wrong trade for a studio shipping one experimental title a year.

  1. New mechanics are modelled in the harness before they are built.
  2. Every title re-runs the full maths suite on every engine release.
  3. Certification artefacts are generated from the harness, not written per title.

The result an operator sees is narrower than the internal benefit: predictable submissions, and a roster where the eighth integration costs roughly what the second did.

The full catalog,
one integration.

Direct via STUDIO:P RGS, or through GLI-compliant aggregator partners. Eight games today, four more in 2027.