question

Jørgen Havsberg Seland avatar image
Jørgen Havsberg Seland asked

Need temporary player attributes together with match result: Question regarding Matchmaking 2.0 Beta API Question and player Attributes

I need to transfer temporary connection information along with the matchmaking request that will be available to the matched players once the match successfully completes, so that the players know how to reach each other.

I have attempted three different approaches for this. Please advice on what is wrong with my approaches, or if other approaches exist within PlayFab.

Solution 1: Player Attributes via GetMatchmakingTicket

The most elegant solution seems to be using the player attributes of `CreateMatchmakingTicket`, and then retrieving them with `GetMatchMakingTicket`.

However, I have hit some problems:

Specifically, I would like to retrieve the JSON object submitted as `CreateMatchmakingTicketRequest.Creator.Attributes`.

The documentation on `GetMatchmakingTicketResponse` (https://api.playfab.com/documentation/multiplayer/method/GetMatchmakingTicket) states:

Members (required) List<MatchmakingPlayer> > A list of Users that have joined this ticket.

This sounds like, once `Status == "matched"`, either

  1. `GetMatchmakingTicketResponse.Members` should contain the complete list of players matched using the ticket, including their `Attributes`, or
  2. `GetMatchmakingTicketResponse.Members` should contain the `Creator`, plus the players from `MembersToMatchWith` that have successfully called `JoinMatchmakingTicket`.

In practice, this seems to contain only the player from the `Creator` field of the calling player's own `CreateMatchmakingTicket` call (I am currently matchmaking only one user at a time, and so I do not know if JoinMatchmakingTicket callers are included).

Solution 2: Player Attributes via GetMatch

I can get the complete list of players by calling `GetMatch` (i.e. `GetMatchResult.Members`), but this list contains neither the `Attributes` not the ticket ids of the other tickets in the match. (The tickets would presumably contain their creator's attributes, providing a round-about solution to my problem.)

It seems `GetMatchResponse.Members` is supposed to contain the `Attributes` of each player; this is indicated by the comment on `GetMatchRequest.EscapeObject`:

```/** * Determines whether the matchmaking attributes will be returned as an escaped JSON string or as an un-escaped JSON * object. */ bool EscapeObject;```

I am not sure if this inconsistency is because EscapeObject should not be there, or if Attributes is indeed missing from GetMatchResponse.Members.

Solution 3: SetObjects / GetObjects on title_player_account

As a fallback, I have tried encoding the information I need transferred as Objects on the title_player_account entity of each player that enters matchmaking, by using SetObjects and GetObjects.

This fails, however, since GetObjects called with title_player_accounts of other players than the current player fail with "NotAuthorized".

I have tried to add the following to the global policy (via the web page) to allow this read to happen, but it does not seem to work. 

  {
        "Action": "Read",
        "Effect": "Allow",
        "Resource": "pfrn:data--title_player_account!FA45/Profile/Objects/*",
        "Principal": "*",
        "Comment": "Allow everyone to read the default object."
    }

There is almost no information available on how to setup policies for pfrn:data resources, and what little there is deals almost exclusively with files.

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

2 Answers

·
Wisgary avatar image
Wisgary answered

Hi Jørgen! This is really great feedback for us. Thanks for taking the time to lay out all the options in detail.

We chatted about it internally and our preferred path is your Solution 2, but as you pointed out, it doesn't work at the moment. We will work on getting the attributes flowing through to the Match object. Our current thinking is that we will expose a flag called ReturnMemberAttributes on the GetMatch request. If that is set, we would populate the Match response object's Members with their corresponding data attributes so you can find all of them in one place. Would that work?

Also, what does your timeline look like? We can probably get this done and deployed in the next week or two. If you need to be unblocked sooner than that, we have 2 options:

  1. We can find someone who knows data policies well to see if it's possible to unblock your solution #3.
  2. There is potentially a way to achieve the round-about solution you mentioned using CloudScript, though it is a bit overkilly. You could write a CloudScript that using the Server versions of the APIs gets the match, grabs all the ticketids from there, gets all the tickets, then grabs all the attributes and returns them. But it's a bunch of work that we'd like to avoid forcing you to do, as it will be way nicer if we just get the change in for you or even getting solution #3 unblocked would likely be simpler.

Let us know if you want further help with a temporary unblock or if sometime in the next couple of weeks is ok for Solution #2 to work. Thanks again for the detailed feedback!

5 comments
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Jørgen Havsberg Seland avatar image Jørgen Havsberg Seland commented ·

Thank you for the comprehensive feedback and rapid reply.

To answer your follow-up questions:

1) A flag ReturnMemberAttributes + GetMatchResponse returning the complete data attributes is a good solution for us.

2) The next couple of weeks for a final solution is a good timeline, but I need to get a prototype up and running ASAP, and so it would be great to get solution #3 "unblocked", as you say.

Question #1 is therefore: How would I go about setting up a data policy that would allow other players to read a) specific Objects (say, only the Object with key "ConnectionDetails") or b) any Object on the current player?

Question #2: If policies for *specific* Objects can be set (i.e. alternative a above), how does the GetObjects API behave in this situation, since it is supposed to return all the objects of the entity? Does it fail, or does it return only the objects for which it has permission?

1 Like 1 ·
Andy avatar image Andy ♦♦ Jørgen Havsberg Seland commented ·

I can give you a hand with the policy definition you'll need for solution 3. You should be able to add this policy block to your global entity policy:

  "Resource": "pfrn:data--*!title_profile_account/Profile/Objects/Public",
  "Action": "Read",
  "Effect": "Allow",
  "Principal": {
    "ChildOf": {
      "EntityType": "title",
      "EntityId": "FA45"
    }
  },
  "Comment": "Allow everyone to read player Public data"<br>

That will make the title_player_account object named "Public" readable to every entity in your title. You can then call SetObject to write a value named "Public". The behavior you'll see with GetObjects is that it will only return the objects visible to the calling entity.

Let me know if that's not clear. Also, apologies for the lack of documentation on entity policy. We're working to make it easier to work with and will update documentation once we're happy with where it is.

1 Like 1 ·
Jørgen Havsberg Seland avatar image Jørgen Havsberg Seland Andy ♦♦ commented ·

Thank you, this unlocks the "solution #3" workaround for us, and we are able to proceed with our prototyping.

Is there any tentative timeline on when a stable version of the data policy documentation might become available?

0 Likes 0 ·
Show more comments
Jørgen Havsberg Seland avatar image Jørgen Havsberg Seland commented ·

Follow-up question on the CloudScript solution mentioned above may be found in this post.

0 Likes 0 ·
Yuvek avatar image
Yuvek answered

Hi Jørgen,

We have added the flag to GetMatch API to return all Member attributes so you should now be able to do that. Here is the link to the documentation for the API

https://api.playfab.com/documentation/multiplayer/method/GetMatch

1 comment
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Jørgen Havsberg Seland avatar image Jørgen Havsberg Seland commented ·

After regenerating the API from github API_Spec with the SDKGenerator, this worked (almost) out of the box. Thank you!

2 Likes 2 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.