Atom Gauntlet: Protocol

The game

Polo is a thief locked up in Carcere, a prison station in space. The guards there use the Atom Gauntlet: a glove that can rearrange atoms and materialise weapons out of nothing — but only the ones it already knows. Each new weapon is an add-on the player has to find along the way.

Attacking drains the glove's energy, and it only recharges at checkpoints, which also save your progress. When the energy runs out, Polo fights with his fists. There are four wings to get through before the Hangar — Cells, Maintenance, Armoury and Orion's arena — three weapons, four kinds of regular enemy and one boss.

The combat is designed around reading, not repetition. Every enemy telegraphs its attack before it lands, and mashing the button is the fastest way to die.

What was mine

On the original project: most of the programming, Orion and his animations, the final level in the Hangar, and support on level design and story. The combat system, the weapon system, the energy drain, the enemy state machines, the checkpoints and the moving platforms all came from here.

A year later, in 2026, I came back to the project alone — with the other three's permission — to fix what the deadline had left behind. That revision is what the sections below are about, and it's where the video above comes from: in the old recording the game crashed before the last level, and Orion never appeared at all.

The animation is the truth of the combat

I had four complaints written down, and they looked like four different problems: the combat was "far too dependent on timing"; the guard landed hits with no time to dodge; the shooter fired too often; the boomerang left no window to hit back.

Reading the code, all four had the same design underneath. The animation was just a cue telling the Animator to start playing, and the damage ran on its own clock, in parallel. On Polo, damage came out on the click. On the guard, two tenths of a second after the trigger — more than a second before the sword came down. On the shooter, two seconds before the shot appeared on screen. On the boomerang, on the first frame of the throw, before the arm had moved.

Without damage tied to the animation there is no tell, and without a tell there is no dodge. The same thing happened in reverse on my side: attacking cost nothing, because Polo swung and kept walking as if he hadn't.

The fix became a single rule: every attack has a wind-up, an impact and a recovery, and the damage lands on the frame where the weapon connects. What made it interesting is that each character needed a different technique to obey the same rule.

On Polo, each weapon has its own duration and the animation is sped up or slowed down to fit it: the same clip takes half a second with the sword and a second and a half with the axe. During the swing he moves at 30% speed and doesn't turn — he chose a direction, and it holds until the end.

On the regular enemies, the facing locks halfway through the wind-up. That's the reading window: you can see where the blow is going and step out of it. And a hit now requires a 100-degree frontal arc, so standing behind the guard stopped being the same as standing in front of him.

On the boxer, the same idea with a different tool. His animation is a slice of a long recording that contains two punches. Rather than redo the animation, I split the clip into the three stretches the punches create and gave each a different speed: a quick 0.25 s jab, a long 1.2 s wind-up that announces the heavy punch, and 0.8 s of recovery that is the player's window. A two-beat combo with no new animation at all.

On Orion the structure was already right — he uses markers inside the clip itself. The problem there was ordering: in one attack, the marker declaring the end came before the one summoning the turrets. He declared himself free, another attack cut the animation short, and the turrets never came into existence.

Two different methods live in the same game: timing computed in code for the regular enemies, animation events for the boss. That was deliberate. Mixing the two inside a single character is what would be confusing.

The execution nobody would use

The axe can execute: an enemy on low health can be finished off by holding a key. Coming back to the game, I realised no attentive player would ever do it.

The maths didn't work. Executing meant switching to the axe, holding a key for almost a second and switching back — three actions — while a sword swing settled it there and then. And since every weapon spent the same energy, there was nothing to save. Worse: the axe had a damage bonus against wounded enemies that killed them before the execution window opened. With the axe in hand, executing was literally unreachable.

The question that unlocked this wasn't about the execution. It was about the whole game: what should the player be afraid of losing — health, or energy?

I chose energy. It's the resource the glove uses, it only comes back at checkpoints, and it's what gives the system its identity. From that choice the fix became obvious, and it needed no new mechanic at all: each weapon now costs a different amount of energy per swing, and the execution window went up from 20% to 40% of the enemy's health.

The sword is the damage weapon. The hammer is worse on purpose — it exists to break things, not to fight. And the axe has exactly the sword's efficiency while being three times slower: nobody wants to fight with it, everybody wants to execute with it.

After that I redid the energy maths for every stretch between checkpoints, adding up the ideal cost of clearing each one. The final confrontation in the Armoury courtyard — where, in the script, Polo "only just manages to get away from that group" — ended up costing more energy than the meter holds. It can only be won by executing. The climax of the level forces the player to use the mechanic they just earned, with no tutorial asking them to.

Orion: a choice in the middle of the fight

The boss has 99 health split into three blocks, and the interesting part happens between them. Every time a block runs out Orion is stunned, and the player decides on the spot: keep hitting him while he's vulnerable, or run around behind him and seal away another piece of his power.

The two choices move the fight in opposite directions. Hitting him during the stun angers Orion — he comes back faster and more dangerous. Sealing does the reverse: he comes back slower, but the player gave up free damage and spent energy to get it.

Before the revision, that choice barely existed. The seal was out of the player's reach, two metres off the ground, with no on-screen prompt — half the system was invisible. And the clock counting the interval between special attacks kept running during the attacks, so the "three and a half second interval" was measured from the start of one blow to the start of the next. Since the blows last seconds, almost nothing was left: the attacks ran into each other with no window to answer.

Today the clock only runs while Orion is free, and the interval scales with both of the player's decisions. A player who always seals keeps the window practically intact across the fight. A player who always hits watches it shrink by half. The punishment isn't a number on screen — it's the air missing between one attack and the next.

He has seven attacks and five seal states, from −2 to +2, and the model changes with every block broken. Making all three stages have their own attacks and animations, in sync, was the hardest part of the whole project.

What was left out

Armoured enemies were in the original pitch and are still out. That was new functionality, not a fix, and the revision had a deadline — the only armoured thing in the game is Orion, who summons rocks that only the hammer breaks.

The dialogue system wasn't touched either, and the exchanges between characters still deserve better. And the game is still short for the number of ideas the weapon system can carry.

One problem I couldn't prove is still open: on the very first run of the Windows build, the game closed itself while loading the first level. The same file worked on every run after that, with nothing changed. The suspicion is shader compilation on first launch, but a suspicion isn't a diagnosis, and I'd rather record that than pretend it didn't happen.

And one design question is still open, which I like keeping on the record: sealing costs 15 energy, and breaking the crystals to force the stun costs roughly the same 15. With equal cost, sealing is always the better choice — the aggressive path needs a reward that doesn't exist yet. The fight works, but the choice isn't as balanced as I want it.

Team

First-year capstone project for the Digital Game Design programme. No paid assets. The 2026 revision was done by me, with the permission of the other three.