Super Meat Boy Galaxy is a prototype I put together for my friend Tommy’s 30th birthday a bit more than a year ago. I only recently released a video, and it seems to have gained a fair bit of attention.

For me, it was just a bit of a throw away experiment. It was never intended as a “pitch” to make such a game (although Tommy and I discussed something a bit like it a long time ago when working on Goo!). The video started to get interest from various reputable web sites and pretty soon, had more youtube views than every original work of mine, combined. As you might imagine, this made me feel… ehhhh… “great”.

Much to my surprise, some people said they’d like to try it out, or would be quite excited about a game based on the premise of “happy death” 3D platforming. Obviously, this is encouraging to hear, but I’m trying to be realistic about it all. From experience (soul crushing, inescapable experience) I know that going from a playable concept piece to a full game is degrees of magnitude more difficult than pooping out the initial prototype, while the end result is often only a few times more fun (if at all).

Releasing it as a “real” product, for money, has its own issues: I genuinely wouldn’t have the time to support it as it stands, and I haven’t the means or hours in the day to develop it further. And developing it further would be rather a case of “ill gotten gains”, since I’m riding the success of Tommy and Edmund’s fantastic game. Basically, if I could just make prototypes for the rest of my life, that’s what I’d do. All the sweet, none of the sour. But then, I’d never be able to charge for them, so it’s hardly realistic.

Ethically, and practically, I just can’t do anything with this project. Charitably, though…?

To that end, I will be releasing the Super Meat Boy Galaxy prototype. It’s going to cost you, though.

I’ll release the Super Meat Boy Galaxy prototype for free as soon as my demands are met: raise 10,000 quid for The Samaritans, and the prototype will be released, free for all onto the internet.

Windows, Mac, and Linux (when I get around to it) builds will be available in one bundle.

Bear in mind that this is a prototype, and as such will not be as friendly and polished as a final game. Its main purpose was to investigate whether Super Meat Boy’s kinaesthetically pleasing platforming physics could survive the leap to 3D, given the right camera and level layouts.

I’ll probably use a torrent so that costs aren’t eaten up in hosting. I have to figure out how to do that… but it’s cool, I can probably work it out! No worries! There will be other methods of downloading, also, in case your ISPs are weird about that kind of thing. However you get it, it’ll be free to copy and pass around. I *may* have to do something about that music before I release, though.

I’ve chosen The Samaritans to be the beneficiary of these donations. I’m sorry it’s not from an international charity, but… this is for personal and private reasons. I hope you understand.

All donations go through JustGiving.com, which seems like the best way to get money to its target without so many processing fees. Also, it lets you pay what you want, which is good, right?

I’m working on some home-brew which centers around mouse movement for both camera, and gameplay. I use the physics system to determine game objects’ proximity in a lot of cases (i.e. bullets hitting volumes), so I have to use FixedUpdate to push gameplay forward. But I also want smooth mouse based camera movement – ideally as fast as the game can render. My camera also follows around the physics object. But physics and rendering update at different rates.

As a result things seem to fall out of sync, and stutter. Messing with interpolation settings on the rigidbody just doesn’t cut it, especially when you handle physics updates yourself (setting the rigidbody physics to kinematic pretty much nullifies interpolation, I’m pretty sure – correct me if I’m wrong!).

So if things are going out of sync, what can you do to get them in sync? Well, unfortunately, we don’t have control over the mouse polling frequency, but we can tailor physics and rendering rates to get something consistent coming into our game.

Experiment – Looking at the Raw Input

I’ve done a little demo showing what’s happening to sampled inputs when setting different frame rates. Since it’s in a web-player, you may want to right-click and fullscreen to override the Unity WebPlayer’s capping of 50Hz (although it’s possible that simply setting Application.targetFrameRate may override this, even in the web player? I could be wrong there).

Please view the full post to see the Unity content.

The two 3D graphs show what values you’re grabbing when you sample your mouse as a 2D axis, with time being the third axis:

Vector2 GetRawAxisNow()
 {
 return new Vector2(Input.GetAxisRaw("Mouse X"), Input.GetAxisRaw("Mouse Y"));
 }

The top one samples from within void Update(), whereas the bottom is sampling from within void FixedUpdate() – the physics update call on every MonoBehaviour.

The two sliders at the bottom control Application.targetFrameRate and Time.fixedDeltaTime. These are what Render Updates and Physics Update rates are effectively “capped” to, respectively. Physics Updates are guaranteed to occur, even at the risk of slowing the game down in real time, whereas render frames drop whenever they like. See this image:

Diagram by Richard Fine (@superpig)

This means you may have multiple physics updates per frame if the rendering is running slower, or none at all if the rendering is much quicker than the physics fixed update. This is in an attempt to keep the game state running in real time, even if the game is rendering too slowly. This isn’t always the way you want to go (many arcade bullet hell games accept gameplay slowdown as a feature - the screen fills with bullets, and the resultant processing bottlenecks means you get gameplay slowdown to help compensate. Most 1vs1 fighting games attempt to have 60fps game play for 60fps input polling), but it’s worth being aware that Unity takes this decoupled approach to meet broader demands.

A Little Analysis

When you set the Application.targetFrameRate very high, you get a lot of spiking of input values – jumping from zero to… whatever was recorded by the polling, and back to zero again.

This is because  GetRawAxis is only giving you pixels moved since the last Update. If you sample twice before the input is sampled again, it has no new information for you, and comes back as zero, even if your mouse seems to be moving smoothly in real life. Unfortunately, there’s no way to change how quickly the mouse is polled in unity, as such. It’s an edge-case desire from the engine for most, but for some kinaesthetic obsessives (like myself and the entire fighting game audience), it’d be really nice to have.

If you set your Application.targetFrameRate frame rate low, your Update frequency gets capped, and sampling GetAxisRaw gives you the accumulated change in pixel position since the last update you checked. So, if your mouse moves right, 5 pixels, stops a short while, then moves left 4 pixels in-between a render frame (and each of these moves is polled), the result that Update reacts to is just 5-4=1 pixel.

You may “miss” the fact that the mouse jerked right then left. The move shows up as a slow move to the right instead of a flick, because you’re getting coarse sampling, and not the individual polled values – just the accumulated travel since the last time you polled in the respective Render or Physics update.

This may occasionally mean that you “miss” the fact that a mouse cursor passed over an area of the screen – i.e. hover over events on a button will likely be missed if your frame rate has dropped – the UI equivalent of physics “tunnelling”.

