This post originally appeared on the Makko AI blog.
Your character attacks an enemy standing directly in front of them. Nothing registers. They try to crouch through a gap they are clearly small enough to fit through. Something invisible stops them. Your character clips through a wall they should be blocked by, or gets blocked by space that looks completely empty.
None of these are art problems. None of these are animation problems. They are hitbox problems. And hitbox problems are almost always caused by the same two things: one hitbox being used for every animation state, and that hitbox being sized to the wrong reference point.
What a hitbox actually is and why one box is never enough
A hitbox is a defined region, almost always a rectangle, that tells the game engine where a character physically exists in the world. It determines when the character takes damage, when they collide with platforms and walls, and when geometry blocks their path. The visual art is irrelevant to this calculation. The engine does not look at the animation and decide what counts as a collision. You have to tell it.
The problem most developers run into is this: a default hitbox gets created when the character is first set up, usually based on the idle pose, and then nothing changes. The idle hitbox gets applied to the run animation, the jump animation, the crouch animation, and every other state. But every animation changes how a character occupies space. A running pose is wider than an idle. A crouch is shorter. A shooting stance extends the arm forward. A jump pulls the legs up and out.
When the hitbox does not match the animation, the engine is working from incorrect information. These are not edge cases. They are the default outcome of never updating the hitbox per animation state.
The fix is straightforward: every animation gets its own hitbox. Not a shared one. Not a close-enough approximation. One hitbox per animation state, fitted to that animation specifically.
The majority state rule: cover where the character is, not where they reach
Makko's Alignment Editor shows you the first frame of each animation when you go to set the hitbox. That is the only frame you can see while placing the box. This means you are making a judgment call about the entire animation based on one frame.
The rule is this: cover where the character spends most of their time in the animation, not where they reach at their furthest extent.
Here is a concrete example. A shooting animation is 24 frames long. In 22 of those frames, the arms are fully extended outward. In the first 2 frames, the arms are just beginning to move. If you draw your hitbox around only what you see in that first frame, the hitbox is significantly smaller than where the character actually is for 22 out of 24 frames. Hits that should register will miss.
The correct approach: size the hitbox to the 22 frames, not the 2. If you are unsure what the majority state looks like, go back to the Character Details page, find the animation, and watch the full loop. Then draw the box there.
Working through each animation state
Idle. The baseline. The character is upright and symmetrical. The hitbox sits tightly around the core body — not the hair, not where the weapon will be. The parts that should be physically solid in the world. This box becomes the reference point everything else is measured against.
Run. The body profile does not change dramatically across the run cycle, but the legs kick back further than the first frame shows. The hitbox needs to extend slightly to account for the full leg extension during the stride.
Jump. The first frame shows the crouch at takeoff. The full arc extends the legs significantly. The hitbox needs to cover the middle ground. One hard constraint: if all tiles are 32 pixels wide, the jump hitbox cannot exceed 32 pixels in width. The character needs to fit through single-tile gaps cleanly.
Shooter stance. Unlike run or jump where the majority state is relatively centered, the shooter stance has the arm extended forward for most of its duration. That extended position is the majority state. The hitbox extends forward to cover it.
Crouch. The most critical one for platformers. The character needs to fit through single-tile gaps. The crouch hitbox cannot exceed the tile height — and in practice needs to be slightly under that to clear gaps cleanly. This is the animation that causes the most broken behavior when the hitbox is wrong.
Debug collision boxes: confirming what the engine actually sees
Setting the hitboxes in the editor is not the final step. Testing them in the game is. The Alignment Editor shows a static first frame. It cannot show how the hitbox behaves at gameplay speed, how it interacts with the physics system, or whether anything in the rendering is offsetting it.
Enable debug collision boxes during runtime. Run through every animation state and watch what the engine actually sees. If anything is wrong, the debug view will show it immediately.
The loop: set, test, catch, fix, confirm. Run through it for every animation until the debug view shows clean, consistent collisions across all states. Do not skip this step. The editor gives you a starting point. The game confirms whether it worked.
What the full series built
Four videos. One pixel art character. Two completely different games. Here is the full arc:
- The manifest system gave us clean, separate game configurations from one source of truth
- Makko Art Studio gave us genre-specific animations built for the feel of each world
- The Alignment Editor gave us correct scale and anchor points per game without touching the source art
- The hitbox workflow closed the loop — making the character physically accurate across every animation state
One character. Two worlds. A pipeline that grows with your project without creating debt you have to manage later.
Start Building Now at Makko AI
For detailed walkthroughs and live feature demos, visit the Makko YouTube channel.
Top comments (0)