From Sonic Retro
|Sonic Physics Guide
- The research applies to all four of the Sega Mega Drive games and Sonic CD.
- There are 2 main ways objects interact with the Player. Hitboxes (like rings and bumpers), and solidity (like spikes or push blocks).
- Hitboxes sizes and trigger areas for specific objects are shown in Game Objects and Game Enemies.
The Player and other objects such as rings, enemies, and bumpers have a hitbox, which is a general rectangular area that will trigger some kind of reaction with the Player when both their hitboxes overlap. Object hitboxes are centred on the object's X Position and Y Position.
The Player can only react to 1 hitbox per frame, and that will be the first one they happen to check they are making contact with, even if overlapping multiple.
While objects can freely define their Width Radius and Height Radius as they choose, when it comes to their hitboxes, they have to choose from a predefined list of radius size pairs.
Here's an snippet example list of some of the available hitbox radius values, taken from Sonic 3 & Knuckles.
In your own game, you do not need to set hitbox sizes up like this as it provides no extra accuracy while playing, however it's worth noting as a limitation the original games had.
Hitboxes have to touch, well - overlap, to react. Overlap is the keyword here, if any pixel of the Player's hitbox is overlapping a pixel of an object's hitbox this will trigger the reaction from the object. The hitboxes just being right next to each other does not count.
So when they touch, some kind of reaction will occur. The type of which is determined by the hitbox type (which is actually just a general "reaction type" variable the objects have):
These hitboxes are used by both Badniks and Bosses, and are attackable when curled but damage the Player when they are not curled up. The reaction to touching an attackable Badnik or Boss hitbox on the Player is getting hit and ring loss, while the reaction on the Player when curled is rebounding (and damaging the Boss/destroying the Badnik)
Routine Counter Increment
This type of hitbox simply moves to the next routine of the object, used by objects like Rings and Item Monitors.
Any contact with these will immediately give damage to the Player. Examples are the spikes on the GHZ log bridge, the spikes under a MZ Spike Trap (though most spikes don't use hitboxes at all and are solid objects), and certain projectiles.
These hitboxes result in different reactions based specific conditions, used by objects like the body segments of Caterkillers.
The Player's Hitbox
In order to interact with other object's hitboxes, the Player needs their own.
The Player's hitbox is much like that of any other object. It sits at the their X Position and Y Position. It has a width radius of 8, and its height radius is always 3 pixels shorter than the Player's Height Radius, making it 17 x 33 pixels in size while standing.
When crouching, the Player's hitbox needs to shrink. Problem is, the Player's Y Position and Height Radius don't actually change at all while crouching. So to tackle this the game manually updates the hitbox's size and position while the Player crouches, where 12 pixels is added to the hitbox's Y position, and the hitbox's height radius is set to 10. This only applies to Sonic. In Sonic 3 onwards, crouching does not affect the hitbox at all for any character.
Quirks With Hitboxes
Because these hitboxes aren't even numbered in size, and because object origins don't lay perfectly centred between pixels (see Basics) most hitboxes will also appear 1 pixel too big on the right side and the bottom side. This is simply how things work in-game and for that reason won't be ignored. Sprites like rings are even-numbered sizes (such as 16 x 16) so an anomaly like the following can (and does, always) occur.
Rings can be collected from one direction sooner than the other, you can try it yourself via debug mode. As long as the sprite of the ring is 4 pixels out from the tiles on each side, you'll experience this inconsistency. A Ring's hitbox is defined as a width radius of 6, but this results in a box with a width of 13 rather than 12. Because all sprites like this are an even size, but their hitbox must be odd, the box cannot be perfectly set on the sprite and will be larger to the left and bottom.
This is the case with any object's hitboxes.
Sometimes an object will forgo the hitbox system entirely and instead perform it's own custom checks on the Player's X/Y Position, checking if it is within some kind of rectangle. An example of this is the Checkpoint object.
This serves the same purpose as hitboxes, but is fundamentally different. For one, the check happens within the object's own code, while hitboxes are checked at the end of the Player's code which occurs before any other object code. Secondly, a trigger can be a rectangle of any size, without using radius values. So they will be described as having a top left position, and a complete width and complete height. Just a normal rectangle. What you see is what you get with these.
Typically, the reason this is done for certain objects is when the area needs to be checked in perpetuity (as opposed to making contact once for a rebound or destroying an object), or in the case it may commonly overlap other hitboxes. This ensures it won't "override" any other hitboxes, or get overridden itself. That's why important objects such as Checkpoints and Air Bubbles use Triggers.
Because these are totally separate and do not involve the Player's hitbox at all, they will be differentiated as "Triggers" or trigger areas.