Taiwan Ace Driver

Screenshots

Swipe to see more.

How it's built

A Flutter shell, a Godot game and a Django backend. Phones and the web run the same game code.

• Flutter shell

  Settings, sign-in, the level list and records live in Flutter. When a level starts, language, graphics and control preferences go to the game over a settings channel, and results come back when it ends.

• Godot 4 game

  Streets are generated from level data; traffic, pedestrians and rule-breaking drivers are run by traffic AI. Ticket rules live in data files, and phones and the web share the same game code.

• Django backend

  Handles accounts and account deletion, multilingual landmark guides, and signs level config before publishing it. The app checks the signature before using a download and falls back to the last good version if it fails.

• Web version: a one-level trial

  The web version has a single level, the Lotus Pond pagodas, playable without installing anything. The level pack has a content hash in its file name and is checked with SHA-256 after download; later visits use the browser cache. The full set of levels is in the app.

• Quality

  Both Godot and Flutter have automated tests, and levels get regression checks and screenshot comparisons. Every fix has to pass the tests before it is merged.

What Flutter gives us across platforms

• One Dart codebase builds both the iOS and Android apps, so settings, sign-in, the level list, records and the three-language UI are written once.
• Both platforms look and behave the same; one fix lands on both, and one set of tests covers both.
• Native features such as AdMob, Firebase, sharing and sign-in have official or mature packages, so we do not write separate Swift and Kotlin code.
• Hot reload shows UI changes in seconds, and Flutter has proven itself across several past projects with performance and development speed we are happy with.

Why the game uses Godot instead of three.js or Flutter

• three.js only renders 3D; it has no physics, collisions, audio management or scene editor, so vehicle handling, traffic and collisions would all be written from scratch.
• Flutter is a UI framework with no built-in 3D scenes, physics or collisions; it suits the app shell, not a 3D driving game.
• Godot is a complete open-source game engine (MIT license, no fees or royalties) with built-in 3D rendering, physics, audio, animation and input.
• Scenes and scripts are text files that Claude Code can read and write directly and that diff cleanly in git; the game can also run headless for automated tests.
• The same game exports to WebAssembly: the app runs it in a WebView and the web version runs it in the browser. The trade-off is tighter performance in a WebView, so low-end phones need lower graphics settings.

Deployment decision: Cloudflare Workers for the site and game assets

The first release of the website and the Lotus Pond web version are all static files, served as Cloudflare Workers static assets with no Worker code. Static asset requests are free and unlimited, with no bandwidth charges. The app and its APIs still use the findmo backend, so web traffic never reaches the backend.

Assumptions: a visit opens the home page and scrolls to the end; visitors who play also download the game. Risk: Cloudflare’s service terms require paid services (including the Developer Platform) to serve video or a disproportionate share of large files through the CDN, and they do not say whether the Workers Free plan counts, so we move to Workers Paid before traffic grows. Static asset requests stay free and unlimited on the paid plan. index.pck and the level pack are now compressed on Cloudflare, cutting the first web download from about 19.7 MB to about 14.4 MB.

Why the full set of levels ships inside the app

• The web version has only the Lotus Pond level as a no-install trial; the assets for every other Kaohsiung landmark level are packaged in the app.
• No bandwidth cost for us: the app downloads from the App Store or Google Play, which carry that traffic, and playing a level downloads nothing from our servers.
• No waiting to start a level: the assets are already on the phone, so levels open without a network connection and never stall on a loading screen.
• The backend only sends small files: the app fetches the signed config and landmark guides; level content updates with each app version after store review.

Running costs: AdMob ads

• The app covers running costs, such as servers, the Cloudflare paid plan and store fees, with Google AdMob ads.
• Three placements: an app-open ad, a banner at the bottom of the landmark list, and an interstitial when you return to the list after a few levels.
• No ads while driving; interstitials have a daily cap and a minimum interval, and the admin panel can change or turn them off at any time.
• The web version has no ads; it lets players try the game first and then points them to the app.

Development story

From the first commit to 0.1.0, Claude Code wrote most of the code and tests. A person set the requirements, made the decisions and tested on real devices. The numbers below are generated from git history at build time.

Tools and models we used

• VS Code

  IDE

  The integrated development environment for the project.

• Open Bull

  Harness plugin

  Manages change issues and project documents.

• Claude Code

  US$200 subscription

  Does most of the coding, integration testing and deployment. Mainly runs on Claude Opus; subtasks use Sonnet and Haiku.

• Codex

  Pro subscription

  Mainly generates images: feature art, street elements, billboards and icons.

• OpenAI

  Audio

  Generates voice sound effects such as street-vendor announcements and horn calls.

Milestones

1. Project baseline: plan, Godot prototype, Flutter shellThis is our first project with Godot. Flutter has been proven across several past projects, and we are happy with both its runtime performance and development speed.
2. Three-language UI (Traditional Chinese, English, Japanese)
3. First Kaohsiung street level
4. Standalone web build: a one-level Lotus Pond trial
5. 0.1.0 store submission

Workflow

1. HumanDescribe a feature or a problem in one sentence
2. AITurn it into issues with current behavior, expected behavior and acceptance criteria
3. AIImplement each issue on its own branch and add tests
4. AIRun static checks and automated tests; merge only when they pass
5. AIDeploy to a test environment and check it for real
6. HumanMake the calls: the AI writes up each decision as three options with a recommendation, and a person picks
7. HumanA person plays on real devices and marks problems on screenshots for the AI to fix
8. AIStore submission and production deploys are done by the AI through the Ego Lite browser; a person types in usernames and passwords

Not fully automatic: product direction, trade-offs and going live are decided by a person.

Who does what: people and Claude Code

• Game scenarios and rules: a person sets the overall direction, Claude Code decides the detailed rules, and a person plays the game and files issues as feedback.
• Whether sounds are pleasant and the game feels smooth: a person tests this by playing on a phone.
• English and Japanese: no native speaker has reviewed them yet; we use the translations from Claude Code for now.
• Real-device performance, heat and touch feel: a person tests on real phones, because a simulator can’t measure them.
• Store accounts, store consoles and production servers: Claude Code operates them through the Ego Lite browser skill; a person types in usernames and passwords.
• Delivery during development is done by Claude Code: branching, testing, merging and deploying, following delivery rules written in CLAUDE.md.