How Super Bear Adventure Reached 200M Downloads and Added Multiplayer at Scale with Photon

In 2016, a 17-year-old computer science student, Stéphane Hulot, started building a small 3D platformer in Unity. It had placeholder assets, a single level, no monetization, and zero expectations of commercial success. Ten years later, Super Bear Adventure has surpassed 200 million downloads, reaches over 100,000 new players every day, and supports cross-platform multiplayer across mobile and Nintendo Switch. Supported by yours truly, Photon Engine.

This isn’t a story about a perfectly planned startup strategy or a heavily funded studio. It’s the journey of a solo developer who learned by doing, rewriting messy early code, scaling infrastructure without paid marketing, building a studio and eventually transforming a successful single-player mobile game into a fully networked multiplayer experience.

Earthkwak Games’ path from experimentation to becoming a full development team offers a rare look at what happens when persistence, technical growth, and the right tools intersect at the right time.

Key Takeaways

Start simple. Improve constantly.
The early code wasn’t clean but steady refactoring, better architecture, and experience transformed it into a scalable foundation.

Organic growth can change everything overnight.
A hobby project became a global hit without marketing spend, driven purely by player demand.

Adding multiplayer later is hard, but possible.
Retrofitting networking required major rewrites, especially the player controller, but incremental integration made it achievable.

Flexibility beats rigidity.
Choosing a networking solution that worked with the existing codebase avoided a full reboot of the project.

Deterministic systems make networking manageable.
State machines and input-based replication were key to smooth synchronization.

Multiplayer boosted both engagement and revenue.
Even with most playtime still single-player, social features doubled monthly revenue and strengthened retention.

Managed infrastructure reduces risk.
Using a cloud solution removed backend stress and let the team focus on gameplay instead of server maintenance.

Stéphane, Super Bear Adventure started development back in 2016 when you were around 17 years old. Looking back at those early prototypes using placeholder assets and ‘Liberation Sans’ fonts, did you ever anticipate the project would scale to over 100 million downloads, and how did that massive growth impact your technical mindset as a solo developer? 

I began using Unity at 13 years old just to play around and try things out. I published a few small scope games for fun when I was in high school (they are now lost to time). I even worked on a small scope multiplayer PC game for fun using the old PUN. I was particularly interested in mobile because it’s so accessible: everyone has a phone and games are often free. When I started higher education in computer science, I began working on SBA as a small project just for fun. On release, it was a bare-bones game with a single level, and no monetization whatsoever (free to play, no ads, no microtransactions). I’m mostly interested in programming, but I still made all 3D models, textures, UI and sound effects myself. The only thing I never touched was composing music.

When I was 18, it started gaining some traction (around 1000 downloads a week) so instead of switching to another project, I continued adding content. I eventually added some ads very sparsely because I did not want it to be another cash grab mobile game. It provided me with a small revenue, so I was able to pay for some stuff while I was a student. When covid broke and lockdown was declared, the game blew up out of nowhere overnight and started getting tens of thousands of downloads per day. I doubled down on it and added more content and paid cosmetic features while finishing engineering school.

I gained experience over time and began to make the code cleaner, the assets better looking and organizing development in a more professional way. Now in 2026 I have hired a team of developers, we have over 100k downloads per day and over 200M downloads total. I never paid for any marketing, the game was good enough for the snowball effect to be massive. This kind of story is extremely rare, and I consider myself a game dev lottery winner lol.

The game is heavily inspired by late 90s platformers like Banjo-Kazooie and Super Mario 64, relying on specific movement mechanics like belly stomps, long jumps, and ledge grabs. When you initially built these character controllers in Unity, were they architected with network replication in mind or did you have to refactor the core movement logic later on?

I never heard about Banjo-Kazzoie before releasing SBA. Believe it or not, the character being a bear with a bird on his back is purely a coincidence. My inspiration was Mario 64, a game I fell in love with at a young age. There was no good 3D platformer with semi-open levels on mobile, so I decided to create one to fill that gap.

