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 - The app crashed or there was a hardware failure mid-game.
• Backgrounded - The app is backgrounded (if the OS terminates the app it is still considered Backgrounded).
• Terminated - The user terminated the app manually.
• Timeout - The user did not submit their score within the allotted time. This is 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 depends upon your unique game mechanics and rules, but we have some general guidance to consider.

Intentional Forfeits

These are 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.

In-Game Forfeits

These can occur in multiple ways depending on the design of the game - the most common being a user forfeiting through an in-game menu. In this case, the game 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. Providing a pop-up modal dialogue notifying the player that their game will end and their score will be reported, giving them the option to return to the game, is a common technique.

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 attempt 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. Again, this is dependent upon the game design, but an abort should never be a way to avoid getting a worse score.

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” (i.e. 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 the 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 Game 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 them 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 could 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 (i.e. if a user disconnects and reconnects after 5 seconds, when they disconnect again they should have 5 less total seconds to reconnect).
   3. When one user disconnects and the game is paused, the opponent should see a modal dialog explaining that their opponent has disconnected and showing the current countdown timer. To minimize problems and ensure accuracy between the two clients, the timer should be implemented in the game server rather than the client.
3. Aborting on disconnection
   1. If a user disconnects for longer than the time allotted by the reconnect timer, that user should be reported as an abort, ideally using server-side score reporting, and the game should be ended immediately. Their opponent should submit whatever their score currently is, and so 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 losing score (typically 0) and the game should immediately end. It is a 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 an abort reported for the disconnecting user, 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 both timers, aborts should be submitted for both players.