From Game Dev to Native ── The Upside of Mixed Backgrounds
Hello there!
I’m Davide from the AnotherBall Mobile Team. At AnotherBall, many client engineers (myself included) had years of experience in the video game industry before joining the native client team.
Today I want to talk about what a team with mixed backgrounds brings to the table — the friction, the upsides, and how AI can help smooth things out.
Different problems to solve
At a fundamental level, engineers are people who love solving problems. But when you put many engineers together, people naturally gravitate toward the problems they care about most.
This is especially true when engineers come from different backgrounds, such as game development. Games and mobile apps may both run on the same device, but they tend to pull engineers in different directions:
- Traditionally, games are about creating an experience, while apps are about completing tasks efficiently.
- Many games — especially story-driven or competitive ones — are designed to hold your full attention; most apps live alongside notifications, backgrounding, deep links, and interruptions.
- Classic console and PC titles ship once or in big drops; mobile apps — and live-service games — ship continuously.
The lines blur in practice, but at a glance there are still a lot of differences!
Avvy is a hybrid
We are building Avvy, a mobile application that lets anyone become a VTuber in one minute. As described in a previous post, this application sits at the seam between a game and a community app. That means users expect the polished experience of a social network, alongside the engagement and performance of a game.
Building something that lives on both sides means we can’t pick one mindset and stick with it. The streaming experience needs to feel as alive as a game; the rest of the app needs to feel as familiar as any other social product. Neither half can be ignored.
The upside of mixed backgrounds
Mixed backgrounds bring different instincts to the same problem. A game developer and a mobile engineer can look at the same screen and notice completely different things — and on a hybrid product like Avvy, that’s exactly what we want.
A good example is the pipeline behind Avvy’s real-time face tracking — the cornerstone of the Avvy experience. The device camera captures your facial motion in real time and feeds it to Unity, which animates the avatar. Since the camera and Unity live in two different frameworks, communication between them can be slow; but for the avatar to feel alive, data has to reach Unity at a steady 60 frames per second.
On Android, the standard native-to-Unity bridge cost 3 ms per frame — nearly 20% of the 16.6 ms frame budget, enough to break the illusion. Coming from a game development background, my instinct was to reach for memory-mapped files on Android and raw pointers on iOS. The results were solid:
| Strategy | iOS | Android |
|---|---|---|
| Parameters (PInvoke / AndroidJavaProxy) | 0.01 ms | 3 ms |
| Memory-mapped files | 0.007 ms | 0.11 ms |
| Direct pointer access | 0.001 ms | not supported |
By the way, this pipeline really deserves its own post — we'll write one!
AI bridges the gap
What makes this work today, more than it would have a few years ago, is AI. Crossing from games to native used to mean a steep ramp: new languages, new frameworks, new conventions. But AI lets you focus on architecture and best practices while it handles the mechanical translation.
For example, when we were implementing Avvy’s in-stream points system, we had a clear idea in mind: a number that rolls like an odometer and squashes-and-stretches in response to server events. This is the prompt I gave Claude Code:
Animate a Text to get an odometer effect using the Disney 12 principles of animation (squash and stretch).
That vocabulary is the bread and butter of game development — and Disney’s 12 principles of animation (the classic rules of motion that include squash-and-stretch, anticipation, follow-through, and a few others) are something game developers are familiar with.
Claude Code translated it into SwiftUI in basically one shot. The squash-and-stretch came out as a bottom-anchored vertical scale, animated with a bouncy spring:
1 | Text(String(character)) |
The odometer feel came from sequencing each character with a small stagger, so digits pop in one after another:
1 | let delay = Double(index) * staggerDelay |
A couple of hours of polish and parameter tuning later, the animation was ready. Without AI, I’d have likely spent the better part of a day on SwiftUI animation docs first.
Conclusion
Different backgrounds create unique dynamics in a team, but ultimately they let the team cover more ground, especially on a product like Avvy. And in practice, AI is not a replacement for what each of us brings — it acts as a multiplier, and lets us move across domains with less friction. What’s left is the part AI can’t do for you: human taste, judgment, attention to detail, and the willingness to ask why something feels wrong.
For me personally, the move from games to native came down to two things: I wanted to ship more often and iterate with real users — something that’s hard to do in games, where years long release cycles are not uncommon — and I wanted a new challenge (though I still love making games!). What surprised me is how much carried over: solid principles tend to matter more than the specifics of any one stack, and when used with care, AI is able to fill the gaps. If you’ve been on the fence about broadening your experience, now is probably a great time to do it.
We’re Hiring
AnotherBall is looking for client engineers interested in app development using Swift, Kotlin, Unity, and AI. We believe that, besides technical skills, attention to detail, a curious mind, and strong ownership are becoming increasingly important skills for engineers in the age of AI. If that resonates with you, let’s have a chat!