Pragma Engine 0.0.86
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:
Original | Replacement | Removal release |
---|---|---|
GameData.Raw.GetLoginData | GameData.Raw.GetLoginDataV2 | 0.0.87 |
Unreal:
Original | Replacement | Removal release |
---|---|---|
PragmaGameDataServiceRaw.GetLoginDataV1 | PragmaGameDataServiceRaw.GetLoginDataV2 | 0.0.87 |
Direct calls to RPC endpoints:
Original | Replacement | Removal release |
---|---|---|
GetLoginDataV1Request | GetLoginDataV2Request | 0.0.87 |
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
withtrackingId
.
- Replace
- Remove all stackable specs for limited grant tracking in
content/src/StackableSpecs.json
. - Run the
contentdata apply
command.
- Delete
- If a custom service uses the
issuedLimitedGrantCatalogIds
field in theGetLoginData
call, it will need to be updated toissuedLimitedGrantTrackingIds
.
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.
Original | Replacement |
---|---|
AbstractDaoNodeService::getHostPortMap | DatabaseConfig::hostPortSchemas |
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 theConnection
object.- Unreal:
Connection()->GetGameShardId()
- Unity:
Connection.GameShardId
- Unreal:
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 newMatchLifecycleService.MatchReady
andMatchEnd
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.