Hacker Screen

Overview

Hacker Screen is a real-time multiplayer system designed around competitive gameplay with sabotage mechanics. The system requires sub-second latency for player actions, reliable state synchronization, and graceful handling of network interruptions.

Problem

The core challenge was building a responsive multiplayer experience where players can interact in real-time while maintaining game state consistency. Traditional request-response patterns introduce too much latency for competitive gameplay, and naive state management leads to desynchronization issues.

Constraints

Desktop application environment (WPF/Avalonia)
Must function reliably on consumer-grade internet connections
State must remain consistent across all clients
Sabotage mechanics require immediate feedback without server round-trips
System should degrade gracefully under network stress

Architecture & Design Decisions

The architecture centers on SignalR for real-time communication, with a hub-based design that separates game logic from transport concerns. Client-side state is maintained through an MVVM pattern, allowing the UI to react to state changes without direct coupling to network events.

State synchronization follows an authoritative server model with client-side prediction. The server maintains the source of truth, but clients can optimistically update their local state to reduce perceived latency. When conflicts occur, the server state takes precedence.

Technology Stack

C# / .NET: Core application framework
SignalR: Real-time bidirectional communication
MVVM: Separation of concerns between UI and business logic
Dependency Injection: Loose coupling and testability

Key Challenges & Trade-offs

Latency vs. Consistency: Client-side prediction improves responsiveness but requires conflict resolution. The system prioritizes consistency, accepting occasional rollbacks to maintain game integrity.

Connection Resilience: Network interruptions are common in desktop applications. The system implements automatic reconnection with state recovery, but this adds complexity to the state management layer.

Scalability: SignalR hubs can handle concurrent connections, but the current implementation assumes a single server instance. Horizontal scaling would require a backplane (Redis or similar) for state synchronization across instances.

Outcome / Current Status

The system successfully delivers sub-second latency for player actions and maintains state consistency under normal network conditions. The sabotage mechanics work as intended, with immediate client feedback and server validation.

The architecture has proven maintainable, with clear separation between network communication, game logic, and presentation layers.

What I’d Improve Next

Implement a backplane for multi-server deployments
Add more granular state diffing to reduce payload sizes during synchronization
Introduce a replay system for debugging desynchronization issues
Consider WebRTC for peer-to-peer communication in low-latency scenarios