Production

Implementing an alternative control interface

One of the major goals over the last semester was improving our control interface. Seeing as we are using a mobile device as the control interface, it both limits and opens up a lot of possibilities. More importantly than the actual interface, though, is the accessibility of the interface. Until now, our interface has been in the form of a lightweight Unity app that can be downloaded and installed on Android devices. While this worked extremely well for a majority of people who downloaded the app to play the game, some users found the that their device would not run the Unity application. We were also faced with the limitation of only being on Android, as we don’t currently have the facilities to built to iOS and Unity for WindowsPhone currently lacks the networking functionality we need. With these facts in mind, I set out to develop an alternative interface that would be OS independent and would be able to run on a wider range of devices than the Unity Application. My solution? Websockets.

Implementing WebSockets with Unity

When I started out, I didn’t exactly understand the WebSocket protocol. I’d never used it before, let alone HTML5 in general. I soon came across two promising C# implementations of a WebSocket server that I could potentially run within Unity as an alternative to the Unity Networking we were currently using. They being Alchemy Websockets and WebSocket-Sharp. I quickly realized Alchemy would not be a viable solution, as it is built in .NET 4.0, which Unity does not support. WebSocket-Sharp, on the other hand, was in .NET 3.5(Unity compatible) and even had a Unity Asset Store download available, which was a good indicator for me that it would be Unity compatible, so I set off with it.
This is more or less where I am now, I have WebSocket-Sharp successfully running within a Unity project, accepting connections from a quick html/javascript page I wrote up to connect to it and easily reading information back and forth between clients and the server, basically all of the functionality I need to convert the input system of the game from Unity Networking to WebSockets.

That said, I have hit a few snags now, for one, WebSocket-Sharp seems to leave a socket listener open(when running in the editor) no matter what I do to close it, which is a pretty big issue that I need to solve before I more further towards implementing it into the full game. I’m not sure at the point if it is an issue with Unity and the threads WebSocket-Sharp uses or an endemic issue with WebSocket-Sharp. Further investigation is required.

Leave a Reply

Your email address will not be published. Required fields are marked *