One Pipeline

One core, every game

The problem

Every game had its own code base and did things its own way. A fix had to be made in every game, one at a time: ten games meant ten times the bugs and ten times the maintenance.

What I did

I built one core for every slot game to stand on. A game is now a thin layer: its symbols, its game modes, its words. Fix something in the core and every game has the fix.

The server used to send back outcome grids, and each game worked out for itself what to show. I moved the games to stages: a spin, a big win, a collection, a feature starting. I built each stage as one reusable piece of the core, so most games need no code of their own for how they play out. When one does, it overrides a single stage, in one place.

A change to the core is a change to games nobody is looking at, so I made every change take the gentlest form that works: an addition first, then a replacement with migration notes, and a switch only as a last resort, defaulting to the right behaviour. Existing games can be migrated. Games not yet written can't be reached by anything but the default.

No developer needed

The problem

Every layout tweak, every new asset and every round of feedback went through a developer. Designers waited on developers, developers waited on designers, and the same work was done twice.

What I did

I gave layout to the motion designers: they lay out the game in Spine. The screen's structure, where the reels sit and how the scene changes between modes, is a Spine file they own, so a layout change is theirs to make, and to animate.

I set a standard for everything, so designers know exactly how to build a file. Every symbol has the same seven animation states; a variant is a skin; a layout names every reel position. They hand over finished files, a developer drops them in, and they work first time.

I built the test harness so artists, animators, sound designers and copywriters can drag and drop their work straight into the running game and see it in place at once. They try ideas without waiting on a developer, or needing one at all.

Text as it was designed

The problem

Text designed in Photoshop lost its look in the game. PixiJS's own text styles are limited, so the effects didn't carry over. The usual way round that, pre-drawn graphical fonts, is heavy to download and full of its own problems, localisation first: every character of every language has to be drawn and shipped. So designers compromised, or developers rebuilt the effects by hand.

What I did

I built a Photoshop importer into the test harness. An artist opens the PSD in the browser, picks a text layer, and exports its whole style straight onto a text style in the game. A font the game doesn't have yet is fetched and added automatically, so what they see is the real result. Anything it can't carry over, it says so.

In the game, my custom shader renders the styles live rather than as pre-drawn fonts, so they stay light to download and work in every language. A text style editor I built shows every style the game uses and lets the artist tune it in place, then hands the changes to a developer as code.