I was recently exploring a mechanic in which the player doesn’t directly control the motion of the player object in the game. Instead, the player object moves along a consistent sine-wave and the player is given the ability to adjust the amplitude and period of this wave, effectively creating an interesting control scheme that will take a little time to master:

I love messing with alternate control algorithms, but they aren’t as easy to implement as you-push-up-I-go-up schemes. The challenge here is getting the sine wave to adjust itself in relation to the player only. To modify the amplitude or period at any one time is to change the structure of the motion and therefore the player position. This leads to predictable but strange mechanics that don’t make sense in the form of a game. This algorithm, admittedly, took me two weeks to figure out, and in the end it was solved by five lines of algebra and a dash of common sense.

Step 1: Limit Variables (Build a Test Scene)

Trying to test different algorithms inside of the player control code was messy, and soon debug variables and values were running amuck in the previously clean and workable code. If you want to play around, build a test scene! Put it in its own folder and keep it all together. Have a riot.

Step 2: Consolidating Motion

If there’s something you’re going to be changing a lot, please just put it in a function. I found myself switch around variables in three different places in my test code and it got frustrating and confusing quickly. Soon the numbers you predict don’t appear because you forget to change it in multiple places. Put it. In. A. Function.

Step 3: The Simplest Solution is the Best Solution

I tried to use smart ordering to make everything work out nicely, but then I realized that I needed to see where the player is versus where the player might be. They can’t be the same thing, otherwise nothing would change. I ended up hacking out some functions that dealt with their own local variables and predicted future motions. It’s a bit ugly, but I’m just happy it works. Elegance can be achieved in future iterations. Speaking of which…

Step 4: Iterate

Do it. Then do it again. Then get rid of the trash and do it again. Do this eight times over and you might get it. A step forward is a step forward, no matter how small. Rethink what you did and clean up as you go. It seems it takes me a few tries for me to even understand what I just typed out.

Step 5: Write Stuff Down

I might just be a spacial person, but I need to draw diagrams and write things down before I do anything of worth. No amount of intuition can best a well-drawn flow chart. Organize your thoughts, then write the code. Then organize that code. Then organize your thoughts on that code. Getting annoying yet? Good. Do it again.

Amplitude was solved by moving the graph over the amount the player character would be moved by the delta between the old amplitude and new amplitude. It was a classic case of move it, then move it backwards by that same amount.

Period was solved by about twenty attempts and then eventually a few lines of algebra. It became apparent after I realized I only had one variable to deal with.

Just happy I was finally able to nail it. Happy coding!