Highlights

• Database sharding is now fully supported in cloud environments, too. This makes the storage layer effectively infinitely scalable and has been tested up to one million concurrent bots. Support for re-sharding an existing database to a higher or lower number of shards is also supported, with a fast-path for scaling up in integer multiples (eg, going from 4 to 8 shards, or 1 to 4 shards).

• Player Incident Reports can now be collected from the devices to help diagnose and fix issues faster. The first version supports collecting reports for networking errors as well as unhandled exceptions on the client. The reports are visible in the Dashboard on the Player page and a global list of most recent incidents on the Overview page. For network errors, a Network Diagnostic Report is also collected, which can be used to better understand the networking conditions on the device at the time of the incident.

• Player event log feature for keeping a log of important game-defined per-player events for customer support purposes. Have a look at Implementing Analytics Events in Game Logic for more info!

• Notification campaign feature for sending a localized push notification to all players at a specified time. Have a look at Implementing Push Notifications for more info!

• A mechanism for defining "database scan jobs", which scan an entity database table and perform a given task with each entity. Have a look at Database Scan Jobs for more info!
  • For example, notification campaigns are implemented as a job that scans the player table and sends a notification to each player.
• Automated LiveOps Dashboard end-to-end tests. Initial test coverage for critical path core components. It is also possible to extend the test suite with custom game-specific test cases.
• Players can now be deleted from your game to meet the GDPR's "right to be forgotten". This can be done from the LiveOps Dashboard or through in-game UI (if you choose to enable it). The feature includes a default cooling-off period of 7 days before player deletion occurs. See Working with Player Deletion if you need to gracefully handle game-specific aspects of player deletion like removing deleted players from guilds or leaderboards.

Under-the-Hood Highlights

• Client-side authentication credentials are now stored in a separate file in addition to the PlayerPrefs. This circumvents an issue on some Android devices where PlayerPrefs fails to persist state properly.
• Google Play and Apple Game Center login validation now cache signing keys. This improves social login latency and reliability.
• Socket metrics are now optionally collected with sock_diag(7) instead of parsing /proc/ pseudo-fs. This improves game server performance when the number of connections is high.
• The server now logs the connecting client IP addresses in a partially-masked, non-personally-identifying form combined with an anonymized ID. For example: 123.45.X.X-3c1f83b9, fe80:0000:X:X:X:X:X:X-3c1f83b9. The anonymized ID will retain its identity until the next server restart or redeployment.
• The client SDK is now able to terminate the session when the application is in the background for a long time (90 seconds by default), if the SDK is informed about OnApplicationPause events. Please see Connection Management for more info.
  • This should help with issues where connections linger for a long time after putting the game in the background.

Breaking Changes

• Database sharding will be enabled by default when running the server locally. This is done to ensure that all features get more testing coverage under sharded database environments.
  • If you have any custom code accessing the database that may be affected, please contact us to confirm whether further changes are needed. Otherwise, no action is required. If you want to opt-out of database sharding in local environments, set the value of DatabaseNumActiveShards in Server/Game.Server/Config/Config.local.json to 1. If you're unsure, please contact us.
• p1.metaplay.io environment has been updated to support the latest database sharding setup. Currently, running deployments are running in a compatibility mode and with the non-sharded database configurations.
  • When you are ready to switch your p1.metaplay.io game server over to use sharded databases, please contact Metaplay to have the compatibility mode turned off and switched to the sharded mode and update to using metaplay-gameserver chart version 0.1.0.
• Updating dedicated environments (prod and staging) to infra-modules v0.1.0 requires a fresh redeployment of the infrastructure from backups (RDS backups and game deployment S3 backups). This update is required for, amongst others, the database sharding functionality.
  • *Please review the notes on updating to v0.1.0 infra-modules at https://github.com/metaplay/infra-modules/tree/v0.1.0.

Migrations

• Player Incident Reports are not enabled by default and require some integration work to start using. This is planned to be fixed in Release 9, where it should be integrated directly into the Metaplay SDK.
  • If you want to start using Player Incident Reports before R9 is out, please contact us.
