Local Multiplayer Info

Hi and welcome to the wonderful world of local multiplayer. I'm your host invadererik, you might know me from other great texts, like those awful commit messages I write...

Anyway, enough of that.

InControl

InControl requires that the InputManager of unity have a specific list of inputs even a piece of code that checks that the InputManager is a specific size.

I've commented out that piece of code, and manually merged the inputs that InControl makes with the standard unity ones. Incontrol generates this list if you go to: Edit->ProjectSettings->InControl->Generate Input Manager Asset

I merged this list with the unity one manually by copying the indexes from one text file into the other

Once you have that input handled you want to in code call InControl.Setup(); hopefully only once in the whole project. I've wrapped that in the main root object using InControlSetup.cs. Calling setup again is a bad idea, try not to do this in any other script, for now I have a static variable you can check to see if InControlSetup has ran.

The local multi lobby

In Main.unity there is a gameobject called localMatchLobbyScreen. This has 2 components:

• LocalMultiplayerLobbyController
• LobbyControllerSupport.

LocalMultiplayerLobbyController is basically a ui handling script and LobbyControllerSupport queries Incontrol devices and sends messages to LocalMultiplayerLobbyController so it can handle events from the gamepads.

What mainly happens here is that we have 4 copies of everything 4 cameras, or 1 prefab copied 4 times, and hooked up in order to player index ( ie, 4 players ( player1, player2, player3, player4) ) in that order. And we let any control attach to any player, including 1 keyboard. Hypothetically there could be more than 4 controllers, ie 6 controllers attached, and any of them could be attached to 4 players.

Anyway at the end of this screen you should have a list of players to controller indexes, which is an index of the order in which InControl has placed devices into an array.

The other thing that is setup in this screen is the list of maps and colors. These both come from config.xml, which is initially loaded from resources that is copied into persistent path, consecutively it will be loaded from there.

the level list is simple, just a list of names, the colors are a bit more complex since each main color has 4 hues of that color. We load that data into a list of string names, to list of strings, and later we turn those strings into colors.

We apply those colors to the player by changing the 4 different colors in the shader to the ones that we load from the file.

At the moment we allow any color to be applied to any player, in the future we want to not allow the same color to be used.

Local multiplayer scene

The local multuplayer scene is usually denoted by _local_multi, but really the only one that has latest is level_full_local_multi.

We have a root component called : LocalMultiplayerController that has links to 3 gameobjects: single view, dual view, quad view.

Each of these groups contain copies of the stuff they will use: Here we use the same approach as the lobby, we have 4 copies of player, buggies, cams etc, that we hook up in clockwise order starting from top left, and we make links to these script that are attached to each of the views.

1 | 2

3 | 4

Each view has a ControllerSupport script that you attach the carts to and the Renderers to. Note All these lists need to be of the same size for things to work.

Anyway when scene is enabled, LocalMultiplayerController gets the data that it needs from the lobby scripts using static globals, and then apply settings to the children ControllerSupport scripts and some of their children that might need to know specific things. for example the swing script needs to know if it is keyboard controlled or gamepad driven, see that script for more details.

Overall, for stuff to work correctly, scripts need to know which device they are using and polling that device directly themselves or receiving a message from controller support preferably.