DeadZones: Part Two

Previously on DeadZone: In The Part One, our capsule man couldn’t sit still thinking of all the fun he could be having in Part The Two. Little did he know that we added a signal threshold, locked him down to the ground! Welcome, to DeadZone: The Part Two: The Square DeadZone: Colon Central.

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

Compare and contrast. White crawls in all sorts of directions like a quietly drunk man, while Red stays stock still, until absolutely signalled to move. However, Red lacks the fidelity of movement speed and heading that White does; Red can’t even move at slow speeds, and when it starts to move, it thrusts up to half its natural pace as the stick is deflected out of the DeadZone. Similarly, directions “snap” to cardinal directions, while being more “analogue” around diagonals.

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("JoystickAxisY"));

//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.y) < 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.

Valid outputs when inputs are filtered through a “Square Deadzones”

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 all the way from half speed to full speed in 8 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. Probably don’t do this. It sounds not great.)

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 initial article! With a DeadZone higher than about 0.8, you may never receive corner inputs in the first place!

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 providing input  in the corners due to a  larger DeadZone.

A Note on DeadZone sizes

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 DeadZone 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 for their particular controller.

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 ).

The underlying code for a DeadZone in 2 axes is pretty trivial in of itself (and you’ll probably do it as par for the course), but I’d warn that creating a nice user interface for people to tweak it is going to the brunt of the work, so you may want to consider the tradeoff. 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.

Another thing to note is that you may find that the input ranges from both sticks on an XBox controller, or PS3 controller, many not be identical; you should plan to have one DeadZone per stick.

Conclusion

This “Square DeadZone” approach is not ideal for a lot of games, and games which pick the wrong style of DeadZone can feel “off”. A great example is Zuma on XBLA. The game requires precise 360 degree aiming, and yet, a square DeadZone is used, meaning that aiming around North, South, East, and West is “snappy” and distracting. The game is by no means totally undermined by this, and some games may have valid reasons to snap to cardinal directions (it’s quite useful in FPS aiming controls – to maintain a level rotation vs. the player’s horizon), but it’s really worth considering the needs of your game, and what style of filtering suits it best.

So what’s the major alternative to Square DeadZone? I think you can already guess…

 Previous Part | Next Part

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>