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