Gacha Stack Counter for Mobile RPG

Disclaimer

This project was built as an external tool for an existing commercial mobile game, so out of respect for their IP, filtered images and no videos will be shown publicly.

About

Gacha pull tracker for a mobile RPG with Dropbox cloud sync, optimized async downloads via dedicated console app, live pity percentages, sortable event history, and character pull stats, built in Unity/C#.

History

While playing a mobile gacha RPG, I got annoyed that the game didn't show a detailed pull history, even though pity and rising rates depend on exactly how many times I've rolled. I wanted a way to track my pulls, see my current chance for a target character, and access that data from anywhere not just like some scribbles in a notebook. Since the game is built in C# (Unity), I decided to make a small companion app and store pull data in the cloud using the Dropbox C# API so it stays in sync across devices.

SubTasks

• C# Dropbox API (with Async Download)
• UI to View & Edit Gacha Pulls
• Uploader to View & Edit Events/Characters

Challenges

Syncing Gacha Data with Cloud Storage

Needed a desktop companion app that could reliably sync hundreds of gacha pull-history files with the cloud and present them in a responsive Unity UI, but initial direct use of the Dropbox C# SDK inside Unity was far too slow (~1.4 files/sec, 6+ minutes for 500 files).

Approach

• Discovered that async downloads in the Dropbox SDK were blocked by Unity's threading limitations, so split the integration into a separate C# console app that uses async I/O to download all files into a Temp folder in about 12 seconds, then launches the Unity app to read and parse them.
• Exposed an async toggle in a settings file, and used the filesystem as the communication bridge: Unity reads and writes structured pull-history files (events, characters, counts) while the console app polls for changes every 0.5 seconds and uploads updates back to Dropbox.
• Built the Unity UI around events and years: supports general vs special banners, most-recent-year default view, sortable event lists, live pull count and current pity percentage, and a small stats panel that aggregates pulls by character, type, and rarity across years.

Lessons & Future Improvements

• Current file-based communication is simple but heavy-handed, because every change rewrites files and relies on frequent polling. A better approach would be a shared local service/API layer or lightweight IPC (named pipes, sockets, or gRPC) so both apps can exchange structured messages without constant disk churn.
• Dropbox updates could move from fixed-interval polling to a more event-driven model (e.g., file system watchers locally, or batching/scheduling uploads) to reduce unnecessary file IO or network calls.
• The separate Uploader app currently requires manual addition of new events/characters (banners from official site, icons from wiki). Future version could scrape sources automatically to detect updates, download assets, and map icons to names via HTML parsing, eliminating manual asset management.