Vitalii Lustin has spent more than a decade working on the client side of games and is now at SpinPlay Games. His focus: the slot core engine — modular architecture, draw call optimization, tools for animators, and an automated testing system that covers nearly all of the studio’s projects. In this interview, he breaks down how to achieve fast loading on low-end devices, the mistakes developers most often make when optimizing, and why AI is still limited to routine testing — not game logic.
— How is engine development for online slots different from standard frontend work or engines like Unity and Unreal?
— It’s still frontend, but with a twist. In typical web work, you build pages, UI, and server interactions. In slots, the client is essentially a mini-game: a set of classes and logic that everything else builds on. Unlike Unity, there’s no visual editor — we code everything line by line. That means the job leans heavily on OOP patterns and modular design, with far less reliance on visual tools and drag-and-drop workflows.
— When you started building a new core engine, what principles shaped your approach?
— My first engine was at Yggdrasil Gaming. From the start, we designed it to be as modular as possible. Features—say, a bonus game—were built as independent modules or repositories. Each could be tested on its own, then plugged into the game as a dependency. Features evolved separately, and changes to the engine didn’t risk breaking other projects.
The result was an engine where each game could extend or disable features as needed, while keeping development manageable for the team. It wasn’t revolutionary, but modularity became the foundation of our architecture and a principle that held up well over time.
— Fast loading is key in slots. How did you cut first load times?
— The goal was for players to see and launch the game as early as possible, even if not everything was loaded yet. First we load a minimal set—static images, the interface, the buttons. The player can spin right away, while high-resolution images and animations stream in the background. The visuals improve step by step, but the gameplay is instantly available. It’s very similar to LOD in 3D games, only we applied it to 2D graphics and animations.
— Optimization is a constant battle. How did you reduce draw calls?
— We combined several methods. Sprite atlases were crucial: if an animation pulled frames from multiple atlases, every switch added a draw call. Keeping frames in a single atlas reduced that to one. Filters and layers were another factor with effects like blur or glow split rendering and increased calls. Text also played a role: fonts generated at runtime added calls, so we used bitmap fonts where all characters are pre-packed in an atlas.
In practice, we tracked draw calls per animation and aimed for about two calls per symbol animation. More than that and older iPhones would stutter. Working closely with animators, reorganizing atlases, and reducing filters in the right spots made performance far more stable across devices.
— How did you approach testing and automation?
— We built a separate app—a test runner. It launched the game in parallel in 10–20 windows, performed basic actions like loading the game, checking console errors, pressing “spin,” waiting for results, and validating balance changes. It also took screenshots and compared them with reference images; if they didn’t match, it generated an error and automatically created a task in the tracker.
This setup covered the standard scenarios and caught regressions quickly. Before, we had five manual testers working on the core engine. After implementing the system, one tester was enough to supervise the automation and handle edge cases. On my resume, I note that automated tests now cover about 80% of games—that’s the result of automating typical scenarios and routine checks.
— What other internal tools shaped the workflow?
— We built a tool for animators and tech artists that tracked draw calls per animation. It broke down the cost frame by frame, so we could pinpoint hotspots with the animator and optimize exactly where needed. Thanks to that, teams iterated faster, collaboration improved, and unexpected lags on weaker devices happened much less often.
— You also experimented with AI in your workflow. Where did it help?
— For me, AI was useful in routine work. I used models to generate test-case templates and speed up UI tasks. With a prompt, the model could suggest test code like “click the button, wait for the API, check the result.” That saved time on simple tests and basic scenarios. But when it came to slot-specific logic—like win calculations or complex animations—AI wasn’t helpful because it lacked context. In short: it’s useful for standard tasks (UI, basic tests) but not effective where deep knowledge of the game engine is required.
— What common mistakes have you seen when developers try to optimize games?
— The biggest is not understanding how the renderer works, and not structuring assets properly. Many optimize without measuring—no profiling, just random tweaks. That often leads to extra draw calls or lag.
Another mistake is using system fonts instead of bitmap fonts, which adds unnecessary calls. In general, superficial optimization without checking metrics rarely works. The right process is always: measure, profile, then fix. Automated tests are just as critical—without them, a single engine bug can easily spread across every game in the portfolio.
— What advice would you give someone who wants to get into slot development and eventually engine work?
— Start with a strong grasp of OOP and design patterns. Slot clients rely heavily on classes and templates, so good architecture is essential. Then study rendering engines like Pixi or Phaser—learn how they render, how atlases are built, how filters work. Their documentation, paired with solid OOP books, forms a strong foundation. Then practice: analyze existing games, profile them, and try optimizing small projects. AI tools can speed things up, but they only complement real fundamentals.
— How have slots evolved in recent years? What trends stand out?
— They’ve become much more visual: richer animations, pseudo-3D effects, and polished transitions. Games are edging closer to mobile titles in look and feel. Where graphics used to be basic, now many use complex Spine animations and transitions that make the product feel interactive and game-like—not just reels spinning. That’s the pattern: simple 2D at first, then more effects and polish as the genre matures. But this growth requires tight optimization and more advanced tools to keep games running smoothly across a wide range of devices.
