From Browser Games to Slot Engines: How Vitalii Lustin Builds Scalable Client Architecture

For more than a decade, Vitalii Lustin has worked on the client side of game development — evolving from crafting small browser-based mini-games to building the complex engines that power modern online slots. Today, at SpinPlay Games, he oversees client engine architecture, performance optimization, and automated testing. In this interview, Vitalii looks back on how his approach to development has matured, why modular architecture has become essential in slot production, and why neural networks, despite all the hype, still serve best as practical assistants — not as architects of gameplay logic.

From Early Games to System Thinking

Vitalii began his career developing browser-based mini-games and integrating them into social platforms. These were small, agile projects — one or two developers handling everything from interface and logic to animation and server connections.

Because the games ran directly in the browser, optimization was key.
“Every extra operation, every inefficient effect affected performance. It was a great school: you could immediately see where you overloaded the client and why the game started lagging,” recalls Vitalii.

Those formative years taught him to think systemically — to understand how content loading, interface synchronization, and rendering all interact under the strict constraints of a browser environment.

Small Teams in Big Studios

As his career developed, Vitalii joined major international studios — first Yggdrasil, later SpinPlay Games. Despite the larger organizational structures, the essence of teamwork remained unchanged: a small, cross-functional group working closely on a single game.

A typical team included one or two client developers, a server developer, artists, an animator, and testers — a setup that allowed full ownership over each title. In bigger studios, though, the focus shifted toward long-term scalability: ensuring that mechanics and systems could be reused across many projects without modification.

Vitalii eventually became part of the core architecture team, responsible for maintaining and improving shared components. “When the same mechanic is used in dozens of projects, it has to be built consistently every time,” he says. “That saves time and reduces the risk of errors when releasing new games.”

Architecture Through Modularity

At Yggdrasil, Vitalii contributed to the development of the company’s core engine — the central framework that powered all subsequent games. The guiding principle behind that work was modularity.

“The idea was that individual features — for example, a bonus game — would exist as independent modules or repositories. Each could be built and tested autonomously, then connected to the game as a dependency. This approach allows teams to evolve features separately and reduces the risk of breaking other projects when changes are made to the engine.”

This modular design not only encouraged cleaner code but also allowed multiple teams to work in parallel. It created a structure where innovation could happen faster, and testing could be done in isolation — both critical advantages in a production pipeline where deadlines are tight and reliability is everything.

Fast Loading: Reducing Time to First Click

In the world of slot development, few things are more important than startup speed. Players expect to jump into gameplay instantly, not wait for assets to load. To meet that expectation, Vitalii’s team focused on progressive asset loading — a method that prioritizes responsiveness over raw visual fidelity.
At launch, only the minimum set of assets — interface elements and static visuals — was loaded. This allowed players to start spinning right away, while other components such as animations and high-resolution textures were streamed in gradually based on connection speed and system resources.
“The visual quality improves gradually, but the gameplay is available right away. It’s similar to the LOD principle in 3D games, but we applied it to 2D graphics and animations. For players, it looked natural, and for the team, it helped maintain the balance between performance and visual quality,” Vitalii explains. The result was a smoother, more engaging entry into gameplay — and a better balance between technical efficiency and player experience.

Optimization and Draw-Call Control

Optimization in slot development is never a one-time effort. It’s an ongoing discipline that spans the entire development cycle and requires careful measurement and iteration. One of the key performance indicators Vitalii’s team tracked was draw calls — the number of rendering operations required to display a scene.

To minimize overhead, animation frames were combined into a single atlas, avoiding the extra load that comes from switching textures. Filters such as blur or glow were used sparingly, since each required additional rendering passes. For text, the team relied on bitmap fonts — with every character pre-rendered into an atlas to prevent runtime texture generation.

To make this process transparent, they built an internal tool that visualized performance metrics in real time. Working with the animator, they could see where frames were dropping and optimize the scenes on the fly. This hands-on, data-driven approach not only boosted the performance of new titles but also allowed the team to quickly diagnose and fix issues in already released games — something that can save weeks of troubleshooting time.

Automated Testing and Internal Automation

As projects grew in complexity, testing became a major area for improvement. Vitalii’s team designed its own autotest runner — a tool that could automatically launch multiple instances of a game, execute pre-defined actions, and compare the outcomes to expected results.

“The script launched the game in dozens of windows simultaneously, performed basic actions — loaded the game, checked for console errors, pressed Spin, waited for the result, and compared balance changes (how much was deducted and how much was credited). The system also took screenshots and compared them to reference images; if they didn’t match, it generated an error and automatically created a task in the tracker for review. This approach helped cover standard scenarios and quickly detect regressions. As a result, where five manual testers used to work on the core engine, only one engineer remained after implementation — managing the tests and handling cases that required manual refinement,” says Vitalii.

The automation system dramatically improved efficiency. Tasks that once required a team of five manual testers could now be handled by a single engineer managing the tests. Overall coverage for standard scenarios rose to roughly 80%, cutting regression time and freeing up resources for creative and analytical work.

AI as a Tool, Not a Solution

As neural networks began making their way into software workflows, Vitalii started using them for routine automation — generating test-case templates and streamlining UI test setups. By feeding a short prompt, the model could produce structured test steps such as “click button,” “wait for API response,” and “verify output.”

The technology proved handy for repetitive tasks, but Vitalii remains cautious about its broader application in game development.
“They can suggest a code structure, but they don’t understand why it’s built that way,” he says.

For him, AI remains an auxiliary tool — something that speeds up workflows but doesn’t replace engineering logic, creative judgment, or the systemic thinking required to build games that actually work and feel right to players.