Multiplayer Android Games _Bluetooth_ by xuyuzhu


									 Using Bluetooth on Android Devices to
Implement Real-Time Multiplayer Games
    Brad Boone, Corey Darr, Chris Hayes
   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
    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
    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?
    Pong Game—Division of Processing
   Client-server model
           Client receives raw ball position data and collision
                  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
            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
           Bluetooth was exclusively built into the program
            through a detailed handler class
       Top-Down Shooter—Division of
   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)
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
           Top-Down Shooter—Latency
   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
Screenshot (Client)—Example of Latency

  Green circle shows perceived position, whereas orange shows actual position
       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
           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
An event occurs and is sent to the Game class           World

Game sends JSON object with data to Network             Game

Queues up strings of JSON data and sends          Network Interface
them to Bluetooth Connection Service on a timer

Converts strings to bytes and transmits               Bluetooth
                                                  Connection Service
      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

Network Interface    Forwards message to Network Event Receiver

    Bluetooth        Receives bytes, makes string, and sends to
Connection Service   Network Interface

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.

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.
                     Future Work

   Games for 3+ players
           Should work on a similar game architecture
   Multi-hop gameplay
           Would require significant expansion of network
   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.

To top