An AI game hitbox prototype should make collision boxes visible before you judge the art, enemy timing, or difficulty. Test the standing box, jump box, attack box, hurt box, wall box, and pickup box in one plain room, because a game feels unfair when the invisible rule disagrees with the visible sprite.
Generated 2D games often look playable before they are honest. The character moves, the slime bumps into you, the sword swings, the coin disappears, and everyone nods because the loop technically works.
Then you miss a jump you swear you made. You take damage from a spike that did not touch your foot. Your attack passes through an enemy's shoulder. The prototype has not failed at polish. It has failed at truth.
This workflow is for browser-first and engine-assisted 2D prototypes where AI helps create the first version, then you tune the physics shape by hand. Godot documents 2D collision shapes and CollisionShape2D. GDevelop documents collision masks for sprite objects. Phaser documents Arcade Physics body sizing, including body size changes that do not resize the parent game object.
Godot
An open-source engine where 2D collision is built from PhysicsBody2D, Area2D, CollisionShape2D, and CollisionPolygon2D nodes. It is the best fit here when you want exact control over body shapes and debug visibility.
GDevelop
A no-code and low-code engine where sprite collision masks can be edited so collisions match the part of the image you actually want to count.
Phaser
A browser game framework with Arcade Physics body sizing APIs, useful when you want collision behavior in code and need to separate the visual sprite from its physics body.
Construct
A visual game engine often used for fast 2D prototypes. It fits this workflow when you want to inspect collision polygons and event logic without writing a physics layer from scratch.
The Sprite Is Not The Body
This is the first thing I want beginners to internalize. The sprite is a drawing. The body is the rule. They may overlap nicely, but they are not the same thing.
AI-generated games blur that distinction because the first build usually arrives with placeholder art, simple physics, and broad rectangular collision. That is fine for a sketch. It becomes a problem when you start tuning difficulty around a box you have never actually looked at.
A fair hitbox is not a perfect outline. It is a readable agreement between what the player sees and what the game counts.
Make The Invisible Rule Loud
Before you redraw the hero, replace the background, or add a second enemy type, turn on debug shapes or draw temporary rectangles over every important collision area. Do it in ugly colors. Make the player body teal, the hurt box red, the attack box yellow, the pickup box green, and the platform edges white.
Now play the prototype without pretending. Does the player's head hit a ceiling before the sprite touches it? Does the sword box start late? Does the enemy hurt box include empty air behind the animation? Does a coin collect when you are still a full step away? Those are not tiny bugs. Those are trust leaks.
Standing body
The basic player collision box should be a little more forgiving than the sprite, especially around hair, capes, weapons, and leaning poses.
If the box hugs every pixel, stylish art becomes accidental punishment.
Jump body
The airborne body should make ledge misses feel explainable. The feet matter more than the silhouette above the waist.
A tall jump box makes ceilings and platform lips feel harsher than they look.
Attack box
The active hit area should match the moment the animation looks dangerous, not the whole swing from windup to recovery.
If the attack box is always on, combat feels mushy because timing stops mattering.
Hurt box
The vulnerable area should usually be smaller than the art. Players accept generous misses faster than unfair hits.
A hurt box that includes empty air will make even simple enemies feel cheap.
Wall box
The player should slide against walls and corners without snagging on decorative pixels or tile seams.
Corner snagging makes movement feel broken even when acceleration and speed are fine.
Pickup box
Collectibles can use a slightly larger area because pickup generosity usually feels good.
If pickups trigger too far away, the player loses the small pleasure of touching the thing.
Do Not Trace The Art
This sounds wrong until you test it. A hitbox that perfectly traces the art is often worse than a simple box. Animation changes every frame. Arms move. Hair bounces. A sword reaches forward. A coat flares behind the character. If collision follows all of that too literally, the rules wobble.
For platforming, I usually want the body a bit narrower than the sprite. For enemy damage, I want the hurt box smaller than the monster looks. For pickups, I want a little generosity. For melee attacks, I want a short active window that lines up with the readable strike. None of that is physically realistic. It is playable.
Hitbox Prototype Smell Test
| Test | Healthy sign | Bad smell |
|---|---|---|
| Jump past a spike | Near misses look scary but do not deal damage | The player takes damage from empty air near the spike tip |
| Land on a platform edge | The player can tell why the landing counted or missed | The character slides off a ledge that looked safe |
| Swing at a small enemy | The hit lands when the dangerous frame visibly overlaps | The sword appears to pass through the enemy |
| Brush a wall while moving | The player slides along the surface cleanly | The body catches on corners or decorative tiles |
| Collect a pickup | The pickup triggers when contact feels intentional | The pickup pops from a distance or refuses a clear touch |
Ask The AI For A Collision Pass
The useful prompt is not "make collision better." That is too vague. Ask for a collision debug pass with visible boxes and named states. You want the tool to expose the rules, not hide them under nicer animation.
Try this: "Add visible debug rectangles for player body, player hurt box, attack hitbox, enemy hurt box, platform collision, hazard damage, and pickup range. Use different colors. Let me toggle them with one key. Keep the level to one room with one platform, one spike, one enemy, and one pickup."
- Keep the test in one room with one enemy, one hazard, one platform, and one pickup.
- Give each collision shape a different color in debug mode.
- Make the player body slightly smaller than the visible sprite.
- Make hazard damage strict enough to look fair from the player feet, not the whole silhouette.
- Give attacks a short active hitbox window instead of one always-on rectangle.
- Add a key or button that toggles debug boxes without changing gameplay.
- Write the current state on screen only while debugging: grounded, airborne, attacking, hurt, invulnerable.
Which Tool Fits This Test
Godot is the cleanest option when you care about exact 2D physics shapes and want to inspect how CollisionShape2D nodes sit under bodies and areas. GDevelop is friendlier when you want to edit sprite masks visually and keep the logic readable. Phaser is good if your project is already a web game and you want to draw your own debug overlays around Arcade Physics bodies. Construct sits in the same practical lane as GDevelop: quick visual iteration, good enough collision inspection, less ceremony than a full engine setup.
Hits feel unfair
The player takes damage before the visual contact is obvious.
Shrink hurt boxes and hazard boxes before changing enemy speed or damage.Attacks feel weak
The weapon art overlaps an enemy but no hit registers.
Move the attack box into the visible strike frame and test timing before adding effects.Movement feels sticky
The character catches on corners, walls, or platform edges.
Simplify the player body and collision tiles before tuning acceleration.If a player would screenshot the moment and say "that did not hit me," believe the screenshot. Your collision prototype exists to make that argument impossible.
FAQ
Should a hitbox match the sprite exactly?
Usually no. Exact outlines look fair in an editor but can feel noisy in motion. A simpler, slightly generous shape is often easier for players to read.
What is the first hitbox to test in an AI game prototype?
Start with the player body and hurt box. If those are dishonest, every hazard, enemy, and platform test becomes harder to trust.
When should I turn off debug boxes?
Keep them available until the main loop survives repeated playtests. You do not need them visible in the final build, but you should be able to toggle them during tuning.
Sources
- docs.godotengine.org/en/stable/tutorials/physics/collision_shapes_2d.html
- docs.godotengine.org/en/stable/classes/class_collisionshape2d.html
- wiki.gdevelop.io/gdevelop5/all-features/collisions
- wiki.gdevelop.io/gdevelop5/objects/sprite/collision-mask
- docs.phaser.io/api-documentation/namespace/physics-arcade-components-size