Platform Collision Demo Pink
Posted: Mon May 03, 2010 2:40 amPink - Platform collision demo
Arrow keys to move: spacebar to jump.
World generates randomly. The seed replaces what should be arrays built by a level editor.
(however, if you like you can design levels in ge and have the blocks fill in the array values on createactor).
About Pink
When we think of platform collisions, most of us tend to think of Super Mario Bros games as 'perfect'. But there is no 'perfect'.
Consider them, if you will, fine-tuned, rather than perfect. You have a player, and a lot of things you want him to be able to do. Yet these things must be tuned to match your intentions, breaking one rule for the sake of relaxing another.
Either mario can stand on one toe, or he can't. Either he runs over a tiny gap, or he falls in it. You have to decide which. There is no perfect, only fine tuned. You think perfect, you think "Mario cannot be inside a block at all" but if you stand on the edge, mario falls off the block. At 1 pixel in, mario falls thru the block (animated to look like he fell 'off' it), and is pushed out the side as he falls. If not for this pixel to fall, mario would not be able to fall between two blocks, as he would then be as wide as the gap (the gap is, now, 2 pixels wider than it appears because of this). It's not perfect, but it works so well for its intended use that you'd call it perfect. But it isn't...Mario can be inside a block sometimes.
Anyway, this demo is very similar to the original super mario bros. The two largest differences are:
1. Mario needs a decent amount of speed to cross a gap, Pink needs very little. Pink is less likely to fall into holes.
2. Pink cannot run -i still have some more work to do on the timing.
Holes are almost a non-issue for pink unless they're at least two spaces wide. You can however, fall down them easily if you stop over them.
Timing and clamping is what it's all about; In the draw actor of player (underneath visual), you can see how all of his speeds are clamped.
The NES was simple to run physics on because the timing was clamped by the very architecture of the system. Needless to say, however, there were certain combinations of acceleration and max velocity that were not allowed (or would result in a buggy collision system and a poor game, and there were many poor games...now you know one of the reasons why).
What this demo still lacks is the relationship of xvelocity to yvelocity; the tolerances for detecting collisions change based on the ratio of these two speeds. (they should change, and i haven't figured out the proper equation for them yet).
What it has now is a combination of speed, accel, and tolerance that work together.
(consider that in mario bros 2, princess and luigi's jumping abilities had to fit into the scheme - luigi couldn't have jumped a little higher or lower, or he'd be out of sync. He had to jump a LOT higher than mario. So their abilities are based on the same math that mario's was. The princess's fall rate was probably a square factor of mario's fall rate...)
Arrow keys to move: spacebar to jump.
World generates randomly. The seed replaces what should be arrays built by a level editor.
(however, if you like you can design levels in ge and have the blocks fill in the array values on createactor).
pink.zip- (52.71 KiB) Downloaded 237 times
About Pink
When we think of platform collisions, most of us tend to think of Super Mario Bros games as 'perfect'. But there is no 'perfect'.
Consider them, if you will, fine-tuned, rather than perfect. You have a player, and a lot of things you want him to be able to do. Yet these things must be tuned to match your intentions, breaking one rule for the sake of relaxing another.
Either mario can stand on one toe, or he can't. Either he runs over a tiny gap, or he falls in it. You have to decide which. There is no perfect, only fine tuned. You think perfect, you think "Mario cannot be inside a block at all" but if you stand on the edge, mario falls off the block. At 1 pixel in, mario falls thru the block (animated to look like he fell 'off' it), and is pushed out the side as he falls. If not for this pixel to fall, mario would not be able to fall between two blocks, as he would then be as wide as the gap (the gap is, now, 2 pixels wider than it appears because of this). It's not perfect, but it works so well for its intended use that you'd call it perfect. But it isn't...Mario can be inside a block sometimes.
Anyway, this demo is very similar to the original super mario bros. The two largest differences are:
1. Mario needs a decent amount of speed to cross a gap, Pink needs very little. Pink is less likely to fall into holes.
2. Pink cannot run -i still have some more work to do on the timing.
Holes are almost a non-issue for pink unless they're at least two spaces wide. You can however, fall down them easily if you stop over them.
Timing and clamping is what it's all about; In the draw actor of player (underneath visual), you can see how all of his speeds are clamped.
The NES was simple to run physics on because the timing was clamped by the very architecture of the system. Needless to say, however, there were certain combinations of acceleration and max velocity that were not allowed (or would result in a buggy collision system and a poor game, and there were many poor games...now you know one of the reasons why).
What this demo still lacks is the relationship of xvelocity to yvelocity; the tolerances for detecting collisions change based on the ratio of these two speeds. (they should change, and i haven't figured out the proper equation for them yet).
What it has now is a combination of speed, accel, and tolerance that work together.
(consider that in mario bros 2, princess and luigi's jumping abilities had to fit into the scheme - luigi couldn't have jumped a little higher or lower, or he'd be out of sync. He had to jump a LOT higher than mario. So their abilities are based on the same math that mario's was. The princess's fall rate was probably a square factor of mario's fall rate...)