You could, if you like, do the equivalent of “swept” mouse moves to see if your mouse passes over UI objects at high speed, but this doesn’t account for the peaks of flicking movements. Starts to get awful complicated, huh?

Mouse smoothing is often a useful technique if your frame rate is faster than your mouse sampling, as it can fill in the gaps. Unity builds in their own kind (just use Input.GetAxis, as opposed to GetAxisRaw, and play around with the settings in Edit->Project Settings->Input – and I recommend putting “snap” on if you do – stops axes having too much sense of “momentum” when jerking the mouse in the opposite direction), but you might want to set up your own smoothing systems.

Changing Time.fixedDeltaTime to higher rates than Application.targetFrameRate shows what we already know from Richard’s diagram: that we’re only polling as fast as render updates occur. This is pretty annoying, frankly, because you could have multiple physics frames (i.e. gameplay) reacting to the same inputs just because your rendering has spiked. This is why you really don’t want to use Inputs inside a FixedUpdate() to trigger, say, jumps – you might get two jump impulses because the physics is acting like you’re doing a positive edge button press for two frames in a row! And yet, if your game is in any way physics based, FixedUpdate is pushing forward the more “honest” version of the game state! Best to cache off your own versions of “Input.GetKey” or “Input.GetButton” to determine positive or negative edge presses.

Conclusion

I don’t have any perfect answers to this. This is a hard problem to fix, especially without full control over polling rates and missed data. I also still have a lot to learn about this, and am aware that I’ve only been testing on one machine, here.

But, as for half way fixes and best practices:

In theory, to maintain the smoothest frame rate for mouse inputs, your best bet is to cap your frame rate by setting Application.targetFrameRate close to, or less than the mouse polling frequency.This way you won’t sample faster than the mouse can possibly give input, and thus you’ll get smoother camera motion with respect to input (if your mouse is driving camera rotation directly in Updates/LateUpdate rather than physics).

It’s kinda sensible to do this for a number of reasons – there’s not a great amount of point in a game running faster than you can possibly give meaningful inputs to it – so the rate of a continuous input polling more or less defines what that is (but for obvious reasons, you do want that rate to be high enough to feel like a continuous feedback loop).

If your frame rate exceeds mouse polling, and your mouse is continuously driving anything in the game, you’re probably going to get something kinda jerky because of all these dead polling takes. That’s when smoothing is useful… ish. It can add a sense of momentum to your mouse movements which some people hate. Any interpolation you do for in between frames is, strictly speaking, misleading, and can take away that crisp clean feel that people love from their mice.

Remember that if you’re using physics collisions in any way, then Time.fixedDeltaTime is, in effect, your gameplay turn speed. Thus, if that is out of sync with input polling, you’re going to sometimes get more frames of gameplay than are affectable by your player. If your physics updates become so heavy that it slows gameplay enough miss polling checkpoints, you’re also missing subtle input data – potentially missing entire button presses if you don’t implement your own button check code.

Another technique is to decouple the visual elements which are affected by mouse from physics elements which are affected by the mouse. The visual element plays “catchup” in terms of positioning and rotation. This is quite the rabbit hole which I can’t go into detail on here (i.e. your visualization is not a “true” representation of your game state, but it’s at least a bit smoother).

We’re slightly in the hands of Unity on this one. Since inputs are so fundamental to realtime applications of all walks, I hope that Unity give an input system overhaul some priority, as it can have a negative subconscious effect on a player’s appreciation of a game. Plus, it’s rather ancient. For the most part, this level of accuracy is not going to be missed in a lot of games, but do remember that the highest quality games do put a premium on this stuff.

Currently we have a deflection magnitude vs. output magnitude which looks like this (in red. Old, scribbled out offensive crap in black):

While we’ve gotten rid of the sudden valley around the deadzone, we’ve also somewhat crunched the useful range of inputs into to the remainder of space after the deadzone are has been removed.

What this means, in terms of feel, is that we’ve now got a limited physical deflection area to serve the purpose of “fine control”: a ring of less than 5mm width on the controller which signifies the “mid ground”. Having fine precision is half the point of an analogue control system (even though most games don’t make much use of it other than to acknowledge it exists through walk/run cycle animation blending or unnecessary stealth sections. Nor should they feel the need to use it if it serves no useful purpose.).

Now that we have a gradual relationship from the DeadZone to full deflection, we certainly have something more kinaesthetically pleasing than having the speed jerk up out of nowhere when we cross the haptically invisible DeadZone. Unfortunately, the introduction or “attack” of the slope is still sudden. It’s like skate boarding into a 45 degree ramp: sure, it’s not a brick wall anymore (i.e. the deadzone threshold), but the transition is still very noticeable.

Not only do we worry about the transition, but also we need to worry that the remaining physical range of analogue input serves its purpose, and feels like it’s a true representation of the ergonomic affordances of the input. We need some way of giving the player access to a generous range of low speed inputs for fine tuning. Here’s an intentionally bad example of this which (true story) was actually suggested to me, and I had to be really polite about it, and say “No. Please don’t. I like working here. I don’t want to have to hurt anyone.”:

We don’t want to introduce lots of stepped “mid way” dead zones to approximate “fine control”, as we’ll just have that “invisible threshold” issue that we had with the main dead zone, but multiplied by however many thresholds you choose to have. Trying to find the sweet spot for your analogue input is going to be harder, because you’ll be jumping between speeds which are just a little too fast, or a little too slow (like following NPCs in any first person FPS ever). Where this is a ziggurat, we need a pyramid – a smooth, unstuttering continuous dynamic, which maps nicely into the mind as a simple relationship.

But as mentioned before, we don’t want to feel too much of a beginning of a ramp up as we cross it. Instead, (and this seems to be the industry standard) we could gradually introduce that slope, like a half pipe, as opposed to a straight ramp.

Please view the full post to see the Unity content.

//Power Curves.
 float axisPower = 2.0f;
 float circularPower = 2.0f;

//Use this method for doing a per-axis power curve (not recommended)
 StickInput.x = Mathf.Sign(StickInput.x) * Mathf.Abs(Mathf.Pow(StickInput.x, axisPower));
 StickInput.y = Mathf.Sign(StickInput.y) * Mathf.Abs(Mathf.Pow(StickInput.y, axisPower));

//Use this method for power curving the pure deflection.
 StickInput = StickInput.normalized * Mathf.Pow(StickInput.magnitude, circularPower);

