Posted on

Henry’s Status Report for 02/12

This week I was in charge of doing research on/ordering components for our VR headset, bluetooth communications, and game engine.  For the VR headset, I honed in on the Google Cardboard and took a while to see how it worked along with what game engines were compatible with the most recent SDK.  I took about 5-6 hours researching game engines, more specifically Unity and Unreal.  What I mostly focused on were the plugins that were useful to us, especially the Bluetooth plugins that would allow a paddle to communicate with a headset.  The Arduino Bluetooth Plugin for Unity was the most promising plugin I found, but the latency reported from the reviews was too large, which is why I am currently looking at a faster communication channel, Wifi-Direct.  I ended up settling on choosing the Unity game engine because the graphic design is really intuitive and it is compatible with the most recent version of the Google Cardboard SDK while the Unreal game engine is not.

Looking forward, I am on schedule right now but I may fall behind next week because I need to figure out how to send data from paddle to headset and from paddle to server.  The problem is that I may need to end up programming the binding and connections myself instead of using a plugin to reduce latency.  Also, I will also need to spend more time working on some higher-level design planning that will take time away from my work.  But the goal is the create a communication network from paddle to headset and from player to player.

Posted on

Team Status Report for 02/12

Our biggest risk with our product right now is latency, specifically how long it takes for data from the paddle to be processed and sent to the headset.  We are focusing on two aspects to improve latency: communication channels and communication protocols.   For communication channels, we are looking at bluetooth plugins to send paddle orientation data to our headset and AWS servers.  Depending on how fast bluetooth is, we could switch to WiFi-direct among other methods if bluetooth’s latency is too high.  For communication protocols, we are focusing on what data to send and where/when to send it.  Last week we had conversation about sending paddle data to a server, which can project the movement of the ping pong ball and send those projections to each player’s headset.  This creates a buffer of data that limits the amount of network communication and thus lowers latency.  What we are focusing on now is how to hide the delay where the server needs to calculate and send the ball projection data.  We are still working on finalizing the protocols right now, but if there are certain latencies that we cannot optimize, we can sacrifice some of the realism of the game to allow for smoother gameplay.  An example could be having the ball pause for a second at one end of the table to allow the server to calculate the projected movement of the ball towards the player.

Moving forward, we are going to continue to work on our communication protocols as well as researching faster communication channels.  We also received a shipment of our hardware, which we plan on testing out to get comfortable with how it works and look for any problems that we may need to work around.  Everything so far is on schedule.