What the game is
You dig, sell or keep what you find, and fill in the index. Coins buy a better shovel, and a better shovel digs faster and reaches rarer gems. Coins and index milestones also unlock new zones, each with its own gem catalog. Beyond digging there are pets from zone eggs, daily and weekly quests, a vault you can walk through to show off your best finds, and timed events. A rebirth resets your coins, tools and zones in exchange for more luck, while keeping your index, pets and cosmetics. The furthest zones are a set of Hell islands, reached through a portal after beating a boss, for players who have rebirthed far enough to want somewhere new to dig.
Real odds, and proving them
The whole pitch is "every gem shows its real odds. No secrets." That only means something if the odds on screen are the odds the server actually rolls. RollService, the module that owns every roll, is tested with a seeded run of 1,000,000 digs that checks the result against the odds table: the worst deviation across the whole catalog came out to 1.75 sigma, well inside what a fair roll should produce, at 168,000 rolls a second in the command-line harness. That harness runs outside Roblox entirely, against the same Luau modules the live game uses, so the odds test is not testing a copy of the logic, it is testing the logic.
Everything is a config table
Gems, prices, drop odds, zone layouts and shop items all live in Luau config modules rather than scattered through game logic. The first zone alone, Meadow, is a 49-row catalog, and the full game now runs to hundreds of gems across nine overworld islands plus the Hell world. Keeping every number in config means a rarity ladder that big is something a spreadsheet-style pass can balance, not something that needs a line of code changed per gem.
A wiki that can only show what's live
The player wiki
is generated straight from the game's own config, so gems, zones, pets, shovels and codes on the wiki match
the game exactly, with nothing to keep in sync by hand. The build reads the newest live-v<version>
git tag, so anything not published to Roblox yet simply cannot appear on the wiki, even if it already exists
in the code. The gotcha with that design: the tool that publishes a new place version does not create that
tag on its own, so a run of updates went out untagged and the wiki quietly sat several versions behind until
the tag was added by hand and the site redeployed. Now every publish is followed by a tag, then a redeploy.
Shipping in waves, as place versions
Updates go out as numbered Roblox place versions, each one a small, named batch of changes rather than one large release. A quality-of-life pass, a boss and relic system, a run of Hell islands: each lands as its own version, tagged and checked before the next one starts. That keeps every change traceable to exactly what shipped and when, and it means a bug can be pinned to the version that introduced it.
Bugs that only show up live
Compiling clean and passing every offline test says nothing about what the game actually looks like once it is running. A few bugs only turned up by opening Studio and playing the real thing:
- Legacy lighting. A build shipped without setting
Lighting.Technology, so it loaded on the old Legacy renderer, which never renders Atmosphere at all. Every zone's haze setting was being silently ignored, and it only became visible once someone actually looked at the world in Studio. - A spawn race caught after publish. A separate script built the world's scenery in parallel with the script placing gem spawns, and the spawners sometimes ran first. A live check after publishing found 18 of 50 pickups sitting inside hills and rocks. The fix was to build the scenery right after the world itself, in a fixed order, and the next version confirmed it.
- An upgrade tap that felt like lag. Players reported the shop button lagging when upgrading quickly. The shop's request limiter was silently dropping requests once a player tapped faster than its budget allowed, so the button just sat there for a few seconds. Raising the request budget fixed what looked like lag but was actually a limiter with no feedback.
How it's built
I build this solo, in Claude Code with subagents doing the implementation work in parallel while I review and direct. It keeps a big catalog and a large feature set moving without every change going through one linear queue.