One Shot
A competitive physics puzzle with one shot per day.
- Project
- Our own product
- Our role
- Design · Software development
- Platforms
- iOS · Android
01 / Behind the product
A real need. A considered solution.
Challenge
In a one-shot-a-day physics puzzle, competition depends on the same scene behaving identically for everyone. Floating-point physics drifts across engines and compilers; if the Unity editor, an IL2CPP build and the server disagree, the leaderboard, the replay and anti-cheat all collapse together.
Approach
The simulation core has no UnityEngine dependency, and CI enforces it. The same .cs files compile on three runtimes: Unity Mono, an IL2CPP player build and a .NET 10 server; 20 golden fixtures produce byte-identical results on all three.
A shot travels to the server with its input log and the server re-simulates it: a forged "1 µm hit" is caught as a mismatch and the leaderboard keeps the server’s number; an impossible input log is rejected. shots is unique on user_id + scene_seed, so a second attempt gets a 409; the spoiler wall is closed by RLS. Four Edge Functions cover daily scene generation, shot submission, verification and the Reprise build.
Result
The playable slice is complete: the deterministic core and the daily loop are verified end to end (12 + 8 checks), and visual smoke tests render the scene to PNG and assert it is not blank, which is how four real visual defects were caught. Reprise, art, virality and monetisation are the next milestones. The images shown here come from actual prototype gameplay.
02 / Inside the product
The experience, on screen.
Open a screen to explore the details.02 images
03 / Scope & details
The details make the experience.
- 01
Byte-identical simulation on Unity Mono, IL2CPP and a .NET server
- 02
Server-side re-simulation verifies shots; forged hits are caught
- 03
One shot per day: a database constraint and an RLS spoiler wall
- 04
20 end-to-end checks and visual smoke tests
Technology
INSIDE THE PRODUCT
The engineering behind the interface.
Systems we built and concrete problems we addressed in this project.
Byte-identical across three runtimes
20 golden fixtures run in Unity Mono EditMode, on a real IL2CPP build, and in the .NET 10 OneShot.GoldenCheck project that compiles the same .cs files. The Reprise, the leaderboard and anti-cheat all rest on that property.
The server has the final word
verify-shot re-simulates the input log: an honest shot is ok, a forged "1 µm hit" is a mismatch with the leaderboard keeping the server’s number, and an impossible log is rejected and excluded from ranking. An eight-check e2e suite exercises all three on every run.
Visual smoke tests found real defects
A PlayMode test renders the slice to PNG and asserts it is not blank; ADR-0005 lists four real visual defects caught this way. The test cannot run headless (-nographics), so it runs headed in CI.
Your idea could be next.
What could we build for you?
From a first release to a growing platform. Let’s plan the design, development and launch together.
From Türkiye to the US, UK, Australia and everywhere in between.