My Bad, Heaven

The original title was "Oops, I Killed a God." Roblox's chat filter flagged the phrase the moment it started spreading in playtests, which is a genuinely funny way to lose a game's name: not because the title was inappropriate, but because a filter built for a different kind of problem caught a completely innocent phrase in its net. I renamed it "My Bad, Heaven," which keeps the same tone (the shrug, the almost-apology) without tripping the filter, and honestly I think it's the better title anyway. It sounds like something the god you accidentally killed would say back to you.

The premise: an ordinary mortal, through no particular skill or destiny, accidentally kills a god. The remaining gods now fear this person, because if it happened once, by accident, to someone unremarkable, it can happen again. That's the whole hook. No chosen-one framing, no prophecy, just the terror of an entire pantheon realizing their invincibility was never as absolute as they assumed, and that the person who disproved it didn't even mean to.

What the fight actually feels like

The playable core is a single boss encounter against a god named Kaelos, set inside an arena called the Forgotten Temple: two hundred and six meshes, fifty-nine collision volumes, procedurally assembled from a fixed seed so the layout is reproducible rather than randomized fresh every time. The player picks up a divine spear early on and gains a genuine step up in movement and combat capability, which is the mechanical language for "you're briefly touching power that isn't supposed to belong to a mortal." The signature system, Fate Instability, and its centerpiece moment (an "accidental execution" sequence where a stray fate misfire turns the player's next completely ordinary attack lethal) is the mechanical retelling of the game's entire premise: you didn't earn this kill. It just happened, and now you have to live with what that means.

Combat animation isn't done with imported cloud assets. There's a custom system, PoseAnimator, driving procedural animation through C0 motor constraints instead of pre-baked animation clips: a harder, more hands-on way to get characters moving, chosen because Roblox's built-in animation import pipeline had real, documented problems I'll get to in a moment.

Built like a studio, run by one person and an agent

I want to describe how this actually got made, because I think the honest version is more interesting than the flattering shortcut. A large amount of the day-to-day implementation (the actual Luau scripting, the iteration on combat feel, the mesh import automation) was carried out by an autonomous coding agent working through Roblox Studio, across a series of documented sessions. My role was closer to creative director and gatekeeper than line-by-line coder: setting the design bible, reviewing what got built, and specifically holding a hard line on character animation, where nothing shipped without my explicit sign-off through something the project's own docs call the Animation Approval Queue. I didn't write every script. I decided what counted as good enough to keep, and what didn't.

That's not a diminishment. Directing that process well, knowing what to approve, what to send back, what the fight needed to feel like before it felt right, is its own real skill, and a different one from typing out every line of Luau by hand. But I'd rather say plainly how this got built than let "I made a Roblox game" imply something it doesn't. The documentation trail for this project is extensive: a full design bible, an architecture doc, a lore bible, an art direction doc, a technical standards doc, a roadmap, a decision log, a risk log, a technical debt log, a changelog. That's the kind of process infrastructure a real studio runs, compressed down to one person directing an agent instead of a team of people directing each other.

The bugs that actually happened

A boss rig froze visually mid-fight because its limbs were anchored, a physics state issue that looked like a crash but wasn't. A race condition in the death sequence caused real crashes under specific timing. Rojo, the tool that syncs code from the filesystem into Studio, kept disconnecting during play-test transitions, which is exactly the kind of infrastructure flakiness that eats development time without teaching you anything about your actual game. A custom blood-moon skybox for a future boss arena flatly refused to load correctly in Studio no matter what was tried. And EditableMesh, the newer mesh-editing API, was losing UV data on save, which forced an entire pivot away from that pipeline toward importing meshes as cloud assets instead: a real, mid-project architecture change forced by a tool limitation, not a design decision made in advance.

None of that is hidden in the project's own docs. It's logged candidly, root-caused, and fixed, which is how I'd want any real development process to run: not one where nothing ever breaks, but one where breakage gets written down honestly instead of quietly patched over and forgotten.

Where it actually stands

The first playable milestone (one hub, one arena, one boss, the full execution sequence) is finished, playtested, and closed as of early July, reportedly running at sixty frames a second with solid input latency. The second milestone, focused on replayability, is approved in scope and actively underway: a companion wolf with its own rig and hand-authored animations, two more named god bosses waiting to be built, new abilities, competitive modes. Monetization exists only as placeholder IDs right now: nothing real-money is wired up, and that's staying that way until the game has proven it deserves a storefront, not before.

What I'd tell someone judging the process, not just the game

If the process sounds unusual, it's because it is, and I'd rather explain it than have someone assume the more familiar story. I have opinions about combat feel that are hard to fully articulate in advance and easy to recognize the moment they're wrong, which is exactly why I rejected my own first combat build after playtesting it myself and calling it out plainly as worse than the platform's own default rig. Directing an agent through a process like the Animation Approval Queue is how I turned that instinct into something that actually shipped correctly instead of staying a vague feeling I never acted on.

Full stack developer. Founder of Yashveer Labs. I didn't write every line of this one myself. I decided what was good enough to keep, which is a different job, and I think it's the one that actually mattered most here.