Key Concepts #
The Party Data Classes #
There are two main data classes within the Party service: Party
and PartyPlayer
. These classes are created by the platform and handed to plugins to customize at the extension points described later on this page.
The Party Class #
property | description |
---|---|
partyId | unique identifier for the party |
maxPlayerCount | number representing the maximum amount of players for the party set via the PartyService config |
disableMaxPlayerCount | boolean indicating if the automatic check for maximum player count is disabled or not, set via the PartyService config |
gameServerVersion | computed game server version based on the PartyPlayer s in the party, updated whenever a player joins or leaves the party |
preferredGameServerZones | list of game server zones that the party can play a match on |
inviteCode | invite code for the party that players can use to join |
overrideGameServerVersion | boolean indicating if the Game Server Version Compatibility Plugin should validate this party or not, set via PartyService config |
partyMembersByPlayerId | map of all players in the party index by their playerId |
extPartySelections | ext proto of selections for the party |
extHiddenPartyData | ext proto of sensitive data for the party that is not sent to players’ game clients |
The PartyPlayer Class #
property | description |
---|---|
sessionKey | identification object including the player’s pragmaId , also known as their playerId |
displayName | object containing the player’s name and discriminator |
inventory | snapshot of the player’s inventory from when they entered the party or last completed a match |
gameClientVersion | version of the game client the player is currently running |
gameServerZoneToPing | map of this player’s ping to various game server zones |
leader | boolean indicating if this player is a leader in this party |
ready | boolean indicating if this player ready to play a match |
extPlayerSelections | ext proto of player selection state within a party |
extPrivatePlayerSelections | ext proto of private player selection state within a party |
extHiddenPlayerData | ext proto containing sensitive data about a player that can only be used on the server in plugins |
Types of Extension Data #
During a party’s construction, you can populate all the custom data that will be present on the party throughout the entire game flow lifecycle. This data persists on the party. On Match End, the pieces of data that are changed can be defined in PartyPlugin.returnFromMatch
.
There are two types of data related to the Party service: player data and party data. These are further defined by visibility; data can be visible to the entire party, to an individual player, or to the server only (hidden). To initialize data, populate the related ext
fields in the Party Plugin during a party’s construction when the initializeParty
function is triggered. These fields are stored on the Party
or PartyPlayer
classes, and are passed to other plugins while the party journeys through the game loop. By default, this data can be referenced by other plugins, but cannot be changed.
Below is a chart containing descriptions and examples for every type of Party service data.
name | visibility | description | example |
---|---|---|---|
ExtPartySelections | party | designated by party leader and applies to entire party | map or game mode |
ExtHiddenPartyData | server | scoped to the entire party but hidden to all players | team win/loss streak tracker |
The Party Plugin #
The Party Plugin provides a location for developers to implement custom party functionality. For a full list of plugin methods, look at All Calls and Methods.
Configuration #
The PartyConfig
configuration class includes everything that can be defined in the main configuration YAML file.
config | description |
---|---|
maxPlayersPerParty | maximum players allowed in each party |
disableMaxPlayerCount | whether to disable maximum player count limits in each party |
enableLocalGameServerVersions | whether to allow local game clients to override their game server version for local development purposes |
repeatInviteDelaySeconds | defines the delay between a player inviting another player consecutive times |
inventoryTagsToInclude | tags used to filter player inventories, and items that match one or more tags will be included |
enableTransferPartyLeader | whether to transfer party leader status from one to another when invoking AssignPartyLeader |
Player Inventory #
A snapshot of a player’s inventory is stored on the PartyPlayer
class that is available when implementing the Party Plugin. This data can be used to validate party and player selections against the player’s inventory–for example, players should only be able to select skins they have purchased.
To minimize the amount of unnecessary data passed between services, use the inventoryTagsToInclude
configuration map to determine which parts of a player’s inventory to include in the snapshot.
A player’s inventory snapshot is updated when they join a party or complete a match, after the match processing has completed.
Party State #
When players make changes to the party state, such as by making party or player selections, all players receive an up-to-date payload along with a PartyDetailsV1Notification
that contains information about any changes from other players.
This notification contains the BroadcastParty
payload, which includes the following information.
For the party:
- party ID
- a list of all public info about each party member
- the invite code
- preferred game server zones
For each player:
- player ID
- display name
is_ready
booleanis_leader
boolean
Game Client Versions #
Game servers and game clients must be updated in parallel as updates are added to live service games. Pragma Engine provides the capability to enforce game client versions via the PartyService.gameServerCompatibilityPlugin
. Lists of game server versions and corresponding compatible game client versions can be defined.
Note that the same game client version can match to different game server versions. If players in a party are compatible with multiple game server versions, the highest game server version is used, as defined by the keys in versionCompatibility
. The {{USER_DEFINED_GAME_SERVER_VERSION}}
value is passed to the Matchmaking service.
A valid config must be defined, and it must include:
- a
versionCompatibility
config block - a
clientVersions
config block - unique
versionCompatibility
keys which are positive ints–greater ints designate higher priority - a unique
{{USER_DEFINED_GAME_SERVER_VERSION}}
which is not an empty string - a unique
{{USER_DEFINED_GAME_CLIENT_VERSION}}
which is not an empty string