Virtual reality is known to be a bit inaccessible due to its high equipment costs. The Samsung Gear is already considered a low-budget VR setup, but the Gear (as well as most other VR headsets) still come with a downfall. VR-headsets typically only have one or two buttons, meaning that games that require complex inputs aren’t supported without buying an external gamepad/controller that pairs specifically with the VR-headset. Google Cardboards don't have any buttons at all!
We brought with us a USB adapter and 4 controllers that we originally intended to play Super Smash Bros. with during breaks, but instead we were able to use those to set up a low-latency input streaming system, allowing up to four players to connect and play at once.
What it does
caVR (pronounced ‘Caviar’), or ‘Cheap Accessible Virtual Reality’, allows users to effortlessly deploy a single server that can stream input to multiple separate game clients. Instead of buying a set of brand-new expensive controllers that are specifically made to pair with their VR headsets, users can play with any old controllers that they have lying around. For example, we used GameCube controllers from 2001!
How we built it
For the server, we used Express and set up web-sockets to establish a persistent real-time connection between the server and the clients (portable VR headsets). For a four-player setup, five clients are used—one to capture and emit signals from the controllers, and one client for each VR headset. We were able to use the gamecube package as an interface to map inputs from the Gamecube controllers into plaintext signals, which are sent from the input client to the server. The server generates packets from the input signals, and broadcasts the packets wirelessly to each of the clients.
We also created a simple demo game in Unity 3D to demonstrate the signal broadcasting capabilities. As a final note, this hack was originally intended for the Google Cardboard (making VR even more accessible), but we were only able to get our hands on Samsung Gears.
Challenges we ran into
Our biggest challenge was getting Unity 3D to work with web sockets. We originally wanted to use Socket.io’s web socket implementation, but quickly found that the only Unity 3D protocol that would interface with Socket.io was extremely outdated. Attempts were made to patch the encoder and decoder classes ourselves, but to no avail. We eventually made our project work with a different web socket package, with some tweaks. On day 2, we also ran into a small issue in which a single controller could control all of the players’ units at once—we were broadcasting our signals correctly, but the signals were being accepted by all units without discrimination. This was quickly resolved by adding unique identifiers to each unit and each signal source. Finding time to sleep was (is) also hard. It’s currently 6:32 AM…
Accomplishments that we're proud of
We're extremely happy with how effective the idea of using a single server to stream packets to separate VR clients ended up being. We had our doubts at first as to whether or not the latency would be absolutely horrid, but it ended up being okay.
What we learned
Many people on our team had experience developing API's in the past, but had less experience with sockets. This experience was an excellent learning opportunity for both server-side development, as well as a huge crash course for everyone in Unity to build our demo.
What's next for caVR
Currently, the server is set up on one of our personal laptops, and the clients all had some setup that had to be done. We'd like to make the caVR system more distributable and easily deployable with just a single command, because we think this can actually be huge for people who want to play games on their Gear or Google Cardboard, and potentially disruptive for the VR accessory industry.