From reconnect recovery to memory release, the plumbing that keeps a slot game stable
Real-time client-server messaging, state restore after a dropped connection, staged asset loading and memory release, localization, and UI layer stacking.
Whether a game holds up under real-world conditions comes down to three systems players almost never notice: the communication layer, the asset layer, and interface layer management. When they are done well they are entirely invisible; when they are done badly every flaw gets amplified.
Among them, communication is the critical infrastructure of the whole game experience. Unlike the request-response pattern of a typical web application, a slot game needs a persistent connection to guarantee immediacy and state consistency.
The client and the server establish a persistent connection over WebSocket and periodically exchange heartbeat packets to detect whether the connection is healthy; if no response arrives within the timeout window, the connection is judged to be down and the reconnection procedure starts. Choosing the interval is a trade-off: too long and it takes several seconds to notice a disconnect, too short and it burns unnecessary battery on mobile networks. We make the heartbeat mutually exclusive with actual traffic. If normal packets have already gone back and forth within the interval, that heartbeat is skipped.
The flow looks simple, but several edge cases hide in the details:
These three situations share one design principle: make every critical operation idempotent. No matter how many times the same request is sent or how many times a response is received, the result finally presented to the player must be identical. Designing idempotency into the protocol layer is far more reliable than defending against it separately at every call site.
Disconnects are extremely common on mobile networks: switching cell towers, stepping into an elevator, a momentary network drop. A good reconnection strategy has to restore game state imperceptibly. The core mechanisms are:
The hard part of recovery is actually not the data but the presentation: pasting the final screen straight up is jarring, while replaying the whole thing feels long-winded to a player who already knows the result. We decide the strategy based on which stage the disconnect happened in: a disconnect before the presentation stage gets a full replay, a disconnect after it fast-forwards to the final state.
All values on the client use integer arithmetic, taking the smallest unit as the base tick to avoid accumulated floating-point error, and converting to a decimal-point format only at display time. This principle has to be carried through every intermediate step, including the interpolation of number-rolling animations.
The asset volume of a slot game can be quite large: hundreds of image sprites (including versions at different resolutions), skeletal animation data, audio files, font files and so on, and how efficiently they are managed directly affects load time and memory usage. Asset loading uses a staged, progressive strategy:
Deferred loading needs a safety net: if a special feature is triggered while its assets are not yet ready, the flow must not break; instead an extendable transition sequence is inserted to buy time, which is also why scene transition animations are usually designed to loop seamlessly.
A slot's asset requirements are not a single set but change as the game switches between flows:
Every flow switch is simultaneously an asset switch: entering free games means loading dedicated backgrounds and symbol variants, and exiting means deciding what to release and what to keep in cache. The criterion is trigger frequency: assets of high-frequency flows stay in memory, while assets of low-frequency special features are released on exit.
To match the three-layer architecture, the asset system also supports three-layer overriding:
When the loader looks something up it starts at the game layer and falls back downward layer by layer, so developers only need to replace the parts they want to customize and everything else automatically inherits the upper layer's defaults.
Multi-language support is far more than "swapping the text"; it spans several dimensions:
The impact of audio on the slot game experience is frequently underestimated; a carefully designed audio system can substantially improve immersion and the sense of feedback. Our audio architecture manages all sound across three independent channels:
The three channels have independent volume controls that the player can adjust separately.
The audio system is deeply integrated with the game state machine, ensuring precise synchronization between sound and picture:
There is a practical detail in aligning the reel stop sound: the sound should align with the instant the reel makes contact with the target position, not with the end of the whole animation. The overshoot and rebound happen after contact, so playing it late puts it half a beat behind.
On a scene transition, the audio system performs a crossfade: the current scene's background music fades down over a configured duration while the new scene's music fades up, with the crossfade curves independently configurable to keep the transition natural.
Another common problem is stacking: in a fast-paced sequence the same sound may be triggered several times within a very short window (consecutive win-line presentations, for example), and multiple stacked instances produce a harsh volume spike. The audio system prevents this with three mechanisms:
Managing interface layers in a slot game is more complex than in a typical application: all sorts of elements appear and disappear at different moments, and strict layering relationships and mutual-exclusion rules hold between them. We use a four-layer architecture:
Strict mutual-exclusion locking rules hold between the layers, preventing the confusion of several overlays appearing at once:
This mechanism keeps the interface orderly and predictable in every situation. Even in the extreme case of a disconnect while the big-win celebration animation is playing, the communication layer's error message passes through to the topmost layer, while the celebration animation is frozen rather than aborted, resuming from the frozen point once the player acknowledges. The cooperation of the three supporting systems at that moment is exactly where the whole architecture really gets validated.
The reason these supporting systems can cooperate without becoming tangled is that a clear layered architecture and state machine definition exist underneath them; and the visual subject they serve, the reels' animation curves and stop rhythm, has its own independent design methodology. We cover those two topics in the other two articles of this series.