My name is Zac Mascarenas and this is Jackass! No but in all seriousness it was a wild ride getting from day one to the deliverable for capstone showcase, and this blog is here to document some of the hurdles I crashed into.
Issue #1: Using a Dual Shock 4 controller for a local multiplayer game in unity, and the realization that not everyone has 4 Dual Shock 4 controllers just laying around.
So anyone who has ever touched unity ever so slightly knows that Unity is indeed a game engine, but every engine has it's faults. The major one I ran into during development was getting support for multiple players on the same machine. The sure fire method to make sure no one was going to stomp on each others toes is doing such as this...
This is literally defining the same button input but from a different joystick labeled with a different number. Then on top of that utilizing a wrapper class where each function takes in a integer to do a string concatenation just to return the proper input manger call value.
Now this worked for what we had in the very beginning and for a few iterations of the game as we went through rapid development (we only had 20 weeks to develop this game). But what was not a good time was coming to the realization that not many folks own 4 DS4 controllers. At the time we had a few really bad ideas, but it boiled down to about 2.
The first is doing the same as above but specifically with xbox one and xbox 360 controllers. This is a horrible idea if you pursue this route because just getting multiple controllers to work for PS4 took about 100 input manger lines PLUS a pretty beefy wrapper class. To do that twice over with the subsequent wrapper class along with the need to play with some Unity Dark magic to register which controller type is active and sending data is actual hell.
What we pursued was the use of a mobile controller, or rather using your phone as a controller. With the thought process of the Blizzcon 2018 Diablo Immortals announcement, we as a team embraced the meme and acknowledged everyone having phones. From there there was some major R&D on my end to actually get that working. The extreme bare bones method is grabbing Unity's standard assets package and then reworking their cross platform demo for your own needs. The demo essentially set up a car to take in packets sent via a mobile device to move around world space. Reworking it was no real problem because it was mostly jsut setting up multiple variables to temporarily hold and then apply values, which consisted of 4 vector 3, a few floats, and a bunch of Booleans. The real trick came into play with actually connecting a phone to the machine. The way it worked for testing all of this was grabbing the machine's ip address and then manually injecting it into the mobile applications code. This works if you only have one machine you ever want to use or you are only testing out theories.
What ended up happening was a flip of a coin on spending money on a bit of server space for a UDP server or spending money on a Unity Asset called Easy Wifi Controller or EWC. The decision ended up being the EWC choice which had it's pups and downs on its own. So having that as open source I was gonna recreate my own version, but with time slowly crunching away it was one oif those why reinvent the wheel moments. The core idea of the whole asset is to grab the connected internet and utilize that as your local ip within the game and the app. This was what was needed up front, but it also had many under the hood callback events to make sure things disconnected nicely from app to game. From there it was simply making a few more wrapper classes to have EWC input system play nice with our already implemented one for PS4 controllers. This allowed for suport of 8 players on one machine, but also spawned some new problems which we will get to later.
Issue #2: Unity, a game engine that uses a lot of dark magic for controller suppot
Let's call this chapter 2 of using controllers with unity for a local multiplayer game. From the EWC side project that enabled for 8 player support, a new major issue arose that was learning that Unity doesn't assign what we defined as player id's sequentially but more so at random. Essentially it was like having a set of 8 ports and every time a controller joined it occupied literally any open slot without rime or reason instead of being nice and occupying the first slot open starting at position one.
Long Story short for those who don't want the nitty gritty details of what what went down, Buy ReWired and use ReWired if you are using Unity in any version before 2019.2. I could also be too hopeful in Unity 2019.2 but supposedly they are finalizing a new input manger that is similar to that of UE4's which happens to be a core feature of ReWired. SO head this warning, if it is too bare bones of an action input system in the near future of 2019.2 grab ReWired and use it.
Now back to story time. When initially doing research into ways to fix this problem two assets appeared multiple times which were ReWired and InControl. InControl was the cheaper of the two and had lots of controller support but noting on the front of supporting multiplier controller types on the same machine. At least without major overhauls in the source code to catch what I refer to as Dark Magic events that register when a controller is connected. Even after that it still does not fix the whole sequential addition of controllers. At the time we as a group did not want to spend any more money after the EWC purchase. So from there it was a deep dive into the jungle that is controller registration.
The very first thing that popped up and seemed reasonable was using a version of xinput that had a c# wrapper class to integrate real nice into Unity. It did integrate real nice, and gave proper stuff only for xbox controllers, so it was a partial solve to a different problem but not the problem we needed. From there it was using an experimental wrapper class found in a deep dark corner of some random forum that supposedly spliced together xinput with DS4Windows. This ultimately didn't work since windows machines support DS4's now as pure direct input, this may have worked if we used it on an older machine. From there it was working with a fellow programmer to dive into the Russian forums, don't ask me why but those forums tend to have weird and innovative solutions. Which lead us to the french forums, where a Frenchman supposedly wrote a xinput equivalent for DS4's. After having a sit down and translating his code to readable English (using that young high school french class knowledge) it ended up being only the very base features of xinput and still had the persistent problem of sequential controller activation. On our last legs after dragging in the other programmer we buckled after about a months worth of research and put down cash to buy ReWired.
ReWired is a godsend, sort of pricey for your average college student for an asset but none the less a freaking godsend. So ReWired's solution is basically separating the whole IDEA of player from the controller and then reassigning it and subsequent actions internally. Basically we get that young sequential controller adding, no longer a need to redefine multiple versions of the same input for different controllers, as well as like 83 controllers with built in support. So yeah ReWired is one strong boi that answered the problem as well as adding some fun features like using a game cube controller with our game.