We should divert to a little physiological explanation: When we’re first playing a game, we have no real muscle memory. As a result, our thumbs tend to “search” rather than “choose” the correct pressure on the stick, comparing the fast feedback loop of feel (the pressure of our thumbs on the stick) with the slower loop of visual feedback from the game. Comparing these two inputs (haptic and visual) creates a relationship in our brain (leading to virtual proprioception – our sense of being in a virtual space).

The visual feed back tells us when the haptic feedback is just right for our current purposes, but we are slower to react to it (~100ms for visual processing vs basically instantaneous for haptic feedback): the controller itself can’t tell the player they’ve struck the correct balance – it’s just telling the player “your thumb is here, pushing with this pressure while your avatar/crosshair is moving that fast on screen”, and so we can match that pressure with the in game behavior.

Your thumbs are essentially performing a “divide and conquer search” to find the appropriate pressure to maintain that perfect turn rate in a racing game, or track an enemy as they move across the screen. Since both input and output are gradual continuum, the relationship between the speed in the game and thumb pressure need to line up, too. When this happens, there’s an intuitive connection between thumb pressure and in game speeds, which allow you to increase and release pressure, and feel a consistently correspondent change on screen.

While the thumb-side of the search is using one of the quickest pieces of brain matter you’ve got (the motor cortex), the search is still held up by having to wait for visual feedback. The human search algorithm is repeating as fast as the player can see. But this eventually develops into a  Bayesian Probability model: this is the essence of your muscle memory – hotwiring your brain with your thumbs so that you’re eventually “hard wired” to know the relationship between your thumb pressure and the on screen movement. If you’re at all interested in this sort of thing, it’s better for me to leave you with this video.

Since the thumb “searches” the breadth of possible pressures to find the right spot, the “kink” in the “sudden ramp” version of the game is a real annoyance: the relationship between in game speed and stick deflection feels very arbitrarily split, with no haptics to tell us where the split begins. With the curved version of the deflection graph, as our thumb pushes out, the speed output comes in tangentially to the “flat” of deadzone. There’s no sense of it “starting” abruptly. It’s as if the relationship is continuous – No kink in the feel. It’s a seamless transition from nothing to something.

It also helps that the curve is providing a large area of low speed movement, so that you have a decent “pallette” of low speeds to choose from. And yes, it does cap out suddenly, but, as luck would have it, we have actual physical feedback in the pad (the circular restrictor plate) to tell the player that they’ve hit a limit.

This is actually rather elegant: We’re working the feel of controller into the very fabric of how the game behaves.

One principle we can take from this is that making intuitive controls can often be achieved by trying to make the outcome of the controls a one to one relationship with the controller itself. And this has a lot of implications when it comes to regarding discreet vs. continuous verbs and controls.

The hardware represents neither of these paradigms perfectly, so we’ve made the choice to go with what a user perceives that the input allows. The X & Y axis information available can absolutely give us an approximation of this mental model of the stick’s input, but in cleaning up the maximum and minimum siginals (the upper and lower DeadZones), we’ve created another problem: one of continuity.

Oh look! There's a a huge jump up in output around the DeadZone. Who knew?

The springs are providing a gradually increasing force on our thumbs as they slowly push outwards, but the player character speeds in our demos, when leaving or entering the deadzone, are not gradual at all – they’re sudden and unexpected.

If our actual force vs. travel graph on the stick matched this (which would feel like frictionless thumb movement within the within the deadzone, then a palpable “start” of the spring resistance at the deadzone’s edge), then this model would be right on. But the spring force is always felt, to different degrees, where ever it’s placed, from full force at the extremities to zero at the center: a continuum of reactive force.

Compare this to the feel within the game, where the change in speed almost comes as a shock.  There’s no instant feedback from the haptics of the controller itself to signify that our minute movement should change anything at all (like some kind of a “notch” in the mechanism). We only get feedback via the long route – through the game and back through visual feedback to tell us that we’re actually moving now, even though the stick has been deflected off the center for quite some time.

The physical affordances of the stick suggest a continuum, but the output gives us a sudden jump, and then a gradual increase of speed, as we increase deflection. This creates a kind of “kinaesthetic dissonance” between controls and in game action. We need the jump from “dead” to “not dead” to be gradual in order to better marry the two feels.

So here’s what we do: Code: Re-normalize the range. We’re re-mapping the magnitude of the true input such that at full input deflection, we get full output deflection, but at the deadzone’s beginning, we get a zero output, rather than stepping up suddenly.

Please view the full post to see the Unity content.

Hooray! Starting to feel considerably less like complete thumb-junk! Note that the magnitude readings on the left only occur between 0.5 (our deadzone value) and 1, while the outputs on the right go from zero all the way to one.

We’ve cropped off the noisey extremities through dead zoning (lower and upper bounds), and now we’ve re-mapped the output to the remaining useful input range we received.

But there’s still more we can do!

So, indulge me here as I try to see, with a more analytic hat on, what exactly was going on.

Back when working on Brink, I swore blind that this technique of mapping a square input onto a circle was the way to go with regards to dealing with joystick inputs. I had made the (false) assumption that the values being fed in were the full range of a square, between -1 and 1 on two axes, and that, since the XBox controller was clearly a circular gate, it must be magically mapping the inputs from a kind of Eular angle into a square (i.e. Pitch and Yaw between -45 and +45 on each axis). As Part Zero’s analysis of what inputs are actually passed in, I was horribly mistaken.

I had been working on an aim assistance system for the console versions of the game, doing a lot of research into the best-of-breed, and even adding a few novel additions to the mix to reduce the noticeable gap in fidelity between mouse and controller aiming. I had something working in prototype which, for the most part made aiming really rather painless, without being patronizing, to the point that it had to be toned down so that there was at least some skill involved. I was quite pleased with my cleverness. Ah, the hubris.

But mid way through working on it, something intangible felt wrong with the controls… as hard as I tried, I seemed unable to cast my view in a perfect circle just by easing around its physical limits. I wondered if it was something to do with the deltaTime (the time between rendered frames) dipping when looking at the ground vs. the sky, but I was testing in very basic block-out maps. Rolling the stick under my thumb caused some sort of warping effect which made off-cardinal directions just slightly faster to turn with than pure cardinals. It was very hard to put my finger on. Thumb on. Shut up.

