Best Practices For Aborted Matches and Forfeits in Skillz Games

Handling Incomplete Games

As players compete in Skillz games, it is possible for some matches to end with no scores submitted and it is also possible for users to quit matches early where scores may or may not be submitted. There are a variety of scenarios to account for that may depend on your gameplay but this guide should provide some best practices for most situations.

No Score 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

Player Forfeits

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). The way to handle in-game forfeits comes down to your unique game rules but we have some general items to think about.

Intentional Forfeits

Created by calling the abort method to end the match prematurely.

In general you should avoid calling the abort method unless there is no other option. Abort rates should be a direct indicator of game stability and performance so it is important to reduce any noise on your game’s true “abort rate” by handling player-initiated forfeits separately than aborts.

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.

Real-Time Games Disconnects

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.

1. Pausing gameplay on lost connection
   1. 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.
2. Reconnection timer
   1. 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.
   2. 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).
   3. 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.
3. Aborting on disconnection
   1. 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.
4. Pause Limiting
   1. 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.
5. Disconnect Limiting
   1. 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.
6. Multiple users Disconnecting
   1. 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.