A little background, first – I finished my first “real” Flixel game last week, “Inspiration Dave” – it’s a maybe hour-few hour long platformer driven by mechanics of par times and collectible items, as well as silly unlockable secrets…mostly a game to get my feet wet in starting and finishing a game…cutting my teeth, so to speak. Had to fit dev time in between all the schoolwork and obligations I’ve put upon myself, but I managed to put a good chunk of time in over the past 7/8 weeks. Possibly more than I spend on the other stuff. I’m hoping some sponsor will find it in their heart to host it before I give up and just throw it on a bunch of sites. But what matters is that I finished it.
Anyways, player movement. It was a fun thing to think about and implement.
Inspiration Dave started as my first ludum dare entry and attempt at making a game. It was terrible. The difficulty was ridiculously hard and the controls were static and merciless….but I thought it had concepts that could have been expanded on. Anyways, I mostly want to talk about the controls.
My first attempt at controls was this terrible kludge of if statements…it worked, sort of, but putting any sort of flexibility was a massive pain, so I just rehauled the whole thing as a state machine diagram. This was considerably easier. The controls are by no means perfect, but they’re decent for the game I think (You can be the judge if you play it some day!).
Dave has a few states – still, walking, running, jump from walk, jump from run, air drag after walk, air drag after run. By putting Dave in various states, I could transition to other states when certain conditinos are met, thus making debugging movement orders of magnitude more simple. For example, in S_STILL (still state), there are no buttons pressed. Dave has his normal standing frame. If left is pressed, we go to S_WALK, where input is handled – setting velocity to a predetermined number, and so forth. This is more or less how the rest of movement is handled. When Z is held, Dave enters S_RUN – jumping, S_RUN_JUMP, and letting go of directional keys puts you in the air drag state, where you’re slowed down horizontally in air.
These variables were tweaked until things felt okay. One of my biggest issues was figuring out how exactly to change velocity when Dave moves left and right in midair – in some platformers, the fairness of precision jumping (single width block to the next) is a matter of how well this velocity change is taken into account. If you just switch the sign on the velocity, suddenly you’re traveling the other direction and going to miss the platform and must mash left and right to land, if you don’t give enough velocity when switching, it’s easy to go too early or late and be screwed. I think I ended up using some sort of halved velocity with deceleration in my movement scheme. It seems to feel fine.
And that was movement.
A lot had to be tweaked to fit in with the level design – precision jumping between spikes is needed, and we need to give an intuitive way to control jump height, which was handled simply with variable jump height. This way, you can make a short-distance hop, or a short-distance jump over something high, etc.
ambient-melodic 