Who remembers Uniracers? If not, who remembers Sonic the Hedgehog? In the past few days I've adamantly been trying to find any information I can on the collision detection in Sonic the Hedgehog games. Unforunately, the most I've been able to find is information on ROM hacking and a few fan game coders who have yet to respond. While the information on the ROM hacking sites has proven insightful about how collision information was actually stored, it has not been useful on how collisions are dealt with and handled. Uniracers recently came to mind as a game with similar (perhaps better) physics. In the old days of 16 bit programming, how was motion on slopes and curved surfaces accomplished? I feel like there is a lot to be learned from looking at classic examples, but unfortunately the knowledge doesn't seem to be there unless you're willing (or able) to dive through thousands of lines of assembly code and try to figure it out. People are rapidly moving to 3D as the solution to all their problems in terms of gameplay, but it's no secret that 2D has its nostalgia value. So why are all the tricks of the 2D trade so hard to come by when they seem to be so established? The hidden question in this thread is where are all the veterans, but my actual question is where can I even start when trying to clone a game like Sonic or Uniracers? Traditional tile-based games are easy. Is the block solid, or isn't it. Move in the x, move in the y, correct for collision. So what about speed games with curvy environments where your speed can actually determine your ability to stick to a wall or ceiling? Are there any hints at all for modelling this sort of world? If it was done on 16-bit systems, it can't have been hard. Anyone? Cheers

Yeah, info on old-school game mechanics is practically non-existant online, but luckily I work in handhelds so I have some concept of how it was done.
The answer is mostly finite state machines. Once you have some good data structures, it's pretty easy to detect a collision. The challenge is in responding to it.

In Sonic, there was most likely an 'on the ground' mode, where your Y position gets snapped to the ground level. Then if you jump, switch to 'going up', where you have a constant upward velocity as long as you hold the jump button down, or until a certain amount of time has passed.
When either of those happens, switch to 'falling' mode, where more realistic physics take over, and leave your velocity upward so gravity slows you down gradually before you start to go down. If you collide with the ground, which back to ground mode.

Idle/walk/run/spin were probably seperate states within the more general ground mode. Also, in the 'snap to ground' function, before you snap, make sure the distance to the new ground level is small enough, otherwise switch to falling mode. That will automatically handle walking off edges.

For loops, put a trigger at the bottom of it that says "if you're going fast enough, switch to 'going around a loop' mode, otherwise just stay in normal walking mode". In loop mode, check if your speed gets too low, and if it does switch to walk mode again (which will then switch to fall mode if you're upside down at the top, because of the ground distance check).


The key is in keeping it simple. The physics aren't real at all, it's just a bunch of state transitions that have different movement processes.
Another thing you'll notice is that in most old platform games, when you get hit by a bad guy, you flash and can go through bad guys for a while. That's just a sneaky way to get out of dealing with colliding with more than one sprite at a time :)

The snapping to ground makes sense for another reason. In Sonic, if you had a ledge that immediately dropped off into a half pipe, and you ran straight off the ledge into the half pipe, instead of sliding of the edge and arcing down to the ground due to gravity, you actually take a sudden 90 degree turn downward and start following the half-pipe curve.

I guess I wanted to think of things as being a little bit more feature rich. Here I was trying to figure out how they worked centrifugal force into a Genesis because I was hoping to avoid having special states for things. I guess it's unavoidable though.

Thanks for the tip. Anyone else out there with experience?

Linolium - I would like to take a look. According to the ROM collision information, something similar was done. 8x8 image tiles were combined into 16x16 tiles, which were then tied to collision data that, in two parts, defined where the tile was solid, and what its slope was. The confusing part about that is the part that defined the slope -- it was a single byte which was split in two, for two values between 0 and 15. For visualization, these two numbers would be placed on parallel vertical lines (basically the left and right side of the tile), and the slope of the line formed between them could be interpolated. This was how Sonic games achieved something other than just 0-45-90 degree angles.

What I don't understand is how that schema went beyond 45 degrees.. obviously if one number is 0 and the other is 15, that's 45 degrees (or -45 if the two are flipped). I don't know if there were extra flags to rotate those collision blocks or what.

Also, I know the special sprite you're talking about, it shows up as 4 vertically aligned rings when you're in debug mode. I can't say I like the idea of using an invisible entity to cause collision zone swapping, but sometimes there are necessary evils.

Still, coding on today's computers means I'm not really in need of bit packing, so I guess I can give a tile whatever slope I want. =P

Yeah, hotmal has gotten really screwy about zip files lately. Just rename the extension to .bin or something unused and it doesn't care anymore. I'd like to see your Sonic clone too, if you wouldn't mind shipping it to my screen name here @hotmail.com.

For the sloped tiles, I think they just never have slopes > 45 degrees, except for the loops, and those are probably handled specially as an actual curve rather than a straight slope (much like Linolium's system, I think).

Personally I think invisible entities are a fine way of handling special events. Mostly an easy way to recycle the collision code. It's only a hack if your engine isn't designed for it and forces you to make a transparent image to load :)

Whoops, guess I didn't have it public.

It's gtg661g@mail.gatech.edu