TunnelPulse

TunnelPulse is an arcade reflex game. You fly a ship down a rotating tunnel and thread it between the obstacles coming at you. The controls are two moves: dragging carries the ship, two fingers fold the wings.

There are twelve obstacle types and they do not all want the same thing. The game says which through four action cues, each in its own colour: most need nothing at all (glide), a tight hole needs fold, the pie and chord shapes need roll and follow the opening, and the Slot wants the exact reverse — open the wings and line up.

The same control having two opposite uses is the core of the game. The colour code makes it readable at a glance, but you get well under a second to decide.

When a run ends you see how far you got and how that compares to your best. The menu holds your level, weekly missions and a market with two tabs: ships, and the game’s currency, AMP (from the oscilloscope theme; it is AKIM in Turkish). Score, player and economy services live in a separate server project.

The game is written in Unity and C#. The server side is a separate project: a Fastify API for score and player services, plus an admin panel. AdMob and RevenueCat handle monetisation.

The tunnel is not laid out by hand

The tunnel, the obstacles and most of the interface are generated at runtime rather than placed into a scene by hand. The practical consequence is that balance values — difficulty curve, obstacle frequency, gap width — can be tuned by changing numbers instead of rebuilding a scene.

That makes it possible to balance by measurement instead of by guess: changing a value and replaying the same run takes seconds.

Collision is fixed; the art is fitted to it

The game sells ship skins. If each ship’s collision shape came from its own mesh, two things would follow: either some ships would be narrower than others (an advantage you can buy), or every obstacle would need re-tuning for every new ship. Neither is acceptable.

So the collision model is analytic and fixed: thirteen sample points — the centre, eight around the body at 45° steps, and two on each wing. Folding the wings makes the body radius grow (0.40 → 0.62): the price of fitting through a tight hole is a fatter body.

Adding a new ship changes no code; the art is fitted to that fixed profile.

Two opposite complaints, two opposite fixes

The same collision model felt wrong in two different ways:

• “I was certain I would not hit, and I hit.” The sample points sat exactly on the visual radius, so a one-pixel touch meant death. The body points were pulled 20% inward — a collision now only counts once the ship is genuinely inside the obstacle.
• “I definitely hit, and I passed straight through.” The body had only four direction points and an obstacle edge could slip between them. Four directions became eight.

⚠️ The wing points were deliberately left on the visual outline: wing contact does not kill, it damages. Applying the same tolerance there would have closed the game’s only “forgiven mistake” channel.

Scores and economy live on the server

The leaderboard, player records and in-game economy are not left to the client; they are managed through a separate API and admin panel. That also means a balance value can be changed without shipping a new build.

For rewarded ads, the client does not grant the reward: AdMob’s server-side verification calls an endpoint on the server and the balance is written there. In a design where the client grants it, all a player has to do is fool the app.

Purchase refunds also come back in real time from both stores: Play sends Pub/Sub notifications and Apple sends App Store server notifications to RevenueCat, which webhooks straight into the game’s economy.

Got something similar?

I build products from idea to store release. Reach me by e-mail.