Aleksandar Vrhovac, Head of Game Development at Avanti Studios, talks about the layered codebase and specialist team that let the company build brand-new live casino formats in weeks.
We get told quite often that our team is extremely efficient at developing new games and features. I wanted a second opinion on why, so I asked an AI tool to look at our code structure and explain it. Its short answer was that a new game means writing roughly 500 lines of certified math, about four phase classes, a defaults file, some UI made mostly from existing library parts, CSS and a few specs. RNG, networking, game flow, i18n, sound, feature flags, telemetry, the lobby, CI, simulation and deployment are all inherited.
I’ll admit I found that a bit unfair. There’s a lot of work behind those 500 lines and the summary makes it sound like there isn’t. It does nail the principle I keep repeating to our developers, though, which is KISS: keep it simple, stupid.
We split every game into four layers. Game Math makes sure outcomes are correct and validated. Game Flow makes sure the game follows the right sequence of actions for its rules. The Client UI lets the player interact with the game within those rules, and per-game styling is there to make it appealing and simple to use.
Those four are the only parts we develop for each title. Everything else a game needs to run – RNG, networking, localisation, the lobby, sound, device management, operator integration, simulation, building and deployment – comes from a modular architecture we designed around the needs of iGaming, and every game inherits it.
The layers also follow a shared ruleset. Internally we call these contracts. Game Math has to deliver its outcome in a data format that stays the same whatever the game design, because that’s what it has promised Game Flow. Game Flow runs on what we call Phases. Every one of our games uses the same set of phases, a bit like a state machine, and Game Flow has its own contract with the Client UI.
The UI is event-based. Each component listens to the data coming from Game Flow and reacts on its own, independently of the rest of the system. Our components are built to be reused, so in the worst case we extend the configuration of one we already have. Styling sits on a boilerplate that can be adjusted per component, with separate versions for desktop, mobile landscape and mobile portrait.
No responsibility in our code knows what’s happening outside it. It’s agnostic, and its only obligation is to serve the data it has promised. Human thinking tends to narrow to the problem in front of it anyway. Our structure lets a developer do exactly that, because they know nothing else will be affected as long as their part delivers the expected outcome.
The other reason we’re quick is people. It’s an obvious point, but no one really thinks about it. We hire people who don’t need to be told what to do. More often, they’re the ones telling me what we should do. That keeps them engaged, because the approach was their idea and they want it to succeed. Everyone knows that feeling of success. Most of us spend our lives chasing it.
Everyone on the team also specialises in at least one of the four layers, and they usually stick to it. We have two specialists in Game Math and Game Flow, two in Client UI and one in per-game styling. Think of a carpenter who has made thousands of tables. He’ll make the next one with more confidence, and faster.
Generalists have their place. They’re good at connecting things. But a team with too many of them doesn’t move efficiently, and speed is a big part of what we offer operators. When we say we can build a brand-new game format in a matter of weeks, this is how. The architecture means a developer only writes what’s new, and the person writing it has usually done that job many times before.