I had assumed that something had to be wrong with the aim assistance code I had prototyped: there were something like 3 or 4 contributing factors to the speed at which you turned for the same input, each of them quite involved, modulating and amplifying one another continuously, based on your surroundings. Rather than turn that stuff off and figure it out by knocking down my assumptions, I let it fester in the back of my mind for a while, while no-one called me to task on it.

Eventually, I happened upon this diagram, and thought I had found the answer to the weirdness, and that I was a darn sight cleverer than everyone else who had ever lived.

Warping a Square into a Circle by using science like in that movie "She's All That"

My attempt at re-mapping inputs in (what I thought was) an elegant way assumes that the inputs we’re getting are supposed to be a square shape, coming from a circle. If that were true (and, I’ll reiterate: it’s not) you’d have to deform that square input, so that you aren’t just throwing away those curved corners of detail by choping off any deflection greater than one unit of magnitude.

Luckily, a real programmer caught the issue in time and fixed it, or that game would have been completely mediocre! Ha ha haa! This is real detail we have to work with:

How much input is actually noticed by the XBox controller vs. how much is implied it notices.

Thus, we are more or less warping an octogon into that “circularized” space.

Please view the full post to see the Unity content.

On the left hand side is a “clamped” upper limit, which simply “chops off” the extra detail we have around the corners. In all honesty, this is all I should have used, if any cap at all.

 StickInput = StickInput.normalized * Mathf.Clamp01(StickInput.magnitude);

On the right hand side of the demo is the “Circularized” version of the input. We’ve taken our incompleted roughly octangular inputs and warped them such that the outer perimeter of the square morphs into a circle, with every point inside it distorting with respect to the ratio of the distance to the square edge vs. the distance to the circle edge (err, always 1) along that angle. I think, anyway.

Vector2 CircularizedInput = new Vector2(StickInput.x * Mathf.Sqrt(1.0f - ((StickInput.y * StickInput.y) / 2.0f)),
 StickInput.y * Mathf.Sqrt(1.0f - ((StickInput.x * StickInput.x) / 2.0f)));

This distortion of an incomplete input square from the 360 controller therefore results in a kind of weird “four leaf clover” mapping. Trying to move the character in a circle ends up being kinda wobbly with the circularized version. Again, it’s subtle, but if you’ve got sensitive thumbs, it’s the sort of irritation which will get under your skin.

Clamping simply destroys any input signal whose deflection exceeds 1. Bending the input onto a sphere maintains the entire signal, but because of the hardware, means we never hit a “True” 1.0 magnitude on the diagonals. Unfortunately, because we’re sending in a pre-cauterized signal, we’re only getting out a part of the distorted range, with respect to deflection. Along the diagonals, the equation expects a magnitude of root 2 to be remapped to a maximum value of 1. However, the biggest input we’re giving is just a little over 1.0, but no-where near the magic 1.414 .

We get a rather distorted/chopped off range of the “continuum” along the diagonals versus the cardinal axes. This makes any partial deflection feel badly weighted – as if we gain faster speeds in the mid zones of the diagonals than we do in the mid zones of the cardinals.

So, once again, there’s really no perfect answer to clamping the extremities just right – it’s a case of picking the least worst approach. I think in this demo’s case, we don’t really want to “warp” the linear deflection differently based on what angle we push the stick in. Therefore I’ll continue by using a simple circular clamp.

However, the idea of “warping” inputs rather than just shutting them down altogether does start us thinking down a different track: we can see that it maintains the continuity of the signal (i.e. this sudden jump from zero speed to half speed due to the 0.5 circular deadzone is pretty harsh!), and that it could have a more intentional affect on how the controls feel.

Previous Part | Next Part (soon)

These “square” deadzones do have their uses (in console FPS games where players mean to sweep their aim perfectly across the horizon, but, when using a “purer” signal, would actually find their aim wavering up and down as they tried. This is one of the subtler forms of aim assistance going on in most console FPS games*) but nothing about the visibly circular restrictive outer limit of the XBox controller screams “make me stick to cardinal directions!”.

Fig 1. A, B, C, D, E, F, G, H & I: These are all lines.

It stands to reason that a circular input wants to result in a circular output: the affordances of the interface should be matched by the expression space inside the game itself. In our example, square dead zones didn’t work in our favour, so let’s try Circular Dead Zones instead.

Please view the full post to see the Unity content.

Now we have a deadzone which doesn’t clamp and deform the direction of the stick. We’re still rid of the “wandering” so notable when there is no DeadZone at all.

Compare and contrast the Square and the Circular deadzones. Note how, instead of a blank cross shape, we have a circular black shape in the center of the output. When we push in a direction, we get that direction in game, rather than it snapping to north, south, east, and west. Great!

Instead of independently DeadZoning the stick axes, we’re DeadZoning the Vector Magnitude – deflection regardless of direction. And as it turns out, the code is a lot more elegant and easy to read than deadzoning the axes separately (in Unity’s API, anyway).

float deadZoneMagnitude = 0.5f;//Yes, still humourously large for the purposes of explanation.
//the ".normalized" version of a vector in unity gives that vector's direction, but not its length... in effect, the length is "1", in the direction the vector was already pointing.
StickInput = StickInput.normalized * (StickInput.magnitude < deadZoneMagnitude ? 0.0f : StickInput.magnitude);//Set the stick magnitude to zero if it's less than the deadzone value. Otherwise, maintain direction and magnitude.

There’s a bit of a problem here, though: Notice how the Magnitude read-out sometimes exceeds 1.0. This is because a deflection reaching into the upper right hand corner (1,1) has a magnitude of root 2 ( Pythagorus! Sqrt(1^2 + 1^2) = 1.41421), which, if you believe in maths, is actually greater than 1.

We don’t get all the way to 1.41421: as mentioned in Part Zero, the stick is physically clamped, and won’t even give us the corner input, though it does give us irritating values which just exceed what we, as players, expect from the interface.

One speculates that this was a hard decision made in producing this interface en mass: it would probably be extortionately expensive to create something perfectly tuned, whilst maintaining any amount of durability.

The least worst compromise seems to have been made: you get a bit more throw in the corners than you expect, just not all the way up to Root 2. And that’s more or less enough to get 90% of the way to a proper representation of the input a player is making.

As users, we believe, due to the design of the controller housing, that we’ve been given the freedom of a 1 unit radius circle, and no more. We actually don’t want more than is implied. It just doesn’t intuitively make sense that the controller would read more than it’s implying it reads. That breaks the implied contract between us and the games we play at a fundamental level. It’s not by a lot, but we’re so subconsciously sensitive to these little irks that it does matter.

