Unity mobile game development with measured levels and tested systems

Which Unity games have we built, and where does each one stand?

We build our mobile games in Unity and C#; Tilting Jar, Puzzle Reveal, SUNTHREAD, WARDLIGHT, Mosquito and BEEing run on Unity 6. Here is where each one actually stands:

• Tilting Jar: live on the App Store. 300 levels, 15 chapters, 12 mechanics, 5 languages.
• Puzzle Reveal: live on the App Store, version 1.1.2. 50 hand-tuned levels plus an endless mode.
• Screwsmith: in development. 200 baked levels and 16 machines are in; the privacy and support page for 1.0 is live.
• SUNTHREAD: in development. All 320 levels pass the verification report with zero failures.
• WARDLIGHT: client work for Hallowmark, in development. The client approved the drag feel at the interim delivery, and a 34 MB release-ready Android bundle is built.
• BEEing: in development, with launch planned for the winter season.
• Mosquito: in development; 15 levels, 20 human variants and the store are done.
• One Shot: a prototype. The playable slice is verified end to end; art, virality and monetisation are the next milestones.

The figures on this page come from the README, plan, progress and report files in each game’s repo.

Why do we generate levels deterministically?

If players are not on the same level, you can neither tune difficulty nor reopen a bug report. So level generation is built to be repeatable:

• In Tilting Jar, the first 24 levels are a handwritten teaching ladder; after that the seed is the level index, and level 137 is identical on every device. That is not a claim of bit-identical physics across devices; what is identical is the starting conditions.
• In WARDLIGHT, the generator first builds a valid Hamiltonian path and derives arrows, walls and locks from it, so every level is solvable by construction. The seed is seed = (uint)(level * 2654435761).
• In Screwsmith, randomness comes from xorshift32 rather than System.Random, giving the same output on every platform and Unity version.

Determinism is protected by keeping game logic out of the engine. Screwsmith.Core and Wardlight.Core contain zero UnityEngine references, enforced by asmdef. The SUNTHREAD and WARDLIGHT generators were written in Node first as the reference; the C# ports are diffed byte for byte against golden fixtures. In Screwsmith, level generation and measurement run headless with -batchmode, without opening an editor window.

How do we measure difficulty with a solver?

Difficulty measured against perfect play is misleading, because almost every level survives perfect play. So Screwsmith’s solver produces two numbers: the minimum rail slots needed under perfect play, and how often a plausible human loses the level. It plays every level 24 times with a shallow strategy, and the loss rate is the dominant term of the difficulty score (×11). Of 200 baked levels, 157 landed exactly on their target band and 34 missed by one. The curve is deliberate: a 0.8% average human loss rate over levels 1–35, a wall at level 36 (37.5%), and 34% over 101–200.

In SUNTHREAD the question is different: does the player actually make decisions? On the WARDLIGHT engine, 100% of moves at level 400 were forced. SUNTHREAD’s generator sets five gates: exactly one solution, no removable clue, a human-style solver that uses only named deduction rules, a forced-move ratio inside 35–70%, and a fingerprint that rejects a rule multiset matching any of the last five levels. The measured ratio runs from 0.44 to 0.79, averaging 0.59.

In Puzzle Reveal, the first version’s formula made the game unwinnable past level three. The 50 levels were hand-tuned instead, and the difficulty manager targets a 65% win rate.

Why are readability and undo audited automatically?

A level being solvable does not mean the player can read it. Screwsmith’s ReadabilityAudit catches pixel facts before any play test: it renders the board to a RenderTexture at real device resolution and measures again at every state of a playthrough.

• The touch target must be at least 8.5% of screen width, about 4.7 mm. Level 178 had three screws at 0.084 of screen width, and the audit caught it.
• Colour distance is measured with CIE76 ΔE: at least 11 for normal vision, at least 9 after a red-green colour-blindness simulation. A seventh colour broke the dimmed floor, so the palette stays at six.
• Screws hidden under the HUD are caught in the same loop.

Undo gets the same treatment. The solver backtracks with the game’s own undo, so an undo bug corrupts measurements too. UndoAudit.Run plays up to 60 random legal moves on each of the 200 levels and compares the board before each move with the board after undoing it. Before trusting the audit, we showed it fails against a broken simulation using UseLegacyCrateUndo and corruptSnapshot.

In Mosquito, a similar quality gate checks for overflow across seven screens at six device resolutions.

Server-verified simulation: how does One Shot catch cheating?

One Shot is a competitive physics puzzle with one shot per day, and it is currently a prototype. Competition requires the same scene to behave identically for everyone, yet floating-point physics can drift across engines and compilers.

The simulation core has no UnityEngine dependency, and CI enforces that. 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 verify-shot re-simulates it. An honest shot passes; a forged "1 µm hit" is flagged as a mismatch and the leaderboard keeps the server’s number; an impossible input log is rejected. The shots table is unique on user_id + scene_seed, so a second attempt gets a 409, and the spoiler wall is closed by Supabase RLS. Visual smoke tests render the scene to PNG and assert it is not blank, which caught four real visual defects.

Leaving the final word to the server carries over to other games: in BEEing, score plausibility checks and server-timed offline earnings, and in Mosquito, scores and gates are validated in Supabase Edge Functions.

How are the release pipeline, ads and purchases set up?

On the way from Unity to the store, one missing setting can mean a crash on launch. After a launch crash in Puzzle Reveal’s build 13, the chain was scripted: compile, visual tests, build number, iOS export and Info.plist gates (AdMob id, ATT copy, SKAdNetwork) in one command, and if a gate fails the chain stops. Our later games reuse that approach. In Tilting Jar, Unity → Xcode → pod install runs as one command, and the build refuses to proceed without the AdMob app id.

Ads and purchases are built provider-agnostic. With no key configured, Tilting Jar runs on a fake store. In WARDLIGHT, ads, purchases, analytics and cloud sync sit behind interfaces, so the game opens in the editor with no SDKs at all. Cloud and analytics use REST through UnityWebRequest rather than SDKs, which is IL2CPP-safe and keeps the bundle small.

The offer engine runs on measurement too. In Tilting Jar, "remove ads" is suggested only after five interstitials were actually seen, rewarded ads are never blocked, and progress is never locked behind money. We do not guarantee downloads, revenue or retention; economy design and integrations are scoped separately.

Frequently asked questions

RELATED STUDIO NOTES