September 27th, 2022

Pragma Engine is moving to a six week release cadence. Version 0.0.88 is scheduled to be released on November 8th.

Features #

You can now authenticate to the social backend without a gameShardId. #

Description: The social backend sign-on is no longer tied to having a valid game. This means if there are no game shards configured, such as when starting a platform in PRODUCTION mode, an Operator can still log into the platform.

Deprecations #

Use GameDataRPC.GetLoginDataV2 instead of GameDataRPC.GetLoginDataV1. #

Description: GameDataRPC.GetLoginDataV1 is being deprecated due to changes to InventoryRPC.GetLoginDataV1. GetLoginDataV2 brings necessary cleanup along with naming that more correctly aligns with inventory’s limited grant tracking ids as a part of the LoginData payload.

Unity:

Unreal:

Direct calls to RPC endpoints:

Use LoginDataPlugin.getLoginDataJobsV2 instead of LoginDataPlugin.getLoginDataJobs if you are not using DefaultPragmaLoginDataPlugin. #

Description: The dependent job structure on jobs coming from the LoginDataPlugin now uses a data class instead of a proto builder for better futureproofing. You will need to implement LoginDataPlugin.getLoginDataJobsV2 in custom implementations of LoginDataPlugin. | Original | Replacement | Removal release | | - | - | - | | LoginDataPlugin.getLoginDataJobs | LoginDataPlugin.getLoginDataJobsV2 | 0.0.87 |

Integrations #

If you’re using the Limited Grants feature, you’ll need to drop all inventory databases, update your stackable specs to remove stackable trackables, and update any custom service implementations that refer to the list of issued limited grant IDs. #

Description: We recently removed the requirement for a stackable item tracker from the limited grants feature. If you’re using the Limited Grants feature, you will need to complete the listed integration steps.

Integration steps:

• Drop all inventory databases for all environments. This is required to avoid duplicating limited grant fulfillment, and it will clear out all stackable trackables.
  • You can see your configs for the host port schemas for a complete list of databases to drop. The default config schema is: “local_game_inventory1”.
• Update content and run the contentdata apply command.
  • Delete content/package/LimitedGrants.json.
  • Update content/src/LimitedGrants.json:
    • Replace trackingCatalogId with trackingId.
  • Remove all stackable specs for limited grant tracking in content/src/StackableSpecs.json.
  • Run the contentdata apply command.
• If a custom service uses the issuedLimitedGrantCatalogIds field in the GetLoginData call, it will need to be updated to issuedLimitedGrantTrackingIds.

Clients must stop calling matchReconnectV1. Clients should instead listen for the MatchReconnectV1Notification that is automatically sent after login. #

Description: matchReconnectV1 is now a service-only endpoint that automatically triggers on login. A notification with reconnection information will automatically be sent to the client shortly after login.

Integration step: In reconnect scenarios, clients should now listen for the MatchReconnectV1Notification. Remove any calls to matchReconnectV1 from your clients.

If you have game shards in production mode, add a shardId to both game and social core configs. #

Description: We’ve added a shardId into the core config to support game shards. It has been removed from the InventoryServiceConfig to avoid duplication.

Integration step: If you have game shards in production mode, you will need to add both game and social shardIds to the core config YAML file.

• You can find the game shardId by visiting the Game Title Management page on the social Portal webpage.

  The social shardId isn’t used yet, so its value can be any valid UUID.

  Default configuration should look like this:

  game:
    core:
      shardId: "00000000-0000-0000-0000-000000000001"
  

  social:
    core:
      shardId: "00000000-0000-0000-0000-000000000001"
  

Update usages of getDisplayNameForPragmaPlayerIdV1 or getDisplayNameForPlayerIdPartnerV2 to include the new required gameShardId parameter. #

Description: To support a multigame (and therefore multishard) setup for Pragma Engine, we’ve added a requirement for the gameShardId parameter on the getDisplayNameForPragmaPlayerIdV1 and getDisplayNameForPlayerIdPartnerV2 requests.

Integration step: Update usages of getDisplayNameForPragmaPlayerIdV1 or getDisplayNameForPlayerIdPartnerV2 from an SDK or any direct RPC call to include gameShardId on the request. You can access the gameShardId by calling a game shard’s <backendAddress>/v1/info endpoint.

Define columnNameOfPropertyToConsistentHash on all custom instances of PartitionDatabaseConfig. #

Description: The columnNameOfPropertyToConsistentHash field previously defaulted to an empty string. However, this field must now be defined in order to successfully start Pragma Engine.

Integration step: Define columnNameOfPropertyToConsistentHash for all your custom PartitionDatabaseConfigs by providing the database column name used to compute the consistent hash to store data for a player into the proper partition.

See `platform/2-pragma/game/src/main/kotlin/pragma/inventory/InventoryDaoConfig.kt` for an example.

Ensure that you call onConfigChanged() on DaoNodeServices prior to calling run(). #

Description: Previously, you could call run() on DaoNodeServices without calling onConfigChanged(). However, this is no longer the case. You must call onConfigChanged() before run() in order for the service to start.

Integration step: Ensure onConfigChanged() is called before run() on DaoNodeServices.

If you’re using getHostPortMap on AbstractDaoNodeService, switch to hostPortSchemas in DatabaseConfig. #

Description: Moving this functionality has allowed us to do some cleanup and remove unnecessary code. Any use of DbCleaner will need to be updated by removing the second argument.

If you are running multiple game shards in development mode, you will need to manually repopulate the game title and game shard data. #

Description: The local database was improperly named local_game_game and has been renamed to local_social_game as it is a social service.

If you are affected by this change, you will have to repopulate the following data:

• Game Titles & Game Shards
• Limited Access Events & Access Groups

Integration step: You can either manually repopulate your data or you can copy data over from the now-unused local_game_game database, as this change does not delete that database.

Update references to the GameShardId so that it’s pulled from the new location on the Connection object. #

Description: The Unreal and Unity SDKs have moved the GameShardId out of the SDKConfig and onto the Connection object.

Integration step:

• Update references to the GameShardId so that it’s pulled from the new location on the Connection object.
  • Unreal: Connection()->GetGameShardId()
  • Unity: Connection.GameShardId

Bugs and Fixes #

• Unreal SDK: Fixed a bug where HTTP RPCs that failed for HTTP reasons would never call their OnComplete callback.

• Unreal SDK: Fixed a bug where game servers would crash when receiving a MatchEnd response if the new MatchLifecycleService.MatchReady and MatchEnd functions are used.

Docs #

• [Updated User Guide] Removed stackable trackables from Limited Grants User Guide.

• [Updated SDK Guides] Added details for completing Discord Role-based authentication to Unreal and Unity Guides.

• [New Tech Blog Video] Purchasing Stackable Items in a Store video is now live and embedded in its corresponding tech blog article. It is also available via YouTube and the Pragma Blog.