Game Designer & Programmer


Senior Project - PPJ #11

I’ve had a very productive week of break. I’ve been working steadily on the UI functionality and Drippy is making good progress and will make me millions.

The hardest thing I was anticipating for over break was writing my own input manager to handle input from 4 controllers in the UI elements. Unity’s default method of input handling with UI elements (buttons/toggles) is an event handler that works great, but can only set up the inputs of one controller at any given time. It’s impossible to have multiple Unity event handlers in the same scene, so I realized I would only be able to use unity’s UI stuff for visuals. All of the functionality would have to be custom coded. I was worried about doing this, but on the first two days of break I sat down and busted it out. Weird. Now all 4 controllers have their inputs recognized separately of each other in a much more robust way. Players can now also navigate the label input alphabet and input their own custom labels using the controllers. This was the main thing I was worried about. But holy cow does it work well.

In a basic rundown, I started with something similar to what Tyler did with the player in-game inputs. Each controller is assigned a value by Windows/Unity when it is connected(P1,P2, etc), but that isn’t the value we want, we want our player values to be determined by the order in which players “sign-in” to our game. To bypass that, each player (P1,P2,P3,P4) has a dictionary for their inputs. That way, if windows determines that the players start button is Button_0_3 (the zero button on the third controller), but that player signed in first making them Player1, we can assign Player 1’s inputs to all come from Unity’s 3rd controller classification (i.e. Button_0_3 now is Player1_Start). This dictionary normalizes and organizes all of the inputs so that we can use any input for any controller regardless of the order that they are connected. An example of this dictionary being created is above. Then in the player options script, players initialize the dictionary when the sign in, connect their player number to that dictionary, and then we (programmers) have free reign to use those inputs freely, as shown in picture 2 above. Since multiple input managers can’t exist, I had to also program an navigation system for players to be able to move around the UI elements, mostly the label input screen. On this screen, 30 buttons are available as character inputs to create a custom in-game label for each player. Normally, an event handler would read in the controller inputs and change the selected button accordingly, so I had to duplicate that. Each row of buttons were separated as children objects of a parent object (each row was a parent object). So I used the horizontal inputs to iterate between the children of the “current” parent object (currentRowParentObj.transform.GetChild(n +- 1);) and the vertical inputs to iterate between the same child object, but in different rows as shown in the last image above. This effectively creates an input grid that players can navigate around in using the D-Pad;

I’m super proud of myself and look forward to wrapping up the functionality. I’ve already figured out how to render 3D objects in the menu scene (a problem we were having before), so now I just need to finish up the team/gender selection, get a placeholder in for the controls menu, and then bust out the in-game UI. All is going well and should be done by Christmas.


-Input manager: 4 hrs
-Label remake and navigation: 6hrs
-label select (A button functionality): 1hr
-meeting: 1/2 hr

Total: ~12 hours

Visit our senior project blog here.