/ 5 min read
ThunderBashers: shipping a Unity brawler in five days
A mid-jam engine switch, a mechanic that felt broken for three days, and the telegraph that fixed it.
I made ThunderBashers in about five days for the Very Serious Juniper Dev Game Jam. The theme was Spin To Win. I did the design, the direction, the art, and the audio pass myself, and it went up on itch.io as a WebGL build with a Windows download for anyone whose browser choked. It was my third jam game and my first in Unity, after Spare Knight in Phaser and I Won’t Be Abducted in Godot.
The pitch
Robots in a circular pit bash a storm-charged ball at each other. Spinning is the only thing you do: it hits the ball, it parries a hit coming at you, and it shoves a rival who gets too close. If the ball touches you while you are not spinning, you are out. Last robot standing wins. I did not want the theme to be a coat of paint on a brawler. Spinning is the offense, the defense, and the win condition.
The wrapper is a deadpan corporate league, the THUNDERBASHERS PRO LEAGUE, whose Standards Committee insists the rules are fair. On a jam that rewards “serious,” the joke was free points, and it gave every bot a reason to have a name.
The first sketch already had the whole game on it. The five days were about the distance between that sketch and a build that felt like it.
The pivot
I started in Unreal. Half a day in, the engine was spending my time instead of saving it: no clean path to WebGL, slow iteration, and every hour in the editor was an hour not drawing robots. I moved to Unity with about five days left.
That forfeited the “Best Unreal Engine Game” prize, and I knew it when I did it. In exchange, the game plays instantly in a browser on the itch page, which means more plays and more ratings, and it opened a “Best Web Game” target. The Unreal start is parked for a hands-on project later. Changing engines mid-jam sounds reckless. The real risk was shipping nothing, and the switch is what protected shipping.
The mechanic that fought back
“The ball kills you if it catches you not spinning” was supposed to be the easy part. It was the hardest thing in the game. For three days it felt wrong, and the temptation every evening was to tune the rule again.
The controls were simple from the first hour: move, aim with the mouse, space to spin. Simple to operate and good to play turned out to be different problems.
When I stopped chasing symptoms and went looking for the cause, “the mechanic is broken” turned out to be five separate problems stacked on top of each other. Any touch killing you made parrying feel like a timing puzzle bolted onto a brawl. Over-correcting to a speed gate meant enemies almost never died. The ball kept parking in a speed band that read as neither safe nor lethal. One value was gating a bot’s offense and its defense at once, so tuning a bot to be beatable also made it stop fighting. And the ball could look red-hot while the kill check briefly read it as safe after a wall bounce.
Every fix that “didn’t work” was fixing a real bug. Just not the one in front of the player at that moment.
Readability is a mechanic
What finally made the core feel right was not a rules change. It was a heat tint on the ball: cool blue when it is slow and harmless, ramping to red and crackling when it is fast enough to kill. Once you could see the threat state, “a slow ball doesn’t hurt you” read as obvious instead of buggy. The biggest feel win in the game came from legibility.
That is the lesson I kept. When a mechanic feels wrong, it is often a readability problem wearing a rules problem’s clothes. Fix what the player can see before you change what the game does.
Bots with temperaments
It is a single-player game, so the bots are the game. I did not want a difficulty slider. I wanted opponents with personalities. Every bot is a data profile: reaction time, aim error, spin skill, how far ahead it looks for an incoming ball, how readily it panics. The profiles fall into five archetypes, from a rookie who mistimes everything and feeds you confidence kills to a veteran you only beat with wall ricochets and baited parries.
Two bugs taught me the most. Bots crowded the ball and multi-killed in one pass, which looked stupid; the fix was electing one “committed striker” each frame so they approach one at a time. And splitting offense from defense, so a bot always strikes but parries by skill, was what let me tune a bot to be beatable without it going passive. The campaign then distributes those archetypes across three arenas to build the curve.
What I’d keep
Root-cause, don’t symptom-chase. Build to your real target early, because the shipped build is the only build that counts. And readability is a mechanic: the most legible version of a rule usually feels like the best-designed one. A small, finished, legible game beats a big unfinished one every time the clock is running.