The biggest risks that we have in the upcoming week is the latency of a swing being reflected on the graphics and how accurately the graphics reflect the motion of the swing. If there is too much latency from data transfer between the VR headset and the paddle, we can work on shortening the sampling period to try to identify and analyze as little IMU data as possible before sending information to the headset. We don’t expect there to be problems with how accurately the graphics reflect the motion of the swing, but if problems do come up, we need to figure out exactly what motions correspond to what swing types and make sure to explain that to the users in a help screen.
Nothing this week has been done to change how the system works. How it works now is that the game sends the paddle a signal of when to start sampling data. The IMU samples an amount of data and analyzes to figure out the swing type, power, and direction and sends these swing parameters to the game, where it triggers the proper swing animation and paddle-ball interaction. The game is run on a dedicated server, but the paddle is controlled by each player and the player’s VR headset sends paddle state to the server and transitively the other player as well.
Last week, William and Henry were able to get the IMU integrated into the game and player swings can now be seen on the game with low latency. Next week, everyone is going to be working on making the game more playable. This includes getting the final testing metrics, adjusting animations, tuning thresholds for swing power and direction, and adding features like scoring into the game.