Step 1: The original algorithm had an invisible “sensor line” that rode underneath the player, sensing what sort of terrain he was on. Unfortunately, any time he jumped up into a one-way, his collision would turn on and he’d teleport to the top of it.
Step 2: I added two more sensor points right around the player’s knees. Now, only when one of them was in the air, but the foot sensor was on land would it turn collision on. This time, though, he would sometimes be falling so fast that his sensors wouldn’t register the surface of something, and he’d end up stuck in the block.
Step 3: I added another sensor line underneath the first one, which solved the falling problem, but now I noticed he wouldn’t pick up on slopes that weren’t very steep.
Step 4: I changed the placement of the extra sensor line and the sensor points so that the faster he was falling, the further away from the player they’d be looking for information. But I started seeing some really weird inconsistencies that had something to do with the test for downward motion.
Step 5: I got rid of the sensor points (which had become sensor boobs in my code) and changed the extra sensor line to be vertical instead of horizontal, so that it started around his knees, and stretched down to a length that was proportional to his speed. I created a whole new set of subroutines that would calculate an intersection between this line and the surface of the one-way platform. But now if you’re standing at the edge of something it wouldn’t notice.
Step 6: I changed the vertical-line-sensor into a vertical rectangle that stretches downward based off of speed, and rearranged some if-statements. After a couple of minor tweaks to make sure that he wouldn’t flash to a standing animation as he passed upwards through a one-way platform, I think I’ve finally got everything working the way it’s supposed to.
Step 7: Right before posting this and uploading a new build, I decided to do one more run-through, and noticed that still, about one out of every twenty times, he’d fall right through platforms. I spent about three more days adding all sorts of visual tests before I decided to just scrap the code I’d been using to detect intersections (that I’d gotten off of a messageboard) and write my own routine. It worked perfect on the first try. Lesson Learned: Just suck it up and do it yourself; don’t try and cut corner’s by reusing other people’s code.
So, back to the level redesign. In the meantime, I’m going to upload a build with all the collision detection debugging still on; I want you guys to play through it and try to break it. See if you can find any inconsistencies, or anything that would look better differently. You can’t get across that little water mill (yeah, that’s what that brown box by the white box at the water is supposed to be) because the rest of the level is dreadfully not done yet.
Debug Legend:
Green lines are collision boundaries
Pink lines are intersection calculations to the platform surface
Any failed intersection attempt is shown by a blue line and a cyan rectangle to show where the sensor rectangle was.
Red line at his feet is the original sensor line.
Red lines to the left and right are wall sensors.
Translucent red box is the stretching sensor rectangle.
The player will turn pink when he stands on top of a one-way platform.
The current one-way object being tested turns translucent blue
All slopes are also one-way
It looks messy, but this was the only way I could see exactly what the engine was doing behind the scenes. Now that I’ve got it all working, I’ll comment it out (because deleting it feels like a surefire way to jinx myself) and continue work on the level redesign, which shouldn’t take me too much longer.