In our game’s example, I’m simply multiplying displacement per frame (speed) by the magnitude of the input (which is typical of any analogue based game). This means that at some angles, our character might actually exceed their top speed.

That may be desirable in some designs: it proved to be one of the component parts of strafe jumping in Quake 2 & 3)**, but in our current character controller example, it seems like an arbitrary and bothersome skill to ask of someone to aim their camera at 45 degrees to their heading to gain optimal speed.

There’s a couple of ways to “clamp” this magnitude, thus funneling the implied stick inputs back to to the range they’re supposed to be in. Both approaches have some small issues. You’d think it’d be straightforward, but this nuance deserves another article! Next time, I welcome you to peruse some of my proudest failures in kinaesthetics.

Previous Part | Next Part (Soon!)

*I’d also argue that, considering Part Zero‘s point, that we’re all still fairly inaccurate machines, ourselves, and lean heavily on the guidance of the hardware… so why not allow software to gently steer us in the right direction, too? Not to the point of playing the game for us, but for the sake of meeting our intent half way. More on that much further down the road.

**In the case of first person shooters, the diagonal speed boost makes some amount of sense from a pure dexterity proving point of view – building speed in this way implicitly requires your aiming skill to compensate, since you’ll rarely be moving toward what you’re aiming at if you desire the benefits of increase speed. And that’s fine and dandy on a keyboard where we can accurately read the 4 diagonals. With these haphazardly clamped inputs on controllers, however, we’re not kidding anyone: The benefit of the extra diagonal deflection is so minuscule (about 1mm of “extra” signal vs. the cardinals) that it doesn’t really feel like a fully honed, intentional mechanic could come out of it: all that’s left is an unexpected Kinaesthetic Artifact. As such, that’s the sort of thing that we probably want to clean up at the lowest level of our input engine architecture, lest it permeate unexpectedly into other systems which assume that input magnitude resides between 0 and 1.

If you value your fingers, may I humbly suggest a keyboard with Cherry Switches, i.e. DasKeyboard .com

Please view the full post to see the Unity content.

Compare and contrast. Mr. White crawls in all sorts of directions like a quietly drunk man, while Mr Red stays stock still, until absolutely signalled to move. However, Mr Red lacks the fidelity of movement speed and heading that Mr. White does, jumping up to half his natural pace as the stick is deflected, and unable to properly comb every subtle degree of deflection, or direction. Mr. Red was born to walk straight lines, ideal after he and Mr. White drive home after a heavy night, and get pulled over by the rozzers, but quickly switch seats before the Police Person comes to test their bibability.

Why the heck this happens? This the heck happens because I put this code in (roughly adapted to help obfuscate and confuse):

float squareDeadZoneVal = 0.5f;//This is set a bit too high in the demo, for comedy effect.

//Read in your input (note, in Unity, you'll want to set up your joystick axes in the Input Manager, and try to turn off all their smoothing McGubbins nonsense. That's for kids. You're in Terror Town, now)
Vector2 StickInput = new Vector2(Input.GetAxisRaw("JoystickAxisX"), Input.GetAxisRaw("JoystickAxisXY"));

//Each axes' magnitude is considered separately. If it's less than the squareDeadZoneVal, it's set straight to zero. So obviously awful, but bear with me.
 StickInput = new Vector2(Mathf.Abs(StickInput.x) < squareDeadZoneVal ? 0.0f : StickInput.x, Mathf.Abs(StickInput.z) < squareDeadZoneVal ? 0.0f : StickInput.y);

By simply killing the input signal below a threashold, we stop the character wavering around. This is normally the neophyte coder’s first approach to fixing DeadZones, as it’s obvious enough, and basically does the job. But we are Real Pro Dudes, so we’re going to see what the heck is the big problem with this all the time.

How does this feel? Well, you can clearly come to a stop very easily. Moving in straight forward/back, left/right directions is easy enough, but trying to move in a “North by North West” angle is irritatingly hard to maintain. Just as we think we’ve got the correct angle, it snaps back to North. It’s as if we’ve lost the “angular fidelity” around the cardinal (up,down,left,right) directions, though we maintain some truncated detail around the diagonals. Odd.

Note the joystick blotter after a bit of playing: You end up with a dark, square area at the center of the dead zoned blotter. This can be seen in the blank areas in a “cross” shape. This is because I’m DeadZoning each axis independently, and it’s created a certain amount of artifacting from this type of input filtering. This can actually be useful in circumstances where you want grid- based movement.

There’s even more you can do to make the diagonals purely diagonal, rather than “digital on the cardinals, analogue in the corners”. Add this code to get more of an 8 way joystick effect going:

if (Mathf.Abs(StickInput.x) > squareDeadZoneVal && Mathf.Abs(StickInput.y) > squareDeadZoneVal)
 {
 //Both Axis are providing a signal. Set both to the average of both.
 //This could be done more elegantly, I admit, but you try coding this stuff sober. I don't know what I am doing with my life. It's like I'm stuck in a fog which won't dissipate.
 float averageValueUnsigned = (Mathf.Abs(StickInput.x) + Mathf.Abs(StickInput.y)) /2.0f;
 StickInput.x = Mathf.Sign(StickInput.x) * averageValueUnsigned;
 StickInput.y = Mathf.Sign(StickInput.y) * averageValueUnsigned;
 }

This still maintains the deflection magnitude of the input (i.e. you can move half speed in certain directions). This might be interesting for a game where you want a player to move between squares on a grid, but want to allow them to do it quickly or slowly. But let’s face it. You’re weird. Don’t do this.

If you want to just get digital output from the analogue (i.e. direction “on” or “off”), you might think you could happily set the dead-zone higher, so that there’s no foolin’. But beware the dead corners we noticed in the raw input! More than about 0.8, and you may be culling corner inputs altogether!

If you want to interpret the analogue as a pure, 8 way input, as the Gods of StreetFighter intended, you might as well keep your dead-zone down around 0.3, and just normalize the previous code for any (non zero) input so that you only have 9 possible outputs, rather than risk the sticks not actually reaching a larger dead-zone in the corners.

If you’re veering toward using the analogue deflection in your game, you might be thinking “this dead zone is too big!”. You’re right. It’s at 0.5, which is a bit crazy. In my experience, somewhere between 0.17 and 0.25 is normally a decent enough dead-zone for an analogue control scheme.

