Inspiration
Fly High Runners started with a simple question: what if a delivery job in a cyberpunk city was already dangerous enough, but then you gave every courier a jetpack and encouraged them to sabotage each other?
The result is a multiplayer arcade game where players become questionably equipped couriers racing through a neon city, managing fuel and inventory while trying to complete their deliveries before everyone else.
And because simply winning the race would apparently be too civilized, players can collect power-ups, fire EMPs at their rivals, and potentially send another courier crashing straight into a police drone.
Fly High Runners was already an active project before Ship-a-ton. For the hackathon, we focused on taking another important step toward making it a sustainable, releasable game: integrating monetization and revenue analytics without disrupting the multiplayer experience.
What it does
Fly High Runners is a competitive multiplayer flying game for up to six players.
Players race through a cyberpunk city as jetpack couriers transporting contraband between destinations. Flying is intentionally a little unruly: maintaining control, managing fuel, choosing routes, and recovering from mistakes are all part of the game.
Meanwhile, other players are dealing with exactly the same problems—and trying to make yours worse.
Players can:
- Race against up to five other couriers.
- Pick up and deliver cargo around the city.
- Manage limited fuel and inventory.
- Collect power-ups while flying.
- EMP rival players.
- Knock competitors into hazards and police drones.
- Compete across a shared real-time multiplayer world.
The goal is an arcade multiplayer experience that's quick to understand but gives players plenty of opportunities for skill, chaos, and rivalry.
How we built it
Fly High Runners is built in Unity.
The original foundation of the game was created primarily with PlayMaker, the visual scripting system from Hutong Games. PlayMaker was used heavily for gameplay logic, player flow, UI behavior, state management, and rapid iteration while the project was taking shape.
As the game grew in complexity, we expanded the project with C# systems for areas that benefited from more direct control, reusable architecture, SDK integrations, platform-specific functionality, and networking support.
Today, Fly High Runners uses a hybrid approach: PlayMaker for much of the game's state-driven gameplay logic, alongside C# for more specialized and systems-level functionality.
Real-time multiplayer is powered by Photon Fusion, which handles player sessions, networking, synchronization, and the shared game world. We have also built custom integrations that allow our PlayMaker-driven gameplay systems to communicate with Fusion while keeping the visual scripting workflow that the project was originally built around.
For Ship-a-ton, that same hybrid architecture was extended again to integrate Unity LevelPlay and RevenueCat Ads, allowing monetization and ad revenue tracking to fit into the game's existing PlayMaker-driven flow without requiring us to rewrite the underlying game.
The project is being prepared for multiple platforms, including mobile, which has required additional work around build size, texture memory, performance, platform services, multiplayer connectivity, and monetization.
What we added for Ship-a-ton
One of our major goals during Ship-a-ton was to build monetization into Fly High Runners in a way that actually fits the game.
We didn't want ads interrupting a race or appearing in the middle of multiplayer gameplay.
Instead, we designed the ad flow around a natural transition point: before the player connects to the Photon Fusion multiplayer session.
That makes the monetization event part of the transition into gameplay rather than something that can interrupt an active match.
RevenueCat Ads
For Ship-a-ton, we integrated RevenueCat Ads into the Unity project so advertising revenue can become part of the same revenue picture as the rest of the game's monetization.
Our Unity integration reports ad lifecycle and revenue information through RevenueCat's ad tracking support while our advertising provider continues to handle delivery and mediation.
This required more than simply showing an advertisement. We had to make sure the advertising lifecycle, multiplayer connection lifecycle, and RevenueCat tracking could coexist without creating conflicting ownership of the flow.
Unity LevelPlay
We integrated Unity LevelPlay to handle our interstitial advertising layer.
The system includes:
- Interstitial loading and availability handling.
- Platform-specific Android and iOS configuration.
- Advertisement lifecycle callbacks.
- A controlled transition back into the game's existing flow after an ad closes or fails.
- Test and production configuration work across our mobile builds.
- Revenue and impression information being passed into RevenueCat's advertising analytics integration.
One particularly important design rule is that the game does not connect the player to Photon Fusion and then show an advertisement.
The advertisement happens first.
Once it has finished—or if no advertisement is available—the existing multiplayer connection process continues.
That separation prevents an advertisement from unnecessarily consuming time inside an active multiplayer connection.
Challenges we ran into
Ads and multiplayer don't naturally get along
An interstitial advertisement can take over the screen for a surprisingly long time.
That's annoying in a normal application.
In a real-time multiplayer game, it can be considerably worse.
If a player connects to a multiplayer session and then spends a long period inside an advertisement, the game can experience connection, timeout, background execution, or lifecycle problems.
We changed our flow so the advertisement occurs before joining the network session, keeping the two systems separated as much as possible.
Mobile advertising has a lot of moving pieces
Getting an ad to appear is only one part of the integration.
We had to work through:
- Android and iOS configuration.
- Advertising network setup.
- LevelPlay configuration.
- iOS application settings.
- Test versus live advertisements.
- Mediation behavior.
- Advertisement duration and quality.
- SDK initialization.
- Device-specific testing.
- Revenue reporting.
We also discovered firsthand that a technically successful advertisement isn't necessarily a good advertisement.
Some creatives being served were dramatically longer than we expected, so we've also been investigating ad quality and network configuration to find a balance between monetization and player experience.
Optimizing a real game instead of a hackathon prototype
Fly High Runners is already a substantial Unity project.
That means every new system has to work inside a real production environment instead of an isolated demo.
During this period we've also been optimizing the mobile version of the game, particularly its textures and memory footprint.
Our build analysis showed that textures represented the overwhelming majority of our asset footprint, so we've been testing different texture sizes and ASTC compression settings across Android and iOS to significantly improve mobile performance without destroying the visual identity of the city.
Accomplishments we're proud of
We're particularly happy that the Ship-a-ton work became part of the actual architecture of Fly High Runners rather than a separate hackathon demonstration.
We now have:
- A functioning mobile interstitial advertising flow.
- Unity LevelPlay integrated into the game's startup/game-entry sequence.
- RevenueCat advertising tracking integrated into the Unity project.
- Advertising deliberately separated from active Photon Fusion gameplay.
- Android and iOS advertising configurations.
- Real-device and TestFlight testing.
- A much better understanding of advertisement quality, mediation, and player experience.
- Continued mobile optimization work aimed at making the full game practical on a wider range of devices.
Most importantly, we were able to add a revenue system without fundamentally changing what Fly High Runners is.
It's still a game about flying recklessly through a cyberpunk city and ruining your friends' delivery routes.
Now we're also building the infrastructure needed to actually ship it.
What we learned
One of the biggest lessons from this work is that monetization design and game design can't really be separated.
The easiest place to display an advertisement isn't necessarily the right place.
For a multiplayer game, deciding when an advertisement happens can be just as important as deciding which advertising SDK to use.
We also learned much more about how ad mediation, individual ad networks, RevenueCat analytics, mobile platform requirements, and Unity application lifecycle events fit together.
Revenue information becomes much more useful when it isn't trapped inside one advertising dashboard. Connecting advertising performance to RevenueCat gives us a foundation for understanding monetization as part of the overall product rather than treating ads as an isolated system.
What's next
Our immediate goal is continuing to move Fly High Runners toward release.
That includes:
- Refining the mobile advertising experience.
- Monitoring ad quality and avoiding excessively disruptive creatives.
- Continuing Android and iOS performance optimization.
- Expanding device testing.
- Finishing platform-specific services and release requirements.
- Continuing multiplayer testing and polish.
- Using RevenueCat data to better understand how monetization performs once real players begin playing.
Longer term, we want Fly High Runners to grow without sacrificing the thing that made us want to build it in the first place:
Get a package. Strap on a jetpack. Try not to explode. Make sure your friends explode first.
Log in or sign up for Devpost to join the conversation.