The game was only ever designed for singleplayer, because I never thought multiplayer was needed. The code was very poorly written because I didn’t know better when I started. The character controller was just polling the inputs every frame and move in the physics step with no fancy architecture.

We initially tried FishNet and Photon Fusion, but the client/server architecture was just too incompatible with the existing code, so we turned to PUN2. While it’s legacy tech with a less robust architecture, it allowed us to add networking to features one by one without rebooting the entire project. First thing I did was rewrite the player controller: it now uses a state machine instead of a 2000+ lines monstrous class, I moved the input logic to a separate set of classes that could be replicated, and I made sure movement was deterministic based on a sequence of inputs. The state machine also allowed for easy implementation of reconciliation.

For a long time, the game was a purely single-player sandbox experience. What was the tipping point that made you decide to tackle the ‘Multiplayer Update’ (Update 12.0)? Was it community demand, or did you feel the game mechanics, like the vehicles and open-world exploration, were specifically missing a co-op element?

After I hired my first employee in 2024, we began discussing adding multiplayer. It was a long-requested feature that I always refused to do because it would mean rewriting most of the game code and redesigning quite a lot of features that were created with a single player character in mind (like triggering cutscenes and boss fights). This specific update ended up taking a year and a half to complete, due to the sheer size of the existing code that needed a rewrite as well as a plethora of other features the rest of the team added.

Currently, some areas are inaccessible in multiplayer because their design simply doesn’t work with multiple players. We plan on changing those areas, so the entire game will be playable in multiplayer.

Transitioning a live, successful single-player game to multiplayer is often harder than starting from scratch. When you began looking for a networking solution, what were your non-negotiables? Were you looking specifically for a state-synchronization engine to handle the complex physics of the vehicles and player movement?

I can confirm that it’s harder! If we started from scratch, we could have built around an existing networking solution, but we had to find a solution that could work around our codebase. That’s why PUN2 felt perfect to us. PUN doesn’t have a strongly enforced client/server architecture. It’s more simple: after matchmaking and connection, it mostly is just RPCs. We can build a strong authoritative host player architecture if we want, or share the authority with trusted players like we did. Building around serialized views, we were able to deeply optimize the bandwidth instead of relying on suits-all components for synchronization.

The player controller was the biggest challenge, and we opted for a clean replication/reconciliation approach even though it’s not enforced by PUN2. Other features that did not require such precision were implemented with RPCs with no major overhaul of the code. I love that flexibility.

We decided to go for a shared authority architecture and no dedicated server. The game is free and doesn’t have aggressive monetization like most mobile games, so our income per player is very low. Additionally, our playerbase was already massive. PUN2 allowed us to keep bandwidth and relay server costs to a minimal.

In Update 12.0, you introduced complex shared interactions, not just player movement, but passenger-capable vehicles, a voting system for level selection, and synchronized environmental states. How did you leverage the networking engine to handle the state authority in these scenarios? Did you encounter challenges with prediction or lag compensation on vehicle physics?

Working on mobile without a server added another layer of complexity: The host client can become unresponsive at any time during interactive ads or if they switched to another app for a short duration. Thanks to master client switching with Photon, the game can continue if the host leaves, but we don’t want to freeze the game for all players while waiting for a timeout. We set up a system of “first reachable controller” where the player with the lowest ping can have authority if the actual host hasn’t sent a message in over a second. Of course this presents us with a security issue, since any player can act on any non-player controller, but since multiplayer mode was designed to play with friends (using invite codes) and with no random room matchmaking, we assumed this wouldn’t be an issue (and so far it is not). PUN2 code does not come pre-compiled and is readable C# so we were able to add a few subtle changes ourselves to implement this. In general, the shared authority was really useful for us because the game can still feel smooth on unstable mobile connections.

As for the vehicle physics, we’re reusing the inputs the driver player is sending with the same reconciliation/replication approach as the players. When no one is driving, the last driver has authority. Movement is still jittery for passengers, but we’re working on smoothing this in future updates.

