Problems in developing multiplayer mobile games technical and architecture considerations for superi

1
Problems in developing multiplayer mobile games
technical and architecture considerations for
superior game play

• Aleta Ricciardi. CTO, Kayak Interactive
• Steve Longhurst. Sr. Developer, Iomo

2
Topics

• What additional functionality is needed?
• Architectural possibilities
• What are the technical challenges?
• What do they mean for game play?
• Case Study
• From single player to multiplayer to
  meta-multiplayer

3
my definitions

• multiplayer game
• multiple players provide input to the game
• interactive
• what Im doing directly affects what you might do
• and interdependent
• for the game to progress, players must update
  shared objects
• beyond high-score, ghosting, bingo, bowling,
  community
• a multiplayer game is a distributed application
• application components execute on distinct
  computers must interact with each other to solve
  the problem
• therefore, apply lessons and best practices from
  distributed computing

4
whats the big deal?
Run-time envt of mobile multiplayer is complex!
5
groups and membership

• define and manage membership of each table
• ensure membership agreement as needed
• interaction of membership changes with game play
• policies and user profiles to include and
  exclude players
• if done poorly, games are inconsistent, blocked

6
communication

• communication is key to game play the only way
  to propagate moves
• ensure consistent and reliable delivery of
  messages
• interaction of membership changes with game play
• great attention to scalability! schemas and
  semantics
• if done poorly, games are unfair, very limited,
  inconsistent

7
failure handling

• networks fail, applications fail, players get
  distracted. cannot be anticipated, or
  differentiated
• how to ensure unresponsive players do not impede
  game play
• application-level failure handling, plus core
  membership
• if done poorly, games are unfair, blocked

8
zeus
isis
hera
thor
9
Post Mortem

• (on the surface, everyone benefits except thor!)
• reliable delivery problem
• hera did not receive the move zeusTank message
• distributed message ordering
• thor received both messages but in the wrong
  order
• FIFO, causal, total orders
• Implementation cost vs strong properties
• atomicity
• isis move interrupted the local execution of
  zeuss messages

10
lessons, dogma
Each component must behave correctly in the
presence of failures and amidst the other
components activities
One size does not fit all. Games have different
requirements of failure handling, membership, and
communication
Each component is subject to pathological
run-time scenarios that can completely ruin game
play
But Size does matter -) Different
implementations for large groups. Tradeoffs
between scalability and increasing the likelihood
of entering a pathological case
Research in distributed computing and experiences
from commercial domains should be applied to
developing and delivering mobile multiplayer games
An elegant solution is equal parts proper,
flexible technology and good game design
This logic is complex and involves a lot of
subterranean communication it does not belong
on the device
11
From Single Player to Multiplayer to
Meta-Multiplayer
12
mission

• take Iomos Pub Pool, an existing single player
  device-resident game, and make it
• multiplayer
• cross device platforms
• in an automated tournament
• with other meta-game features
• in 2 months

13
changes to game design

• what is lost in not having a simulated opponent?
• rapid response from opponent
• impose timed turns to keep play engaging
• proper duration is important
• notify other player when turn changes
• need animation and other diversions while its
  not your turn
• device uniformity during game play
• computations must have identical outcomes on all
  devices
• what is encumbered
• connecting, waiting for opponents

animation
14
game design multiplayer complicates these even
more

• whos on first?
• race conditions and bootstrap issues
• changes in turn
• often this is where network errors will further
  complicate
• modular design to pop in new bits
• hot-seat / computer AI / network
• queues / stacks
• threads and schedulers

15
architectural issues

• general principals
• keep multiplayer and meta-game logic off client
• client will supply required inputs
• keep multiplayer and meta-game logic separate
• keep game computations off server
• minimize changes to existing client

16
beyond multiplayer

• automated tournament
• Spy (passive observer) can join table at any time
• intra-table competitiveness
• real-time results capture and display
• all via a single, flexible component tuple space
• store, notify (per subscribed event type)
• put each move in the space as an event
• notify listeners when new event (of type) arrives
• listeners read or take event
• temporary storage events are leased for cleanup
• flexibility
• Begin round, 2min-warning notifications Spy
  changes game replay leader board

see the spy
17
timed turns

• a lot of synchronization issues
• turn duration must be implemented
• on client (distracted player)
• and on server (client not connected, message
  loss, graceless exit)
• failure handling an expired turn
• application-level failure handling
• player forfeits and cedes turn is blocked until
  opponent loses turn
• if detected on client
• if detected on server (lost moves)
• failure handling at beginning/end of game

client time-out
18
thank you!

• aleta_at_kayakinteractive.com
• steve_at_iomo.co.uk

19
animation keep players attention, reassure no
move ! no nw
20
MIDlet times out on player after 60sec block
shot(s), notify of lost turn, reiterate rules,
generate forfeit move
21
opponent is notified of timeout and change in
turn whether through nw lapse or player lapse
22
Spy can join any table at any time receives
appropriate state, replay ability, does not
affect game play