It’s also worth noting that battered, worn, old sticks are going to need bigger deadzones because their springs are used up and floppy. I recommend veering toward that upper limit and designing around the issue, instead of crying when people complain that the DeadZone’s not big enough.

Some developers like to give players access to the various axes’ deadzones for this reason (especially on PC, where the zoology of controllers is considered more diverse) (also note, one deadzone value does not fit all sticks on a joystick. Maddening but true).

The underlying code is pretty trivial in of itself (and you’ll probably do it as par for the course). I’d warn that creating a nice user interface for people to tweak it is the brunt of the work, but if it can make just one person not tell you you’re incompetent on an internet forum, surely it’s worth the extra hours or days? Maybe? Failing a full UI treatment, there’s always text config files for people who care hard enough to open notepad for something other than writing tiny cries for help to themselves, and then publishing it on a blog by mistake.

But, what if we don’t want this cardinal-heavy aim that seems to be an artifact of square dead-zones? Say you’re making Zuma for XBox live, where you’re aiming in big sweeping arcs and are counting on good feeling 360 degree sweeps and… actually, yeah, Zuma really messed that up: They used a square dead zone exactly in the wrong place. So what’s the alternative? Yeah, I think you can guess.

 Previous Part | Next Part (Soooon)

Well, yes, admittedly yes. Mostly. Dealing with deadzones is so straightforward in practice that no-one really ends up talking about the subtleties. There are like, 5 subtleties, I’m guessing. Missing these subtleties creates the creeping irritations which undermine a game. So subtle are these that most players won’t be able to articulate why they’ve not been able to engage fully with the game.

Guerrilla Games QA hard at work on KillZone 2 controls. Sure, they look happy. But they are Dutch.

So yes, we need to talk about this stuff. It’s fundamental. It will save you some time and heartache. And although it’s currently focusing on the XBox 360 controller (thanks commenters: I am aware that other devices exist), there are principles here which expand out into other interfaces.

I tend to find that although games come out with great feeling controls, it’s not without a lot of tweaking. One might think of Super Meat Boy’s control scheme as “simple”, but 2 solid man months of work were poured into getting it just right, and it shows. It’s not just for the end user, either: that attention to detail no doubt made a labour of love easier to develop than if the core game play was off for the entire development*.

This trial and error process is expensive: Just one of Tommy Refenes’ man hours lasts about 28 earth days. Don’t be fooled into thinking this is trivial. The iteration involved is always necessary to some degree, but these articles aim to stop you stepping on some obvious, and not-so-obvious landmines.

Below is a simple little character controller: like last time, you can plug in an XBox 360 Controller, click on it, and start moving the guy around. I’m simply moving the origin of this little capsule around over time, based on the “deflection” of the joystick.

Please view the full post to see the Unity content.

With the raw input signal coming from the joystick affecting the character, notice how hard it is to stand on the spot. Not good if you’re looking to get this fella to move around on tight platforms. If your joystick is especially knackered, it’s a nightmare to re-center the stick perfectly, and your character (or reticle, or whatever you’re controlling with raw analogue inputs) slides around, despite the fact that you may not even be touching the stick at all! This is why games almost always add an area around the zero of a joystick where no through-signal is yielded. This is called a “DeadZone”.

Previous Part | Next Part

*Spending every day of development with underwhelming controls is going to get you down. Trust me on this. Trying to add extra features to hide flaws in something so fundamental isn’t fooling anyone, either. Just respect their importance, and fix that shit.

First off, grab a USB 360 controller, and plug it in. No wait! Install the Unity Plugin if you haven’t already. Actually, the order’s not important. Do not freak out! It’s not a big deal! Once you’ve got that sorted, click on the thing below:

Please view the full post to see the Unity content.

If you’ve already got to manipulating your inputs (and there is no way to say that which doesn’t sound completely sexy; sorry, I tried), you’ll see that you’re plastering these two textures with white pixels. There’s no special code distorting the stick’s inputs: this is the raw signal straight from the source. Or, at least, as raw as Unity will give it to you (which, I’m guessing, is as clean as any other API).

Try playing around with the sticks, almost meditating on what you’re doing, and how it feels.

At some point, you’ll find yourself tracing the extremities of the analogue thumbs, moving the sticks in a circular motion, resting on the edges of the controller case’s gate.

In deflecting the sticks to the physical limit of the circular gate housing each stick, you’d expect a perfect circle to be drawn; but something’s off. It seems as though we’re missing the corners of the input! Our interface bandwidth is clipped into a sort beveled square. And to rub it in, the shapes resolved by the left and right sticks aren’t even the same (and this is notably an even worse on the DualShock/SixAxis’s left and right sticks, if memory serves me correctly. Though it probably doesn’t because of this one time when I wasn’t paying attention and I got my head squeezed between two doors on the London Underground, and was totally concussed, and went to work anyway, and wrote hilarious code, and made the coders angry).

Not only are the corners physically out of reach, there’s also some detail at the top, bottom, left and right which is cropped off!

'Sensitive Area'. 'Ignored'. 'Unreachable'. Story of my life.

And yet, while far from perfect, apparently people aren’t throwing their controllers out of windows in disgust. It seems modern video games somehow seem to cope. To figure out why, let’s get you drawing as straight a line as you can. Here, fresh canvas:

Please view the full post to see the Unity content.

You may also notice that it’s pretty difficult to create anything like a straight diagonal line. Lines in cardinal directions (up, down, left, right) are relatively easy to do because the spring pressure exerted to bring the stick back to the center is happening twice: once along the horizontal axis, and once along vertical. You’re essentially finding a “groove” of least resistance in the X and Y axes, and it’s guiding your thumb.

Probably why artists in the games industry don't draw using XBox controllers.

The fact that you can’t draw a diagonal is, frankly, your thumb’s fault (assuming you are using thumbs – I’ve seen incredible streetfighter players with motor neuron disease use only their tongues poking around under their cheeks to pull off amazing combos that I can’t even do). Your thumbs are not as accurate as you hoped: if you try to draw a circle without leaning on the guide rails, you end up with concept art from the now canned PacMan World 4: PacMan World Universe Land (see fig. whatever: right hand side).

You may be able to “lock” your thumb and maintain a position, but the act of moving with finesse feels kind of drunken. Your thumb is trying to balance its force against the reactive force of two springs, and those springs are acting perpendicularly to one another, because that’s what seemed to make sense to the engineers behind the sticks. Your thumb itself doesn’t naturally move better along cardinal axes, because of… evolution I guess?