• PersistentEntityActor initialization sequence (InitializeNew/ LoadPersisted → MigrateState → PostLoad) now passes the initialized state along the calls, removing the need for the implementation to store partially initialized state.
  • No action is required.
• PlayerActorBase now provides a SwitchToNewModelImmediately method and a OnSwitchedToModel callback which replace the RestoreFromModel & PostLoad combo. This clarifies the lifecycle as PostLoad will only be called once, at the end of an initialization sequence.
  • This is a somewhat subtle change, so you should probably pay extra attention to testing code paths where Game Configs are modified on-the-fly.
• PlayerActorBase.ExecuteServerAction now takes a mandatory ServerActionTimelineOrder argument which controls whether the action may happen as a part of the ongoing (if any) action (Relaxed), or if the action may only happen after all actions have finished (AfterPendingOperations).
  • No action required. We have migrated existing code.
  • For ServerActions triggered via a ServerListener, it is recommended to use AfterPendingOperations, as it makes the flow of operations linear. We have migrated the existing code.
• [Sensitive] attribute replaces old PrettyPrintFlag.Sensitive flag for sanitizing sensitive strings from logs and when sending data to the dashboard. The new attribute works when serializing data for the dashboard as well.
  • No action required. We have migrated existing code.
• [MetaSerializable] is now required also for serialized enum types. This makes using serialized enums safer as the attribute should inform the reader that the values of the enums should not be changed, as they may have been persisted in the database already.
  • No action required. The game will let you know during initialization if it is missing. We've added the attribute for existing enum types where necessary. All existing code has been migrated.
• The MessageTargetActor enum has been replaced by an abstract MessageRoutingRule attribute class in order to make it more flexible and extensible by the game without needing to make custom modifications to SDK code.
  • For example, if a message previously had MessageTargetActor.Player as the targetActor argument for its MetaMessageAttribute, it should now instead have the MessageRoutingRuleOwnedPlayer attribute next to the MetaMessageAttribute.
  • No action required. We have migrated existing usage of MessageTargetActor.
• The GoogleCredentialsPath field in Server/Game.Server/Config/Config.*.json files has been renamed to FirebaseCredentialsPath.
  • No action required. We have updated existing code.
• The class structure of the PlayerAction was changed such that the base classes for serialization are now PlayerActionBase and PlayerServerActionBase.
  • No action required. We have updated existing code.
• Many PlayerActions were moved into Metaplay.Core, namely InAppPurchase.cs, PushNotification.cs, and SocialAuth.cs.
  • No action required. We have updated existing code.
• The ActionResult class was split into two: ActionResult remains the container for the game-specific result codes, and MetaActionResult is the type that is passed around and returned from Execute() methods. It also contains all Metaplay Core-specific result codes and the Success code.
  • No action required. We have updated existing code.
• The LiveOps Dashboard project now enforces JavaScript Standard Style linting for better code style alignment with the greater JS ecosystem.
  • No action required. We have migrated existing projects to pass the new linting rules.
• In order to get the client SDK to terminate the connection during long times in the background, the SDK will need to be informed about OnApplicationPause events as described in Connection Management.
  • Check out that the game calls MetaplayClient.OnApplicationPause or MetaplayConnection.OnApplicationPause in its MonoBehaviour.OnApplicationPause. It may already be implemented.

Change Log

Added

• SDK: More metrics related to IAP validation.
• SDK: Utility for defining jobs that scan an entity database table and perform a given task with each entity.
• SDK: NetworkDiagnostics tool which can be used to probe game server, CDN, and known sites on the internet to assess state and quality of network.
• SDK: Push notification campaign feature which allows sending notifications to all players at a specific date and time.
• SDK: Added support for deleting players in properly GDPR-compliant way.
• SDK: Support for sharded databases (re-sharding is only supported in limited scenarios).
• SDK: Support for up-sharding database in integer multiples (assumes that the added database shards are copies of the earlier shards).
• SDK: Added support for deleting players
• SDK: Source IPs of the connecting clients are logged on server in a partially-redacted form.
• SDK: Added a "player event log" feature for keeping a per-player record of game-defined events for admin purposes.
• Dashboard: Added Cypress end-to-end test runner with some initial test as a stating point. The intent is to steadily iterate and add useful tests going forward.
• Dashboard: Added a database section to the landing page status card.
• Dashboard: Added a new environment page with database sharding and item count details.

