Overview
How can several nearby devices behave like one coherent game when connections, timing, ownership, and screen roles are distributed?
PestaLokal turns multiple personal devices into controllers and players while a shared screen presents the common game state.
Problem
Realtime play must remain understandable when devices join, leave, lag, reconnect, or disagree about the latest state on a local network.
Constraints
- Local-network discovery and connectivity
- Lobby ownership and player identity
- Deterministic shared state across devices
- Late joins, disconnects, and reconnection
- Different interaction models for phones and TV
Architecture
One session, multiple devices
Select a device to trace player input and shared state through the local session. Connections illustrate roles, not live network activity.
The session owner coordinates lobby membership and accepted gameplay state. Exact authority rules need protocol evidence.
Local-network messages carry player intent and shared state across devices.
A player device sends input and renders the session state it receives.
Other participants share the same session; presence and reconnection are protocol concerns.
TV Cast presents shared gameplay to the group, with a different interaction role from player phones.
Trace a relationship
Focus or hover a node to highlight its connections. Select to keep it highlighted; select again or press Escape to clear.
Conceptual architecture from the project brief. Arrows show information direction, not live traffic.
Read all responsibilities and connections
- Host / lobby
- The session owner coordinates lobby membership and accepted gameplay state. Exact authority rules need protocol evidence.
- Local WebSocket
- Local-network messages carry player intent and shared state across devices.
- Device B
- A player device sends input and renders the session state it receives.
- Device C / D
- Other participants share the same session; presence and reconnection are protocol concerns.
- Shared TV
- TV Cast presents shared gameplay to the group, with a different interaction role from player phones.
- Host / lobby → Local WebSocket: accepted session state
- Local WebSocket → Host / lobby: player commands
- Local WebSocket → Device B: state updates
- Device B → Local WebSocket: player input
- Local WebSocket → Device C / D: state updates
- Device C / D → Local WebSocket: player input
- Local WebSocket → Shared TV: shared presentation
Engineering decisions
Design rationale from the project brief. Code-level examples and measured tradeoffs are pending verification.
Decision 01
Define one authoritative session state
A clear owner reduces conflict when several clients produce events at nearly the same time.
Decision 02
Separate commands from rendered state
Devices can send intent while the session distributes the accepted state consistently.
Decision 03
Design reconnection as a normal state
Local networks are convenient but not perfectly stable, so recovery cannot be an afterthought.
Tradeoffs to validate
Comparison of the design directions in this brief, pending confirmation against the implementation.
- Design direction
- Give session state one authority
- Alternative
- Let every device independently resolve game events
- Consequence
- A clear owner simplifies consistency but creates a host-loss recovery problem. Migration behavior requires protocol verification.
- Design direction
- Separate player commands from accepted state
- Alternative
- Replicate each device's local UI state
- Consequence
- The protocol needs explicit message semantics, but screen-specific behavior does not become the source of shared truth.
Implementation
Implementation scope based on the supplied project description.
Establish a shared session
The Android platform brings local devices into a multiplayer lobby. Session ownership and player identity define how devices participate.
Exchange events and state
WebSocket communication supports realtime state synchronization. Message ordering, accepted commands, and state recovery are protocol questions that need verified implementation examples.
Separate personal and shared screens
Phone interactions and TV Cast serve different roles: individual participation and shared gameplay presentation.
Challenges and reliability
Reliability concerns that shape the engineering work:
- Ordered realtime events and explicit session ownership
- Presence, disconnect, and reconnection handling
- Shared-state recovery without blocking the whole group
Outcome
PestaLokal demonstrates distributed product thinking on a small network: protocol design, synchronization, device roles, and multiplayer UX are treated as one system.
Evidence to add
This case study describes engineering scope. Quantified outcomes and implementation claims need supporting material.
- Session protocol and sample message payloads
- Disconnect, reconnect, and late-join behavior
- Synchronization measurements with device count and network conditions
Technology
- Kotlin
- Primary Android language
- Android
- Lifecycle, services, platform APIs, and product delivery
- WebSocket
- Bidirectional local session messages
- Local Network
- Nearby device connectivity
- State Synchronization
- Authoritative multiplayer state
- TV Cast
- Shared-screen presentation