How did 2D games handle this collision in antiquity?

Started by
7 comments, last by ikarth 10 years, 3 months ago

I'm working on a 2D game (using Unity's new 2D features) and when I carefully study old games (Super Metroid, SOTN) to see how the player collides with the ground, I am lost as to how it is accomplished; how it is handled.

Here is what I notice:

When the player stands on a ledge, they can walk out to the very last pixel of their hit box, This suggests a square collision shape. Easy.

But when the player walks up a slope, it is the very center point of the character that rests on the ground. You can slowly walk up to a slope, and you never start moving upward or downward until the very center of the character touches the slope.

So the collision presents a bit of a contradiction, and becomes very difficult to reproduce with the modern tools I have. If I use a box collision, then I can walk to the very edge of a ledge, but when I walk up a slope I start going up when the farthest corner hits the slope. If I round out the bottom of my character's collision I can move up slopes with the center of my character on the ground, but then I can't walk to the very edge of a ledge because I'll fall off too soon.

How exactly is it even being handled in these older games? I suspect that I can't recreate the exact same method without rebuilding an engine, but even so I am left to wonder how this effect is even created in the first place. I've seen in ROM hacking tools that the levels give special blocks to the sloped ones; they don't simply use an angled collision polygon like modern games would. And yet they still have feats that defy this understanding, like in level 6 of Super Castlevania where you jump across swinging chandeliers. That's not simply angled ground, but moving angles. But yet you can stand on the edge of those ledges, and your feet still don't float above the ground when the angle is sharp.

So how was collision handled in these old games, and how did they keep your feet steady on sloped ground?

Read my webcomic: http://maytiacomic.com/
Follow my progress at: https://eightballgaming.com/

Advertisement

Well, you could have the collision shape actually just be half the width of the sprite, but "slide" based on the direction the sprite is moving.

ie: For ground collisions, the collision shape is width/2, but one side is always at the center of the sprite, and the other side is opposite the direction of motion.

If no ground collision is detected, expand the shape to full width and test again, this way you can still handle edge cases when jumping/falling properly.

Does that sound like it should work?

Waramp.Before you insult a man, walk a mile in his shoes.That way, when you do insult him, you'll be a mile away, and you'll have his shoes.


I've seen in ROM hacking tools that the levels give special blocks to the sloped ones; they don't simply use an angled collision polygon like modern games would.

I think you've answered your own question right there... The interaction (collision and collision response) of the player with each block type was pre-determined i.e, pre-recorded.

In Unity, you could possibly handle that by having two different collision objects for the character and place slopes on a different layer than flat ground. (or use tags instead of layers, but layers tend to be faster if you can swing it)

When checking for flat collisions use the larger rectangle against the "Flat" layer, when checking for sloped collisions use the smaller rectangle using the "Sloped" layer.

The simple answer is that a lot of old-school 2D games don't actually use hitboxes for terrain collision detection (though they are used for detecting collisions between objects). Often, they use sensors instead - basically single points relative to the sprite's origin that are used to probe the tile map for collision.

This is because of the relatively limited RAM and processor speed of those consoles - there typically wasn't enough RAM to actually store hitboxes for all tiles onscreen (much less a whole level or subsection thereof), and if there was, there wasn't enough processing power to test those hitboxes against every object that interacts with terrain (on top of all the other collision detection needed) and still maintain a good frame rate (typically 60.1 fps on NTSC consoles). It was far more efficient to probe the tile map at specific coordinates for information about that tile.

For example, in the 2D Sonic the Hedgehog games, Sonic has two terrain sensors - one at the lower-left corner of his hitbox, and one at the lower-right (when Sonic is standing on top of a roughly horizontal surface; the locations of the sensors changes at times to account for running on vertical surfaces and ceilings). Each terrain tile has metadata indicating the terrain height at each x-coordinate in the tile. When handling terrain collision, each sensor can detect the terrain height at it's horizontal position; if both sensors detect terrain collisions, then Sonic's vertical position is the higher (on screen) of the heights the two sensors report. This is why in a 2D Sonic, if Sonic walks forward slowly along an upward-sloping surface with a dropoff at the end, you can see Sonic's vertical position change abruptly as one sensor passes over the edge of the terrain while the second remains on the ground (which is probably why such terrain configurations are extremely rare in Sonic games).

Mega Man X uses a similar method. X has a primary sensor (located in the center of the bottom edge of his hitbox) that is used to probe the tile map for collisions and terrain height. If the primary sensor doesn't detect a terrain collision, the game then checks his secondary sensors (his lower-left and lower-right corners), and if either of them detects a collision, it uses the relevant edge of that tile to determine X's vertical position. (For example, if the lower-right sensor detects a terrain collision, it uses the height of the left edge of that tile. The secondary sensors are spaced in such a way that it's impossible for both of them to detect terrain collisions if the primary sensor doesn't.)

For rotating terrain objects, like the chandeliers in Super Castlevania or the Koopaling fights in Super Mario World, it's not to difficult to transform the sensor coordinates into the background's local coordinate space when probing, since you have to calculate the necessary transformation matrix to rotate the background in the first place.

Another possible solution is an artistic trick. If the collision data doesn't exactly match the tile art, it's possible to make it look like the very center of the character is on the ground, when it's actually the corners of the hitbox.
http://www.gamedev.net/page/resources/_/technical/game-programming/the-guide-to-implementing-2d-platformers-r2936

The links must flow.

In Sonic there was seperate hit information for every tile. Also some tiles such as the loops and morbius strips didn't really have any collision at all. These were simply scripted sequences that got triggered depending on sonics speed going into the loop. This was also the same for the moving platforms in Sonic.

This is why in a 2D Sonic, if Sonic walks forward slowly along an upward-sloping surface with a dropoff at the end, you can see Sonic's vertical position change abruptly as one sensor passes over the edge of the terrain while the second remains on the ground (which is probably why such terrain configurations are extremely rare in Sonic games).

Hehe, while I was researching different games before making this thread, I found that exact situation in the first level of Super Ghouls and Ghosts. I walked to the very edge and then suddenly dropped eight pixels into the ground. I had no idea how to explain that.

Thank you for this very informative response; it's great to learn about this kind of thing.

Now I just need to figure out how to re-create this effect without having access to the source code.

Thank you for this link! I think I've seen this page before, but I've never read it thoroughly. I will read through it when I next have the time.

Read my webcomic: http://maytiacomic.com/
Follow my progress at: https://eightballgaming.com/

Here's part of the Sonic Physics Guide, which is basically everything you wanted to know about Sonic physics but were afraid to ask: http://info.sonicretro.org/SPG:Solid_Tiles

This topic is closed to new replies.

Advertisement