Vaporwave Skateboarding

Overview

Vaporwave Skateboarding is a vaporwave-inspired endless runner for Android and iOS, commissioned by Star Computer Labs. I worked on this contract for roughly 2,000 hours, alongside designers, music producers, QA, and marketing specialists. The game shipped and is still live on both the App Store and Google Play today.

As the primary programmer on the project, my responsibilities covered the full Blueprint and C++ communication architecture, the master shader driving the game's vaporwave visual identity, store economy and progression, character customization, cloud save, audio visualization, the platform and backend layer, and the core endless runner loop itself. I also authored the modular tile pieces the generator assembles, along with the props that dress them.

Store Economy

The store had to absorb new content after launch without structural rewrites, so it was built data-driven from the start. It supported real-money IAP, with purchase logic, state management, and UI feedback all living in Blueprint for faster iterations by a designer.

Character Customization

New character configurations needed to be addable by the team without requiring code changes each time. The customization system was built data-driven from the start, so adding a new character or swappable part was a content task rather than a programming one.

Audio Visualization

The brief called for visuals that reacted to the music. The question was whether they should react to gameplay events or to the audio itself. Tying them to gameplay events would have been simpler but would have broken the connection to the music. The system uses frequency modulation to filter the active background track into distinct frequency bands, then drives object scale transforms from those values in real time. Different elements respond to different frequency ranges rather than just reacting to overall volume, which is what gives the aesthetic its musical connection.

The clip below shows the system running in game, with in-world objects scaling in real time to the active background track across different frequency bands.

Cloud Save

Cloud save turned out to be more nuanced than expected. I built the save and load flow as a REST round-trip between the game client and a server, keyed on a per-player account ID. That account identity comes from the platform login, and because iOS and Android use completely different login and identifier systems, a single unified cross-platform save was not feasible. Save data persists per platform, and switching devices works as long as the operating system and account stay the same. Getting both integrations stable took a few weeks, mostly because the authentication flows and edge cases around account state at launch differed more than anticipated.

The subtler problem is write safety. Several separate places in the game can build and send a cloud payload, and any one of them firing before the player's data has finished loading would write a blank or partial save over a real one. Every path funnels through a single write function, and the guard lives there rather than at each site.

Procedural Level Generation

An endless runner needs variety to stay engaging across sessions, but manually designing infinite level layouts is not realistic. The tile generation system was built to handle this procedurally, integrated with scoring and difficulty progression to keep the challenge scaling alongside the content variety.

The clip below shows the tile system generating level segments procedurally at runtime, with difficulty and obstacle density scaling alongside the player's score.

Platform & Backend Layer

Everything that earns money or touches player data sits behind a first-party C++ layer: in-app purchases, ads and the consent flow, cloud save, authentication, and platform game services. Each module is written against the platform vendor's own API: native store billing on each platform, Unreal's Online Subsystem for achievements and leaderboards, and the ad and consent SDKs directly.

Technical Approach

All gameplay logic and system communication was implemented in Blueprint, with C++ used where performance or platform access required it. Blueprint keeps iteration fast for the designers working in these systems daily, while the platform layer underneath stays in C++ and exposes a deliberately small surface to them.

Device Framing

Phones and tablets differ enough in aspect ratio that one fixed camera distance frames the game differently on each. Holding the visible width constant does not solve it either, because width and height are linked through the aspect ratio. Pinning one lets the other drift, and a tall phone ends up showing noticeably more of the road ahead than a tablet does. Camera distance is derived from the device's aspect ratio instead, which holds the framing consistent across the range, checked against tablets and phones at both ends of it.

Performance Optimization

The game had to hold frame rate on low-end phones, not just recent flagships, so performance work was critical. I profiled the build whenever the architecture changed substantially to find what actually needed optimizing rather than guessing. Draw calls, texture streaming budget, and triangle counts on characters and track props were the main targets on the rendering side. On the code side, anything running every frame that did not need to was moved from Tick to timer handles. The build was tested across a range of low-end Android and iOS devices to confirm it held a consistent frame rate.

What I Learned

Working on a live commercial title for the first time taught me a lot about building systems that last rather than just systems that work right now. The requirement that the store and progression systems absorb new content without structural rewrites forced early architectural decisions that paid off in the end. The cloud save work gave me a real appreciation for how differently platform ecosystems handle identity and persistence.