Using Bluetooth on Android Devices to Implement Real-Time Multiplayer Games

1. Brad Boone, Corey Darr, Chris Hayes Using Bluetooth on Android Devices to Implement Real-Time Multiplayer Games

2. Overview • Games use Bluetooth because it does not require rooting phones (and is supported by APIs) • Focus on two-player, real-time gameplay (as opposed to turn-based) • We wanted players to be controlling moving entities that would appear on both screens

3. Pong Game—Division of Processing • Only sending start message • We hoped that concrete rules for ball movement and collision would lead to two independent but identical games • However, latency leads to loss of synchronization • Game devolves into two separate games

4. Pong Game—Division of Processing • Equal division of processing • Which perceived ball position overrules the other? • Does one phone need to be in “charge”? Should this title alternate?

5. Pong Game—Division of Processing • Client-server model • Client receives raw ball position data and collision data • Leads to jerky movement on client side, ball going through paddle • Client only receives info upon ball collision • Missed messages leads to disappearing ball (for a few seconds) • Any lost/corrupted message could be game-breaking

6. Pong Game—Networking • Used modification of Google's Bluetooth chat service code • Allows for low overhead, but only supports sending strings • We had to come up with our own message tags and syntax • Bluetooth was exclusively built into the program through a detailed handler class

7. Top-Down Shooter—Division of Processing • Client-server model w/ event-based messages • Combines fixed-interval sending (for movement) with event-based sending (for critical actions) • Increasing the write buffer's size has removed a lot of packet corruption and mixing • Use of timer-based messaging for movement (because of frequency of touch events)

8. Top-Down Shooter—Latency Calculation • Latency tests every 1000ms (1 sec) as follows: • Latency = (SenderSendTime – SenderReceiveTime) / 2 • Both phones send out latency tests, and the phone on the receiving end is required to respond • Latency hovers around 50ms when players are in the same room

9. Top-Down Shooter—Latency Compensation • Latency hovers around 50ms when players are in the same room • For robots and bullets, game that sends message calculates where that entity will be after the message goes through—given the most recent known latency • A copy of a robot or bullet is made, then its coordinates are modified (using known speed, angle, and location) and this modificd copy is sent

10. Screenshot (Client)—Example of Latency Issues Green circle shows perceived position, whereas orange shows actual position

11. Top-Down Shooter—Networking • Network layer with multiple handlers • Contains a handler between the game and a network interface class, and a separate handler between the network interface and the Bluetooth service • Allows for less coupling and more potential ease of transfer to another wireless protocol • Data sent using JSON • Less overhead than XML • Easy to send messages with multiple pieces of data • Bigger write buffer leads to fewer collisions

12. World An event occurs and is sent to the Game class Game Game sends JSON object with data to Network Interface Network Interface Queues up strings of JSON data and sends them to Bluetooth Connection Service on a timer Bluetooth Connection Service Converts strings to bytes and transmits

13. World Event is executed in game world Game Makes sense of received event and updates game world accordingly Network Event Receiver Passes events on to any Games that are listening Network Interface Forwards message to Network Event Receiver Bluetooth Connection Service Receives bytes, makes string, and sends to Network Interface

14. Conclusion • Since nearly all multiplayer games involve shared resources and entities, a client-server model proves essential, providing unity and structure. Although Bluetooth features significantly less bandwidth than Wi-Fi, it can work for games, given that the developers effectively utilize event-based messaging, allowing the client to process the game locally given the most recent information.

15. Conclusion • Additionally, a data protocol such as JavaScript Object Notation helps send messages that are both easy to parse and low in overhead, helping to keep latency to a minimum. Programmers would also do well to implement a custom network infrastructure, using layers to separate data transfer from gameplay and prevent coupling of classes.

16. Future Work • Games for 3+ players • Should work on a similar game architecture • Multi-hop gameplay • Would require significant expansion of network code • Side note: Wi-Fi • It is outside the scope of this project, but the shooter game is decoupled enough to make adapting to new wireless technologies possible.