AirConsole Games Features
Connect to your game

Handling unstable connections

10min
your game needs to handle unstable connections and high latency in this guide you will learn about properly handling unstable connections (such as in cars, unstable 4g/wi fi networks) internet connections can be unstable (e g in cars) the airconsole api makes sure that no messages and updates from the screen and the controllers are lost a message or update sent by a device is guaranteed to arrive at some point in the right order even if the internet connection was disrupted, but the latency can be high loading file resources in your game you are responsible to reload resources if they fail to load after onready() onready() is called if a request fails before onready is called in the api, we will reload the entire game but once onready was called, you have to reload resources that fail to load yourself the best practice is to load all resources before onready if you know that they are going to be used additional levels and big data files should still be loaded on demand at a later point, but you are responsible to handle load failures/retries implementing onpause() / onresume() events general it is vital that you implement the onpause() onpause() / onresume() onresume() events when a device such as a car's infotainment screen loses the internet connection (e g in a tunnel), the inputs from the controllers will not arrive on time when airconsole detects a very high latency or temporary disconnect from the internet, the onpause() onpause() method will be called, and you should immediately pause the game and all audio you don't need to inform the user about pausing the game since airconsole will provide a pause overlay on the screen and all controllers make sure that pause still works if called twice! sometimes, there may be a delay in displaying the pause overlay on controllers this happens when the connection between the controllers and the screen is completely lost, but as soon as the connection is re established, the pause overlay will appear please, do not create any informative screens about pausing the game airconsole will provide pause overlay on screen and all controllers once the internet connection conditions are back to normal, airconsole will call onresume() onresume() , and you should resume the game and all sounds airconsole will show a countdown overlay for 3 seconds before onresume onresume event is called the onpause() onpause() method will only be called on the screen! controller input will still arrive on the screen and should not change the game's state before onresume() onresume() is called onpause() onpause() / onresume() onresume() methods were added in airconsole api 1 8 0 you can test them in the airconsole simulator if you are using at least api version 1 8 0 testing please include these following cases in your tests test case 1 initially (game loaded) the screen is disconnected from the internet while the game is loading and the onpause() onpause() function is called when the game loads, it calls the onready() onready() callback function airconsole will call the onpause() onpause() function right after it executes the onready() onready() function from the game that just loaded make sure that this is handled properly and that you pause any game logic, intro videos or other background music immediately steps load your game preview in the airconsole simulator, e g https //www airconsole com/simulator/#https //game airconsole com/com your game/2023 06 07 16 06 19/ with pause on start selected expected the game should be paused and not producing any sounds (e g background music, intro sound/music, video intro, etc ) test case 2 during gameplay disconnecting the screen from the internet while playing the game should pause the game and all sounds in the game steps load your game preview in the airconsole simulator, e g https //www airconsole com/simulator/#https //game airconsole com/com your game/2023 06 07 16 06 19/ press the pause button any time during the gameplay (e g while loading a game level, while in the game menu, while playing, etc ) expected the game should be paused and not producing any sounds (e g background music, intro sound/music, video intro, etc ) test case 3 repetitive calls to onpause() onpause() calling the onpause() onpause() function multiple times will not cause any issues the game should remain paused and not exhibit different behavior even if onpause() onpause() is called repeatedly steps simulate calling the onpause() onpause() function multiple times (without calling onresume() onresume() in between) expected invoking onpause() onpause() on an already paused game should keep the game in a paused state test case 4 repetitive calls to onresume() onresume() calling the onresume() onresume() function multiple times will not cause any issues the game should remain active and not exhibit different behavior even if onresume() onresume() is called repeatedly steps simulate calling the onresume() onresume() function multiple times (without calling onpause() onpause() in between) expected invoking onresume() onresume() on an already active game should keep the game active it should not pause the game or behave differently even if called multiple times high latency handling general input latency from controllers can be significantly higher in cars the api call getservertime() getservertime() provides a synchronized clock between the devices for example in a quiz game, this timestamp can be sent from the controller to the screen if controllers have different latency, you can still determine the correct winner by looking at all timestamps received from the controllers to compare the real user input times this can be applied to almost any game you can determine the latency of a message by sending the getservertime() getservertime() timestamp from the controller to the screen and compare it with the getservertime() getservertime() on the screen once you know how many milliseconds the message took, you can consider this in your input (e g rewind the game by x milliseconds, add the input, fast forward x milliseconds again) testing the best way to simulate a high latency between the controller and the screen is to use a vpn the chrome devtools network option won't throttle the webrtc connection, only the loading of the game assets