All posts by Rob

Using InControl in Unity for Local Multiplayer, reconnecting controllers

InControl is an awesome plugin developed by the guys at Gallant Games. What it does is allow super easy configuration of multiple input controllers to give similar outputs, meaning you only have to setup the controls for your game once, rather than for every single different type of controller you would like to use. This allowed us to quickly setup NZA to run with Xbox360, PS3, MOGA ect. controllers with minimum effort.

So InControl  is great, but where it falls short a little bit is when a controller disconnects and then reconnects. Now this is not InControls fault, the problem lies with the fact that controllers don’t have unique identification codes , read more here.

How did I get around this problem? Well if the game was singleplayer there is a simple solution, use InControls built in ActiveDevice. This uses whichever device was last touched to give the output, so as soon as the device reconnects it works again. But I have multiple controllers being used at the same time, so ActiveDevice is no good.

So here’s what I did.

When a new player joins the game, they are assigned an InputDevice to there profile. This device is then also added to a static List<InputDevice> “playerDevices” on the GameController. On the PlayerController an int “deviceID” is also assigned for quick reference to the device in “playerDevices”.
Now thats all setup we create an InputDevice “mInputDevice” on the PlayerController like so:

InputDevice mInputDevice{
            return GameController.PlayerDevices[deviceID];

Now the PlayerController will always reference the list in the GameController to find it’s device.

Now we just make a small addition to the InputDevice.cs . Adding the following line lets us keep track of which devices are attached.

public bool active = true;

Now we know if a device is active, we add this to the Attach and Detach events:

void DeviceAttached(InputDevice device){
   Debug.Log"Attached: " + device.Name );

   for (int i=0;  iGameController.PlayerDevices.Counti++) {
       InputDevice InD = GameController.PlayerDevices[i];
       if (!{
          if(InD.Name==device.Name && InD.Meta==device.Meta){

void DeviceDetached(InputDevice device){
    Debug.Log"Detached: " + device.Name );

    foreach(InputDevice InD in GameController.PlayerDevices){
        if (InD==device){

What this does is set the device to be not active when it is disconnected. Then if a new device is connected with the same name and meta data it will automatically assign it to PlayerDevices list, allowing the player to continue playing!

Obviously if another identical controller is connected before the original one, the controllers will switch. But there is nothing that can be done about that.

If you want to remove a player from the game (they quit) then you can just set their device to null (in the PlayerDevices List). This way it wont effect the other devices.

So that’s working so far for me, feel free to post in the comments if you have a better way of doing this!

Sticky Grenades

Working on sticky grenades today, didn’t think it would be too hard. I hoped it would work as follows, throw grenade, wait till grenade hits object, parent grenade to new object and then remove the grenades rigidbody.
Which did work great… On walls…
The trouble was when the grenade attached itself to a zombie, it attached to the main capsule collider not the individual bones of the zombie…

Screen Shot 2014-10-15 at 21.06.34

As the zombies are rigged for ragdolls, it shouldn’t be too hard to use those colliders for the sticky grenades. The problem with this plan is we don’t want the bone colliders interfering with the animations. The easiest way to do this is to make them triggers. So now I have a load of colliders that I want the grenade to stick to, but I want the grenade to ignore the capsule collider.

So I thought of a few ways of doing this, I could make a new physics layer for the grenade which ignores the capsules layer. But that seemed a bit messy.

That’s when I realised that the grenade didn’t actually have to do any colliding, as it could stick to the first thing it hit. Boom, the sticky grenades became triggers, which means the grenade wont physically collide with the capsule. Now using a little bit of extra code to ignore the zombie colliders and everything works!

Screen Shot 2014-10-15 at 21.24.22


What’s going on?

Last week: We were working on the zombies, concentrating on adding characteristics animations. Like them shouting, pointing at a player, going crazy and even pulling off their head and throwing it like a grenade.


We added two more speeds of zombies, crazy fast, and just a bit slower then normal run. Which is going to make the game more difficult and also make it seem more manic. Then we worked on the damage from the zombies so they hit you directly when they swing for you and jump at you. And also now the zombies eat you while you’re on the floor being rag dolled so getting knocked out by your own grenade is a bad idea.sloth_head_sml

A lot of work has been done  on characters, setting up the giraffe and sloth in game as well as creating custom animations to add more characteristic moves to the players. The sloth is meant to have this cool slow swagger. Thinking that he’s chilled in all situations, not a care in the world. Bring on those zombies. He so needs some awesome shades!sloth_customWalk

With the giraffe I was looking at how to make it shorter without making it actually shorter so I thought about giving it a little bit of a hunched back and a curvature of the neck to shorten it would add more character. Created some animations for the walk, run and idle poses to add more hunched look. I think we will have to experiment and keep an eye on it to see if the long neck causes any problems with going through doors etc. modo_giraffe

We are looking to add more to the levels and how to theme them around where we live in the UK. Having animals walking around famous landmarks in London would make the game look awesome. So yesterday we decided to mock up some ideas creating very rough block prototypes of both stone henge and tower bridge. Two totally different types of levels one a small region that all the zombies come to one point and one that the zombies end up charging across the bridge like an army coming to eat you. Pretty awesome on some of the tests, where we put some cars in the way and put all the spawn points for the zombies on one side of the bridge. They all came running towards the player and jumped like made men over the cars. Its MANIC.  Rob created a mockup of Stone Henge to see what it was like to play. A small level where there is just nowhere to hide! They come at you from all angles.

Screen Shot 2014-10-14 at 10.55.38 Screen Shot 2014-10-14 at 12.57.52