In fact, I’ve heard some suggest that games should rotate their inputs such that the thumb is regarded on its rotation and bendiness for X and Y inputs, respectively. That might be an idea, but it’s incompatible with the natural grooves found in the XBox controller, due to the axis aligned spring setup. And it also requires calibration per user, so that’s just irritating.

As you move your thumb around, notice the different pressures that feed back. When you try to move through the full deflection range very slowly and gradually, you’re actually moving in little hops as your thumb’s force overcomes the resistant force of the spring, but slightly overcompensates as it beats the static friction, and finds a new equalibrium. The fact that you feel different pressures at different degrees of displacement, or “throw” is really important: That force provides the haptic feedback to feel where your thumb is in the entire range of motion of the stick. You don’t have to look down to see where your thumb is, because you feel the counter-force from the stick, pushing as hard against you as you are against it, in the direction you’re pushing it. That’s sort of the genius of this interface. Compare using an old fashioned “yoke” style joystick with no return springs what so ever, and you immediately grasp how important the gradual return force is to the haptic feedback of the controller.

And when you push hard out to the outer gate/rail of the stick housing, you really feel that you’ve hit the limit – no amount of extra force will yeild further displacement… unless you’re good at tearing phonebooks in half with your bear hands. Yeah I just said “bear hands”. What you gonna do? Tear my phonebooks in half? I don’t even have any, you bear handed buffoon! Use bing ya idiot!

The lines you try to create also seem spotted. This is partly down to  to how frequently the pad is sampled or “Polled” (If any unity users could tell me the default polling, it’d fill in this gap right here: ________________). But when filling in the entire bevelled square (which will take some time!) you may find that some values inside the detectable area are unaccounted for. This might be the result of crunching numbers within drivers and losing detail along the way but it’s mostly that your thumbs (the best thumbs of any animal!) are still not the perfect herald of your intent.

And that’s really the first lesson here: human output, itself, is fuzzy, and interfaces rarely read a pure signal. And depending on how it’s crafted, the interface itself could feed noise back into the signal it’s trying to read – that war of spring vs. thumb you saw as you tried, in vain, to draw a straight line steadily.

There’s easily enough data from the stick to feed into a mechanic which reacts properly to analogue inputs, but we have to accept that there’s some work to do in filtering out the noise from both the player, and the interface.

Good Interface design aims to clean the broad and noisy signals that users can potentially give down to a limited set that they can easily and intentionally give. Often this is by funneling that broad range of inputs into a limited set of actions, cutting back what you can do in the game to what you must do, and ignoring, or at least smoothing, the noisy inbetweens.

On the hardware side, there are also intentional limits to the player’s range of inputs: by physically limiting our interface freedoms (as with the restrictor plate on a joystick), a very clear, but unspoken contract is established between player and game: our unconscious physical ticks, or habits like picking our nose aren’t registered within the game, embarrassing us, making us feel self conscious about the weird ways we move when we’re not watching. Or, I dunno, maybe that’s just me.

Thanks to these physical restrictions (to throw, or to the limit a button must be pressed before registering etc) we can also tell if we gave a signal by mistake, because we feel ourselves physically change the interface, and get a miniature feedback loop from its clunking and clattering about. Every time we instinctively scratch our nose, or cough, our game doesn’t cause our avatar to jump off the closest cliff, because physical interfaces don’t really watch for such things. But if we missed that quick scope shot because we sneezed and pulled the stick off target accidentally, we know it because our thumbs tell us pretty much instantly.

Interpretive interfaces like the Kinect, voice recognition and (to some degree) touch screens, don’t give this naturally haptic feedback, where we intuitively know what signal we’re expressing: our own bodies are almost too intuitive to us for us to really know what they’re doing: try watching yourself dancing on video and try to come away from that feeling better about yourself. If you think you’re great before the video, and awful after, you suffer from proprioceptive self delusion… like the rest of us.

Interfaces are a translator for your intent into machine manageable form. It just so happens that you have horrible grammar, you rarely say what you mean, and they are confused tourists trying to understand your directions through your loud, fake frensch achhsont.

Game developers have a duty to establish a “contract” with the player by giving them an interface, and teaching them the interactions which are actually being listened for in the game. Knowing this, the player accepts that their fuzzy signal is filtered down into the agreed upon in-game action, and, having established this contrivance, they player can feel immersed through the established channels of interaction and feedback, and start to obtain flow.

The key to doing this successfully is to show the player that they are being listened to, how they are being listened to, and by either being successfully devious about filtering the noise in hidden ways, or at least up front about how the noise is overcome via acknowledgement of the interface’s shortcomings.

I’ll be going into various little techniques to do this, hopefully in a useful amount of detail. Next time we continue with the 360 controller to see these principles in action, starting with DeadZones! If it is exciting, I will be the first to write to my minister in mock outrage. Writing about kinaesthetics is awful, and I intend to keep it that way.

Here’s a bonus link to Chris Franklin’s take on Kinaesthetics (I did some co-writing. You can tell my bits from where the sentences just sorta go off like in some meandering direction and you don’t actually think Chris is even going to draw breath because seriously he’ll just read out any old crap I write because he’s a really nice guy and he doesn’t want to offend me even though I thrive on that kind of negative attention since I can’t seem to get any other kind of attention from anyone not even my parents and i’m pretty sure they love me?)

When I was growing up, trying to convince people that games were an art form felt impossible… there I was, a massive fan of my generation’s very own medium, and to everyone around me, it was considered trashy, and base. God I wanted them to love games like I did. But when you’re trying to convince an older generation of their merit, and they’re reading old-school games from the perspective of an old guard of literary criticism, it’s easy to turn snob and refuse to take the medium on its own terms. And what’s a 10 year old going to say to a Professor of English Literature? “In a game, the story is different every time!”. Yep. I actually tried that. Oh God why?

Ouch! My feeling!

So I spent 20 years learning how to write words and sentences and things and how to set up a wordpress just to get back at that old…

No wait.

It took a while, but right after seeing that Doom was the most mature and artistically resonant exemplar of games we could ever possibly strive to conceive, I saw lots of people try to justify games as a worthy medium from many angles: storytelling, visual art, audio design, immersion. I tried to myself, for a while (interactive storytelling being of great interest to me), but the part that I always secretly felt most passionate about, and the thing that always felt skipped over in favour of more traditional readings of games-as-other-mediums, is the thing we find hardest to put into words: how a game “feels”.

