Instead of talking about what I said I would talk about in the last post, I’m going to talk about what has been consuming my nights and days recently – Game Feel. Especially game feel with regards to input and controls.
Controls. Like few other things in game creation, bad controls can render your game nigh unplayable if not at least unpleasant to play. It’s because of this that I’ve spent a fair amount of time recently investing into the controls of Reborn. Whether that’s paid off remains to be seen, but intent has to count for something… right?
I’m currently reading a book called Game Feel which tries to more clearly articulate how a game feels to play and assign metrics and explanations to why different games feel the way they do. It’s been a really interesting read so far and gave me an idea on how to analyse my game and improve the feel of the controls. Using an idea mentioned in the book, I created a system which enables me to graph various values in my game and see how input changes those values.
I created it partly in the hope that a hard metric like this would actually help me at all and partly out of curiosity about what kind of graphs my game would create. I am happy to say that not only has it helped me tune my game much closer to how I wanted it to feel but I got to see some SUPER interesting graphs too!
In this “Game Feel” book, they use the concept of ADSR envelopes to analyse input and movement in games. If you want a more in depth explanation on the concept of ADSR, I really suggest reading the book. It’ll do a way better job than me. I’m more familiar with the concept from playing guitar and tinkering with amps and effects pedals where it’s used to analyse to sonic character of an instrument. ADSR stands for Attack-Decay-Sustain-Release and is a way of dividing up an sound’s volume over time.
For something like a piano, the “attack” is the period from when the key is first pressed to when the maximum volume is reached; the “decay” is when the volume dips from this maximum down to a stable volume level; the “sustain” is how long this stable volume level is held for and the “release” is the period from when the key is released to when the volume hits zero again. Applied to a game character, the run key is pressed and the character hits his maximum run speed (attack), the character continues to run for a bit (sustain), the run key is released and the character stops (release). Most games seem not to use a decay in the movement speed. Armed with this new knowledge I dug into my game to try to figure out what was what.
I started by analysing my character’s movement speed over time. In the graphs below, you can see the increase in the value (attack), the continued run (sustain), and the deceleration after run is released (release).
Firstly, my movement was feeling too twitchy which is fine and was feeling good, but wasn’t weighty like I wanted the character to feel. From the graph I could see that the acceleration was too fast and linear and for some reason there was an exponential component in the deceleration (which was a bug I probably wouldn’t have found otherwise).
So after a bunch of tweaking and bug fixing, I arrived at this. An exponential acceleration, so that as soon as the run key is pressed there is a big and obvious change in the character’s motion, but not completely linear so it feels more organic and heavy, and a longer linear deceleration. So far so good.
Next I checked that the jump was behaving as I expected and thankfully it was. This graph shows the vertical speed of the character. When the line’s in the center of the graph the character isn’t moving vertically, above he’s moving upwards and below he’s moving downward. With the high jump (the first jump in the graph) we can see the character very quickly accelerate upwards, slowly decelerate and reach the apex of the jump, hang there for a bit and then accelerate downwards until he hits the ground. In the short jump where the player releases the jump button before the jump apex to alter the eventual jump height (second jump in the graph), we can see the character accelerate upwards, the acceleration gets cuts short by the release of the jump button, the character hangs for a bit and then slams back to ground. Woot!
I sent my prototype out to get play tested by some friends and most seemed to like the way the controls were feeling, but I got two reports of the the dodging mechanic feeling “weird”/”abrupt”. So back into the graph to see what the problem could be. The movement speed during a dodge looked like this. I wanted the explosive acceleration but maybe the deceleration was too fast? So I reduced that, sent it back but no love. Still feeling weird. I was a bit lost and was ready to write it off as “different strokes for different folks” but after some more play testing I noticed what the graph looked like if you dodged while running.
Ahhh… So if u dodged during a run, the character was decelerating to a standstill and having to build up his speed again giving a feel of momentum loss. Possibly what the testers were experiencing, so after some tweaks later:
A nice smooth transition between running and dodging sans momentum loss. Hooray. I may have fixed that issue, but I suspect this will introduce another issue of making dodging the optimal method of locomotion around the level resulting in players just dodging everywhere which isn’t really ideal. I think I’ll have to do something about that like put a cooldown on the dodge, or go back to the original behaviour but push it even further so that the player is rooted to the spot for a short time before they can move again. After all, the dodge is supposed to be used to escape danger and evade attacks not to just run faster, but that’s a problem for another day 😉
That’s it. I hope this has given you some ideas on how to analyse the input and control in your own game and make things feel better, or at least some insight into how I’m muddling through it. If you have some other ideas let me know. I’m always keen to learn new ways to improve my games.