Given the limited amount of time we have left to pull our game together for the greenlight presentation (less than a week at time of writing), I’ve been focusing on specific aspects that needed the most fixing. I met with one of the Game Design professors (Professor Boyd, who helped us decide which ideas to cut), and the thing he emphasized the most was the polish that we needed. Fortunately, we were working on art, sound, and music at the time- however, he did eventually bring up two dreaded words: “Game Feel”.
I say dreaded because “Game Feel” has become a bit of a buzzword among the design students at my college. It’s something that is often talked about and lauded in games that have it, but I’ve never heard described in detail by any of my classmates. And I find that kind of perplexing, since I read Game Feel by Steve Swink for the first time over a year ago.
The cover of Game Feel, by Steve Swink
While I think that a lot of the chapters that go on and on about “soft metrics” (i.e. things you just need to test and tweak) are limited in their usefulness, there are a few chapters that detail how players perceive things on a screen, as well as a chapter on the concept of “ADSR Envelopes” that I think are absolutely indispensable to a designer. I started reading through my copy again, in order to apply the concepts within to Super PAC Bros!
The main thing about game feel that Swink outlines is that games need three things in order to express it: first, they need to allow the player to have real-time control over an avatar of some sort. Turn-based games, such as certain strategy games and RPGs wouldn’t work, since they work in discrete amounts of time, as opposed to being continuously manipulated. Games that also don’t allow for direct control over an avatar, such as most RTSs and older point-and-click adventure games, can’t exhibit this either. In our debate mode, players have direct control over a political candidate in a platforming context.
A Venn diagram of the components of game feel (Swink, pg 69)
Second, the game needs to simulate a physical space, in order to give context for the controls. Swink uses the example of Guitar Hero as a game having somewhat real-time control, but without a space to exert it. The debate levels in our game are perfect for this, since they serve as areas for the players to move around.
Finally, the game needs to have some layer of polish; this is mostly served by audio and visual feedback, which ideally every game should have. This is what really helps players feel like they’re manipulating a physical object, since the point of game feel is to mimic objects in a way that is consistent with our idea of how physics works. This is the area we were focusing on at the time, so this was a good time to finally nail down a sense of weight with the avatars.
Well, how would a person make something feel like it had weight? This is where ADSR Envelopes come in: ADSR stands for “Attack, Decay, Sustain, Release”, which are the four phases of inputs, both digital and physical. Swink uses the example of plucking a guitar string to illustrate: the Attack comes from initially hitting the string, the Decay from the drop in initial volume, the Sustain from holding the note, and the Release from muting the string or letting go of a fret. Believe it or not, this directly correlates to Newtonian physics: an object needs to overcome static friction before it can start moving (Attack), and is then slowed by a smaller kinetic friction value (Decay). The object then moves at a fairly constant speed (Sustain) before being slowed completely by friction or other forces (Release). If an object at least looks like it obeys physics, we will interpret it as doing so.
A generic ADSR envelope, and an ADSR envelope applied to a guitar string (Swink, pg 122)
A generic graph showing the drop between static friction and kinetic friction, which imitates the Attack and Decay in an ADSR envelope
So, in essence, we have to apply physics to our avatars. Previously in Super PAC Bros!, when players moved in the debates, they were always moving at the maximum velocity, which is not how objects behave when force is applied to them. Because of this, I changed the player to be able to accelerate and decelerate by comparing its current speed to the maximum (when increasing) and 0 (when decreasing), and then adding or subtracting a constant velocity to simulate it. This also encouraged me to make a variable jump height- now, if a player pressed the jump button for one frame, they’d go up half of a jump height value. Holding onto the button longer would make their jump increase proportionally based on how long they had been holding the jump button.
Applying these very small things to the game immediately helped the feel, but there’s still a long way to making it feel great. As it is, there’s no way to have players immediately travel downward when their head hits the bottom of a platform- they just stay there until the jump controller stops adding force upwards. Switching directions rapidly also doesn’t cause the player to slow down then accelerate in the opposite direction, which is going to be a very interesting problem to tackle. Still, I feel like this preliminary look at how to apply this idea has set us down the right path, it’s just a matter of taking it further now.
Jared Mitchell 