Don’t get me wrong: I’ve been utterly floored by the masterful meta-commentary on linearity in Bioshock, the beauty of vistas in Skyrim, the immersive emergence of Deus Ex. But the reason I’ll play a game for ages is to experience a sense of one-ness with the game. That feeling of flow you get when you’re cutting just the right line in Wipeout, or Tux Racer. And every time the art of games was discussed, it felt like caring about this sort of thing, this primitive instinct to move, should bring a sense of guilt to me.

I never wanted to bring it up, out of a sense of inadequacy: I can’t quote Joseph Campbell‘s Monomyth while talking about it, or come up with Ayn Rand Objectivist Philosophy to clothe a system, or make allusions to Spaghetti Westerns in order to bask in the reflected glory of another medium – I’m just too illiterate for that. Telling you that games are a work of art because of how fucking hard I nailed you with a rocket juggle into a rail shot while falling… just doesn’t seem to hit that lofty mark of impressing your relatives at Christmas, and make them feel like you’re not wasting your time.

And yet, I’d say that’s a good proportion of the reason I keep playing games.

I don’t mean to throw dirt at the intellectualization of game development or criticism (I’m just unintentionally good at it), or pull the old “GAmeplay is moer importent tahn graphix and you don’t even need a story” routine. I actually like where some games are going in this respect (even though I’m past the point of trying to get English Professors/my mum to respect what I do for a living).

What I’d rather do is play super-ponce to what I feel is an under-represented factor in the ongoing appeal of games. I want to show you why kinaesthetics are important, how to get them right, and how to be literate about them. I’ll also fight anyone who gets snobby about this area only being interesting to sugar fueled racist 12 year olds playing Call of Duty all night: You see, to the untrained eye, boxing is brawling, but aficionados see ballet. Okay, fight over, knock out in the first round. I wins. PERFECT!

"Hello. Kinaesthetics is like the heart of a game, but not literally, because games don't have hearts unless they're Zelda or made by David Cronenburg. Do you understand?"

I started my career wanting to be a designer. When I realized that I found it impossible to express the sort of feel I wanted to give to a game in words, pictures, or even video (and holy crap did I try), I decided that it’d be easier to show what I meant, even if it was horrible at first. I learnt to code. It changed how I design. It scared some coders, also. Not in a good way.

7 years later, and it’s clear I’m never going to be John Carmack, but with the release of easier tools and languages (Unity3D and C# are my current weapons of choice), I find it more than possible to explain what I mean by example, rather than expecting people to sit through my awful writing style (I’m not really selling this, am I?). And thank God, because writing about kinaesthetics is like dancing about architecture, and getting anyone to read it is like asking me to finish a simile on point.

Still better than the fourth movie.

As I’ve worked on games, I’ve noticed that people aren’t doing much to share information on game feel, despite it often being the difference between people loving a game, and liking-it-but-dropping-the-controller-for-some-reason-they-can’t-put-their-fingers-on.

There are loads of articles on the technicalities of game making. Lots on guiding philosophies. But Kinaesthetics are at the intersection of these: partly about software, partly about hardware and partly about meatware. Since it can get so technical, Kinaesthetic design has been fairly well relegated to the status of “plumbing”. Crucially, this can put it below the tolerance threshold of creatives and high minded designers. It’s seen as an engineering detail which must be stumbled and suffered through before the meat of the game can arise. Except that, in a lot of ways, it is the meat! Or at least, some edible form of cutlery. (Hmm. I warned you about these similies).

Since it can become quite engineering heavy, and is easier to engage with practically rather than theoretically, it’s hard for even those who are passionate about it to be left with terms other than “unresponsive”, “twitchy”, and “loose”. And because it’s so much more subtle than that, this post-it note of a dictionary is not really good enough.

"Unresponsive", "twitchy" and "loose"? There's a joke here which I'm not making.

I find it hard to reconcile the idea that games with orders of magnitude more scope than small indie games are often as not less kinaesthetically pleasing. There are reasons why this often happens (and admittedly, there are a lot of kinaesthetically rubbish indie games, too!), but no reason not to want to fix it. I think it’s partly because we don’t talk about it with the love that we should. We don’t know how. Or we feel silly for trying. Like, me, right now. This is embarrassing and it will not stop!

A Small Indie Game.

While games with horrible kinaesthetics can still have great merit due to other lovable qualities, good kinaesthetics are never going to detract from these. System Shock 2′s core mechanics were often like that scene in the Temple of Doom where the lady has to put her hand in the insect hole and crank a lever, but the combination of all these B- mechanics made an A+ game. Equally, BioShock 2 more or less nailed that side of things, but no-one is blaming the honed controls for the difficulties of sequalitis.

In fact, a good bridge of kinaesthetics into the experience is only going to make those higher level mechanics, or themes, or story, or environment easier to enjoy: the irritation and annoyance of embracing them is cleaned away.

"Hello, I am bad kinaesthetics sitting between you and a nice game, and I got a machete thing!"

When a game feels just right, it’s like standing up in the middle of crowded theater and shooting dead the man who has just answered his mobile phone, and seeing the rest of the audience quietly acknowledge that you did the right thing, and silently agree not to say anything during the ensuing investigation. And then we all enjoy watching The Iron Lady together in peace. And no-one does that slurpy thing at the end of their drink.

No-one is ever upset that a game feels great. No-one really believes that kinaesthetic pleasure retracts from any lofty statements a game has to make. And for all intents and purposes, it’s fundamental to all games ( even GUI heavy, non-time critical games), and yet, despite being a win for everyone involved, it’s often left as an unwanted stepchild.

When designers who are closer to the engineering end of the spectrum (“plumbers”) don’t try to understand designers toward the creative end of the spectrum (“super ponces”), and vice versa, a communications breakdown occurs. The story and the game start to work at odds, with neither side riffing off their jazz partner: Ludonarrative Dissonance tends to occur.

My thesis for this blog is that getting both parties to understand each other, through the common bond of kinaesthetics, is the key to marrying the two. IT WILL SOLVE EVERYTHING!

Okay, not everything.

I’d also like to redress a balance in design focus which has been sliding in a sinister direction of late: In this time of psychology led game design where gamification is often used as a substitute for the intrinsic joy of kinaesthetics, we must remember: we are not merely carrot guzzling robots. We feel.

It’s okay to feel.

PRESS A TO NOT FUCK THIS UP