Super Bear Adventure supports cross-play between Android, iOS, and Nintendo Switch. Mobile devices and consoles often have different floating-point behaviors and performance constraints. How did the networking stack help you bridge these hardware gaps to ensure that a Switch player sees the exact same projectile trajectory or boss animation as an Android player?

We did not notice any discrepancy between platforms. Unity seems to handle really well floating point and processing differences, so the outcome is the same regardless of hardware. In terms of code, cross-platform was really seamless to implement with PUN2. Photon’s team also helped us with Nintendo Switch approval.

Beyond standard co-op, you recently added competitive modes like ‘Prop Hunt’ and ‘Infection’ (Chase Tag) in Update 12.1.0. These require precise hit detection and rapid state changes. From a coding perspective, how difficult was it to layer these custom game rules over your existing networking foundation?

Because of the friends-only multiplayer mode, we’re trusting the players. There’s no precise hit detection and the system is actually quite flawed, but we think it’s good enough to not impact the gameplay negatively.

With a player base in the hundreds of millions, launch day for the multiplayer update must have been intense. How did the backend hold up regarding room management and matchmaking? Did using a managed cloud solution alleviate the stress of server operations, allowing you to focus on gameplay bugs rather than infrastructure?

Photon cloud saved us on this one! Launch day was stress-free, we were very excited to see veteran players play together for the first time, and we played with our players by sending invite codes. We had a few bugs we discovered on launch, but nothing too massive.

The relay server continues to run without us having to worry about anything. It just works. Photon has by far the most responsive and ready to help support team I’ve ever worked with.

You’ve added lobby emotes, group interactions like rock-paper-scissors, and social spaces like the DJ Pierre set. Have you noticed a shift in session times or player retention since integrating these real-time social layers? How has the ability to ‘hang out’ changed the game’s ecosystem?

Adding multiplayer more than doubled our monthly revenue. We were worried that the cost of the relay and matchmaking services would be too much, and we would see little to no return on investment, but it ended up being the best decision we ever took. Even though the vast majority of playtime still happens in single-player, the idea of showing off your progress and unlocked cosmetics is a strong motivation engine to keep players engaged, even when not playing online.

Many indie developers are intimidated by the prospect of adding multiplayer to their physics-based games. Based on your experience migrating Super Bear Adventure, what technical advice would you give to a dev currently staring at their single-player code, wondering which networking stack to choose to avoid rewriting their entire game?

If you have technical experience, even if not related to networking, I would suggest going for a low level engine integration with flexible architecture. Having control of what we do gameplay wise while not worrying about matchmaking and how packets are actually being sent was perfect for us. Modern networking solutions are way cleaner and robust, but require you to adapt to their architecture. 

Don’t try to have a separate gameplay logic for multiplayer and singleplayer, use offline mode. We tried keeping multiplayer its own thing to keep things clean, but it ended up being too much abstraction and complexity for the simplest features. We lost so much time because of this. We fixed it by making singleplayer an offline room with one connected player. It makes everything so much cleaner. Networking code like RPCs and state synchronization is just reused with minimal overhead.

Conclusion

What makes Super Bear Adventure remarkable isn’t just its scale, it’s the arc behind it. A teenager experimenting with Unity gradually became a developer capable of refactoring complex systems, leading a team, and shipping cross-platform multiplayer to millions of players without losing the spirit of the original game.

The technical lesson is clear: architecture decisions echo for years. Clean separation of input, deterministic systems, and flexible networking integration can mean the difference between an impossible rewrite and a survivable evolution.

The business lesson is just as powerful: multiplayer isn’t merely a feature. It’s a catalyst. It deepens engagement, strengthens community identity, and can transform the economics of a game when implemented thoughtfully.

Stéphane summarizes the experience succinctly:

“Photon allowed us to focus on the gameplay and synchronization, without getting into the complexity of packet transfer, session management, and hosting. Adding multiplayer to our game was the best financial decision we ever took.”

From placeholder fonts to hundreds of millions of downloads, Super Bear Adventure stands as proof that technical growth, persistence, and smart infrastructure choices can turn a student project into a global phenomenon.