DANGER

Beware: Once a player has been deleted from your database, that's it - they're gone! If you ever need to recover a player after they've been deleted then you'll have to manually restore them from your database backups.

Overview

To comply with data privacy regulations, you must offer players the possibility to delete their data from your game's database. Metaplay already comes with a mostly complete solution, but it still requires some customization. Using Metaplay, whenever you wish to delete a player's data, you'll instead schedule a player for deletion instead of doing it right away. The scheduled date is 7 days by default, but this number can be changed.

The way this works is, that once a day a background worker process on the server looks through the player and deletes any player whose scheduled deletion time has passed. Deleting a player in this context means resetting it back to their initial state, that is, stripping all personally identifiable information and preventing them from logging in again. This marks the player as deleted, and they will otherwise look like a newly registered player to game code. Since having deleted players be visible to the rest of the game code is not desirable (think: guilds, leaderboards, etc.), the SDK provides callbacks that you can use to scrub references to these players from other parts of your game as desired.

The Lifecycle of a Player

The lifecycle of a player can be described by the following diagram:

1. A user creates a new player account. The player is initialized and assigned a random username, and the user's login credentials are stored and linked to the player. Inside PlayerModel, the player's DeletionStatus is initialized to None.
2. User requests that their player account is deleted. This could happen through a CS agent or, if you choose to enable it, from within the game itself. The player's DeletionStatus is set to Scheduled and ScheduledForDeletionAt is set to some time in the future - 7 days by default. At this point, Metaplay calls a hook function (OnPlayerScheduledForDeletion) on the player actor that allows you to clean up any game data related to this player. For instance, you may wish to cancel any multiplayer games that the player is engaged in. Even though we don't block players who are scheduled for deletion from playing the game, you can work under the assumption that they are unlikely to open the game again.
3. In the downtime between scheduling and proper deletion, the user could decide to not delete their player - they might change their mind, or the request might have been unintentional or accidental in the first place. For this reason, we allow a player to be "un-scheduled" for deletion. This action can be performed by a CS agent or, if you choose to implement it, from within the game itself.
4. When the scheduled time arrives, a number of things occur in order:
   1. The player's authentication methods are removed so that they can no longer reconnect to the game.
   2. If currently connected, the player is kicked from the game.
   3. A hook function (OnPlayerBeingDeleted) is called on the player actor. You can use this to clean up any remaining links that the player has to the game. For instance, you may wish to remove the player from guilds or friends lists of other players.
   4. Finally, the player's data is reset to an initial state, effectively stripping all of the user's personally identifiable information from the database.

INFO

Good to know: If a user deletes their player account but later decides to return to the game they will have a fresh new player account automatically created for them when they log in.

Managing Player Lifecycle From The LiveOps Dashboard

With Metaplay, a user can always ask a CS agent to delete their player through the LiveOps Dashboard. It's a simple process once you have navigated to the player's overview page:

INFO

Protip: By default, player deletion happens after 7 days. You can change this value in your server config, and a CS agent can always override the value on a case-by-case basis.

When a player is scheduled for deletion, you will get clear feedback on their overview page:

Background Worker

The background worker process that looks through the player database for players whose scheduled deletion time has passed is run once a day. This is a slow-running background process that scans the entire player database, and that may show up on increased load on your game server. By default, this process is scheduled to run at 2 AM UTC. It's best to run this process at a time that is relatively quiet for your game, so if this time doesn't work for you then you can change it with the System.PlayerDeletionSweepTimeOfDay server configuration option.

The worker is considered to be a low-priority task, so there's a possibility that something more important may block it from running. If this happens then it will try to run again at the same time the next day. The task can also be triggered manually from the Scan Jobs page of the LiveOps Dashboard.

Database Backups

Even after a player has been deleted from your live database, it is important to note that the player will still exist in any backups that you have taken. Database backups pose two interesting problems for player deletion and the GDPR's "right to be forgotten":

1. A player is not "forgotten" if they still exist in backups. In practice, this is acceptable as long as you do not keep long-term backups. If your backup retention policy is, for example, six months then it is ok for those backups to contain the deleted player because new backups will not contain the player, and the player will be completely purged from your system after six months.
2. Restoring data from a backup has the potential to restore a deleted player. The restored player would then remain in your system forever, and this would be a GDPR violation. The solution to this is a system that can detect these cases and cause the affected players to be "re-deleted' after the backups have been restored. This process is explained in Re-Deleting Players After Restoring From Backups

INFO

Help Available: Call us if you need to restore your game from a backup.

Game-Specific Customization

Cleaning Up References to Deleted Players

Remember that we don't actually delete players - we just reset their data. Once reset, these players may still be visible to other players in your game. This can be undesirable for a few reasons:

• If you use leaderboards then you probably don't want deleted players to be visible in them. Maybe you generate your leaderboards daily, for example, and store them as a list of Player IDs. When a player is deleted, the Player ID will now point to a "reset" player. Imagine a situation where a top player is deleted, leaving the leaderboard with a level 1 newbie player in the number one slot.
• Guilds and friends lists that contain deleted players might look bad to other players. Maybe those players will start to wonder why the other player left? If a lot of players leave at once, it could look really bad to your remaining players.
• Multi-player games can also be affected by deleted players. What if a long-running game is in progress when one of the players is deleted?

Whilst deleted players can be problematic, players who are scheduled for deletion might also be a cause for concern. It may be sensible to assume that a player who has requested to be deleted is never likely to return to the game. Such an inactive player can cause a few problems:

• If the player is involved in a multi-player game with another player, you might want to terminate that game so that the other player doesn't wait forever for their next turn.
• Matchmaking systems might want to avoid picking these players - who want to be matched against a player who might never even open the game again?

Metaplay's player deletion system contains several features to help you manage the situation. These features fall into two categories: programmatic hooks and player status.

Programmatic hooks allow you to react to changes in a player's deletion status as they happen. There are two hooks available: OnPlayerScheduledForDeletion and OnPlayerBeingDeleted. Use these to clean up existing references to players.

The DeletionStatus variable on a PlayerModel lets you check the deletion status of a player. The value can be either None, Scheduled or Deleted. Use this information to, for example, exclude players from your matchmaking or leaderboard generation algorithms.

INFO

Note: How you handle deleted players is up to you - there is no "one size fits all" solution. For some games, especially those without social features, doing nothing is also a valid option. Metaplay makes sure that deleted players won't cause problems (you don't have to worry about exceptions caused by Player IDs ceasing to exist) but it's up to you to think about how you want to handle deleted players in your game world.

Wrapping Up

Deleting players is serious business. GDPR rules dictate that we must allow it and that we must perform it properly, but mistakes could also prove to be problematic. What happens if a CS agent accidentally deletes the wrong player? Or what if someone else gets hold of a player's device and schedules the player for deletion without their knowledge? How will you re-instate that player when their data has been lost? Ultimately, you'll need to think about which features you want to enable and how you want to implement them. As an absolute minimum, we recommend implementing in-game feedback and making sure that players have a direct access channel to a CS agent in case of problems.