Prototype This!!

Finally squared away the actual movement for the Prof himself... This was actually really agonizing and horrible more due to my lack of experience working with the trig functions of Flash than anything else, but damn this took a long time. I tried about 4 or 5 different methods for controlling the Prof both in and out of the water and I finally settled on a hybrid of vectors and degree modification. In actuality, the player is only in control of the directional vectors which move the Prof around in the gameworld, this allows for the easiest level of switching between aerial and aquatic maneuvering, though moving through the air and moving through the water are very different.

Essentially there are two modes of interaction, one for in the air and one for in the water. When the Prof is in the air, the player can "pull up" or "push down" similarly to a flight simulator. Pulling up will create a certain amount of lift, which is always less than the effect of gravity so the best you can do is glide a bit. Pushing down will increase the downward force in addition to gravity and lets you plummet to the ground more quickly. This is the simpler of the two control schemes, as you just have one acceleration vector which has both directional and magnitude. The rotation of the sprite is calculated by a simple trig function.

When the Prof is in the water, however, it gets horribly complex. First off instead of one vector there is now a scalar velocity value and a unit vector which is the Profs orientation. The rotation of the sprite is calculated with trig using the directional vector, just like above. This is the crux of what I was going for, so that the vectors controlling acceleration would be in control of the rotation of the sprite and not vice versa.

I ran into a problem, however, as previously in order to rotate the Prof in the water I could simply rotate the sprite and re-calculate the directional vector. Now that I wanted the vector to determine the rotation, I had to figure out how to change the vector to simulate an rotational object and maintain it as a unit vector. I've never used this kind of math before so I was fairly out of my element and I wrote about 3 different methods to attempt to change the rotation smoothly, all of which created a total clusterfuck of random rotations and what have you. I never really figured out what was wrong with those algorithms, even though I spent a few hours trying to fix them. I eventually decided to use pure math to control the vectors with a much more elegant solution.

Here it's gonna get triggy and wavey, so bear with me. I created a new value, a 0 - 360 control value which represented the current rotation of the Prof while in the water. From this the directional vector could be calculated and from them the actual sprite could be rotated. Why this is better than simply using the rotation of the sprite as my guide I really don't know anymore, though they seem to be essentially the same thing.

Anyway... The Y component of the vector, which is vertical movement, is determined by a sine wave with no offset. Essentially I use my new rotation control value and feed it into a sine wave every frame, and the control value determines where along a single period waveform the Y component of the vector is. Essentially this means a control value of 90 will make the Y a maximum, a value of 270 will make the Y a maximum negative value and values of 0 and 180 make it zero. The X component is determined the same way, using the same control value, except its waveform is offset by 90, so where Y is zero, X is a maximum (either positive or negative), and where Y is a maximum, X is zero. This is all pretty basic trig, but it took me a while to get up the nerve to trust myself to use it and figure it all out.

The final step was to make the transition from air to water smooth... which was more frustration, but I got it.

This was a pain in the ass, but now it's pretty much what it needs to be. Now it's pretty much all about tweaking for proper results.

ALSO, if you play around with the jumping out of the water, you can see that when the framerate is really low you can jump much higher than when it is high. This is 'cause I haven't decoupled my physics from my framerate... I never had the problem well illustrated to me until this, so It's neat to see the problem in action.