One issue that concerned us this week was how to communicate the position and orientation of an opponent’s paddle to a player. We were worried that the latencies from an opponent’s paddle to a player’s headset would be too much and would cause delayed graphics and drastically affect gameplay. An intermediate fix we have for the MVP is to use bluetooth communication. Since for our MVP, the distance between players isn’t large, we can have an opponent’s paddle connect to a player’s headset and the latency between the two devices is pretty much negligible. For the final product, we discussed adding delays to game to send paddle data, not showing the paddle to an opponent at all, or simplifying the game so that players are within range to have bluetooth connections.
We also made some adjustments to our server design. Before, we were planning on using AWS Gamelift as a gaming server to compute the ping pong ball path. However, because the server’s rate of sending and receiving data is low we decided to switch the server to either one of our computer or AWS EC2. The biggest factors in this switch comes down to pricing, lower latency, and ease of implementing. For example, if our server was one of our computers, we could really quickly set up a bluetooth network for quick communication and our computers should be powerful enough to calculate the ball projection. If the bluetooth connection between computer and paddle are too slow, we can switch to a different communication protocol or use EC2 which can guarantee single digit millisecond latency.
Our schedule looking forward seems to be on schedule. What we are going to be working on this week is data transfer and collecting data from sensors. We should also start implementation of basic graphics for our MVP.