Abort Types Handled by Skillz:
As players compete in Skillz games it is possible for some matches to end with no scores submitted, this can happen because of a crash, connection issues, or a player just force-quitting their game. The Skillz SDK handles these matches by submitting an
abort score for players. Aborts can occur for various reasons and are all tracked and tagged differently on the backend to ensure proper categorization.
- Unintentional Crash - App crash or hardware failure mid-game
- Backgrounded - App is backgrounded (if the OS terminates app it is still considered Backgrounded)
- Terminated - User terminates app manually
- Timeout - User does not submit their score within the allotted time. Also the default abort type recorded if no other information is available
Abort Types Handled by the Game-Client:
There are two other important ways to handle players not properly submitting a score that should be handled by the game client: in-game forfeits and calling the abort method (referred to as “Intentional” aborts). In general you should avoid calling the abort method unless there is no other option. It is important to reduce any noise on your game’s true “abort rate” by handling player-initiated forfeits separately than aborts - abort rates should be a direct indicator of game stability and performance. The way to handle in-game forfeits comes down to your unique game rules.
- Intentional- Created by calling the abort method to end the match prematurely
- In-game forfeits- Can occur in multiple ways depending on the design of the game - the most common being a user forfeiting through an in-game menu. These should submit a real score, rather than an “abort”. In general it is a best practice to continually educate the players on the consequences of leaving the game early.
- Asynchronous games: Typically this should submit whatever score the player has when they forfeit. When handling a player action that will end the match you should first look to report the final score for the player according to the rules of your game. Note that if the user has the potential to lower their score while continuing to play, it may be more logical to submit a 0.
- Real-time games: We recommend submitting a pre-determined losing score for the forfeiting user, rather than calling the abort method. The losing score should be determined by the win-condition for your game and be carefully selected to avoid unintentional “Ties” (ie. force a 0 for the forfeiting user and 1 for winner)
- If your game has a score summary screen before returning to the Skillz SDK, it is best practice to indicate that the opponent Forfeited here, as the Skillz results screen will show only the losing score value that you assign the forfeiting user.
Aborts in Real-time games due to Disconnect from the game-server
In real-time games, there are more nuances to consider when reporting aborts, especially in the case of disconnections from the game server. Some common use cases and typical ways of handling are listed below, but these by no means cover all the permutations of disconnect/reconnect use cases.
- Pausing gameplay on lost connection
- Depending on the design of your game, you may want to pause gameplay when one user loses connection to the game server. For example, in a turn-based game, such as chess, where a user only has a set amount of time to make their move, it would make sense to pause during a reconnect by one user. In real-time strategy games, it can make more sense to allow the opponent to continue playing.
- Reconnection timer
- If you implement a pause in gameplay while a user disconnects, there should be an associated timer to ensure that the game ends if the user never reconnects. A typical value is 20 seconds to allow for reconnection.
- As a best practice, many developers implement this timer to be aggregate to prevent griefing/excessive pausing (ie. if a user disconnects and reconnects after 5 seconds, when they disconnect again they should have 5 less total seconds to reconnect in).
- When one user disconnects and the game is paused, the opponent should see a modal explaining that their opponent has disconnected and showing the current countdown timer. To minimize problems implement the timer in the game server rather than the client to ensure accuracy between the two clients.
- Aborting on disconnection
- If a user disconnects for longer than the time allotted by the reconnect timer, they should submit an abort and the game should be ended immediately. Their opponent should submit whatever their score currently is and win.
- Pause Limiting
- If one user pausing the game, using an in-game menu, results in a pause in gameplay for both users, there should be a limit on the amount of times the game can be paused by one user to prevent griefing. If the user pauses more times than is allowed, they should submit a set losing score (typically 0) and the game should immediately end. It is best practice to educate the user on the implications of pausing too often or disconnecting for too long.
- Disconnect Limiting
- If one user disconnecting from the game server results in a pause in gameplay and impacts the other user, there should be a limit on the amount of times a user can disconnect and reconnect before they are aborted. When this disconnect limit is reached, the game should immediately end with the disconnecting user submitting an abort, and their opponent winning with their current score.
- Multiple users Disconnecting
- If both users disconnect from the game server at the same time, there should be distinct timers for each user. If both users do not reconnect in the time allotted by the timer, they should both submit aborts.