Inspiration
On a day-to-day basis as a game programmer, I haven't always been able to dive as deep into other disciplines of game development as I would have liked. Getting the chance now to look more closely at parts I don't normally work with professionally feels quite rewarding to me.
Making an extraction shooter has been something I've thought a lot about recently, since it's a genre I've come to like more and more, and I've been curious about how I'd want to design one myself.
What it does
COREDIVE is a top-down bullet-hell extraction shooter built for mobile. You dive a flooded facility floor by floor, stripping it for materials while enemies, their fire patterns, and the danger of every room escalate around you. Every third floor offers a way out: bank what you're carrying, or push deeper on the bet that the next haul is worth the risk. Die, and you lose everything you brought with you --- the materials in your bag and the gear you dove with. Extract, and it's yours to spend.
Materials banked between runs are spent at a Fabricator to craft and upgrade gear --- weapons, armour, and trinkets, each with real trade-offs, never experience points or character levels. A hub between dives lets you choose your loadout, check your stash, and pick how deep to insert based on the floors you've actually survived. Two escalating minor bosses guard the way down, and a two-phase final boss holds the only way out of the last floor: beat it and extract, and the campaign has a real, distinct ending.
Every floor is procedurally assembled from hand-authored room templates and a seed, so no two runs repeat, and movement, combat, and controls are built around a single thumb and an automatic trigger that targets the nearest threat --- twin-stick shooting without needing a second stick. The entire game is built from primitives and code: no image, model, font, or audio file ships with it at all.
How we built it
Three.js and vanilla HTML5 on top of an AI build tool (Claude Code) doing the actual implementation, with me steering direction, making the judgment calls, and reviewing every change. Design decisions were locked before any code was written --- genre, the core bank-or-push loop, gear over levels, aim as target selection for a thumb-only control scheme --- so the build itself went in dependency order: seeded randomness and the stat system first, procedural level generation next, then the entities, persistence, the raid and hub, audio, and the interface layer that ties it together. Everything in the package is generated at runtime from primitives and code --- there's no image, model, font, or audio file anywhere in it, and one script concatenates the source files into a single, unminified, readable build.
The build didn't stop at "it compiles." Every fix was verified against a live, actually-running instance of the game --- driven through a real browser, stepping simulated time forward frame by frame to reproduce timing-dependent bugs on demand --- rather than trusted on inspection alone. That loop of playing it, finding something that felt wrong, fixing it, and playing it again is most of where the later sessions went: widening chokepoints that turned out too tight, correcting a shortcut that unlocked the wrong floor, adding a way to swap gear mid-run once finding a new weapon mid-dive actually became possible.
Challenges we ran into
Translating a twin-stick shooter to a single thumb was the biggest design problem to actually solve, not just implement: aiming had to stop depending on a second stick or a mouse and become target selection instead, so the same control scheme feels right whether you're on a phone or at a desktop. Getting that to feel consistent across input methods took more iteration than expected.
Balancing gear progression against a thirteen-floor difficulty curve was another one, especially without the benefit of a long playtesting period. Some of that had to be worked out on paper before it was ever playable --- checking that an upgrade always made a weapon strictly better, for instance, rather than trusting that scaling every stat evenly would obviously do that. Other things only showed up once the game could actually be played end to end, like a run's opening minutes turning out harsher than intended, or a death costing a player more than it was supposed to.
More generally: verifying that a fix actually holds up in real use, rather than just in a quick check, turned out to matter more than it sounds like it should. More than once something looked solved and then reappeared under
Accomplishments that we're proud of
Still, I'm proud to have found a core loop that I believe can be developed further going forward. In that sense, this hackathon has definitely felt rewarding.
What we learned
On top of that, getting to develop my ability to work with AI across every discipline is also an experience I can carry with me going forward.
What's next for Coredive
Multiple types of runs, with different biomes, are a natural next step --- each with its own room set, enemy roster, and hazards, giving the core loop somewhere further to grow.
Log in or sign up for Devpost to join the conversation.