Changed

• SDK: Replaced the MessageTargetActor enum by a MessageRoutingRule abstract class, allowing for better extensibility and separation of SDK and game.
• SDK: Introduced an IMainGameConfig interface for separating the game-specific representation of parts of MainGameConfig that are referred to by SDK.
• SDK: Serializer now supports enum values larger than maximum int.
• SDK: Serializer now requires the [MetaSerializable] attribute on serialized enum types.
• SDK: Serializer now supports Queue<T>.
• SDK: On Linux, server socket accept queue length metrics are optionally collected with sock_diag(7) instead of parsing /proc/net/tcp. This improves performance if the number of sockets is high.
• SDK: Changed the database-related RuntimeConfigs to better support sharding.
• SDK: Remove MetaplayClient.InMemoryLogger -- will be superceded by the player incident tracking.
• SDK: Failing Actions are now logged on the server with a Warning level.
• SDK: Google Play social login token signatures are now validated on server without extra roundtrips to Google API server. Improves reliability and lowers latency.
• SDK: Apple Game Center social login token signatures are now validated on server with cached certificates. Improves reliability and lowers latency.
• SDK: On client, CredentialsStore now stores user credentials to a file in additions to the PlayerPref.
• SDK: PlayerActorBase::ExecuteServerAction now takes "order" parameter which controls when the action will be executed. When in doubt, use AfterPendingOperations.
• SDK: PersistedEntityActor::{InitializeNew,RestoreFromPersisted,MigrateState,PostLoad} now operate on explicit state object argument to avoid incomplete state leaking to entity.
• SDK: PlayerActorBase::{RestoreFromPersisted, InitializeNew, MigrateState} now operate on explicit PlayerModel as above. Added SwitchToNewModelImmediately method to replace fragile RestoreFromModel();PostLoad(); combo. Added OnSwitchedToModel callback to replace RestoreFromModel in all (re)load paths.
• SDK: Upgrade to .NET 3.1.9
• SDK: Upgrade dependencies: EFCore 3.1.9, MySqlConnector 0.69.10, prometheus-net 4.0, Serilog 3.10.0

Fixed

• SDK: Allow 1 hour for database migration commands to execute to avoid timeouts with large databases (more than about 500k players).
• SDK: Fix race condition in InMemoryLogger when logging from multiple threads.
• SDK: Fix updating of references to GameConfig data in PlayerActor.InitializeSession() when the MainGameConfig version has changed while PlayerActor is live, but player not logged in.
• SDK: Terminate the connection on the client if the application stays paused for a long time.
• SDK: Fix race condition in ServerConnection related session message acknowledgement.
• Reference project: Fixed a nullref exception on the desync error screen when a network report wasn't ordered.
• Dashboard: Fixed player banning toggle sometimes working in unexpected ways.

Refactored

• SDK: Refactored IPlayerModelServerListener and IPlayerModelClientListener into base and game-specific parts. Implement IPlayerModelServerListenerBase in PlayerActorBase.
• SDK: Split PlayerMessagesInternal.cs into game-specific and Metaplay core parts.
• SDK: Move some utility data types from PlayerModel.cs into Metaplay.Core.
• SDK: Introduced MessageCodesCore registry for storing the various typeCodes of Metaplay Core messages.
• SDK: Introduced ActionCodesCore registry for storing the various typeCodes of Metaplay Core ModelActions.
• SDK: Support Metaplay.Core level PlayerActions, which only operate on IPlayerModelBase. Base classes for actions are now PlayerActionBase and PlayerServerActionBase (use these when serializing).
• SDK: Moved InAppPurchase.cs, SocialAuth.cs and PushNotification.cs contents into Metaplay.Core.
• SDK: Moved core messages from PlayerMessages.cs into Metaplay.Core.
• Reference project: Moved StateManager.cs from Code/Systems to its own folder (too game-specific).
• Reference project: Introduced ActionCodes registry for storing typeCodes of game-specific ModelActions.