Production

Browser Controller

I have successfully implemented the browser controller, which currently works on most Android and iOS devices. The system implements WebSockets to make a connection to the server then feeds touch data through the socket connection. The interface as it stands currently allows for a large amount of future customization and alteration.

The current control scheme is a slight alteration of the Twin-Sticks scheme available through the Android App, with the caveat that the center of each stick is set to the position the touch input begins. An new scheme that is planned, but has not yet been implemented, is a somewhat gesture based input, where the input is based not on the delta from the center of the joystick(where the touch began) but on the delta between touchmove events.

Improving Character Motion

Another aspect of the input that we are working on is the slipperiness of the character when moving. The character currently moves based on forces being applied to a rigidbody that is part of the character, which is an effective way of maintaining realistic interactions between the player and other objects. The downside, however, is that because motion is created by force being applied to the unit, that it slides, rather than immediately changing directions when input is changed.

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.

Production

Second Semester

After a break of a month, it's time for production to resume for the final 4 month. We've added 5 new team members to Phlegmatic Studios and are looking forward to working with them to improve our game as much as we can. We have a lot of ideas to discuss and decide upon and even more work to get done before the Senior Show in April.

Improvements

There are a few key areas that we, as a team, have decided we need to focus on first. The highest priority of these being the control scheme. Throughout the first few months of production, we mainly used a "twin-stick" configuration for controls, with two virtual joysticks as the method of input on the device, but as testing and feedback have shown time and time again: this isn't where we should be. Testers have found it lacking in many ways and desire something better. Our first task is to figure out what that "better" is and implement it as quickly and effectively as possible.

The next high priority area that we need to focus on is the aesthetic and theme of the world. As it stands right now, players are dropped in a pretty generic and empty feeling factory environment.

While it has worked for us up to this point, we have decided that we need to push it, either locking down on the factory setting by making the level more like an assembly line, or by taking it somewhere else entirely. The primary alternative idea, at the moment, it a Dr Sues feel, with comical looking machinery and strange devices whirling and buzzing around the level.

With these two primary points of focus in mind, we resume our work with new team members providing fresh and interesting new ideas that will take our project to new heights.