question

brendan avatar image
brendan asked

Check if one friend is online? Accept friend request?

luizcarlosfx
started a topic on Tue, 03 February 2015 at 9:27 AM

First: Is there a way to check if one player is online?

Second: I've noticed that when I call AddFriend() the friend gets automatically added to my friends list. Is there a way to add the player only when the other player accepts the request?

Third: How can one player have another player in his friends list and the other doesn't? this shouldn't be mutual? I have two players: luizcarlosfx and demouser1. Luizcarlosfx has demouser1 in his friend list but demouser1 doesn't have luizcarlosfx in his friend list.

Thanks

10 |1200

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

brendan avatar image
brendan answered

Best Answer
Brendan Vanous said on Tue, 03 February 2015 at 11:59 AM

As a Web API-style of service, we don't specifically have the notion of an "offline" status (there's also no Logout API call, for instance). One way to compute the "login" state for the player would be to query for the player's info using GetUserCombinedInfo. The LastLogin property of UserTitleInfo can be used to see when the user last signed in, and the timestamp on other user data values could be used to determine recent actions, depending on the specifics of how the game uses user data.

The Friend system in PlayFab is more akin to a "follow" system, in that you add players you want to have on your list - it does not require two-way confirmation. One way to force a two-way friend system for your game would be to have a "FriendRequests" Shared Group Data object for each user - just don't add any users to it, other than the owner. You'd use the PlayFab ID as they Key for any Values you write, and do the updates in Cloud Script. That way, there are no contention issues to deal with. So, for example:

  • Player A (PlayFabId "111") wants to add Player B (PlayFabId "222") as a friend, and so chooses that option in your game.
  • The title adds the Key/Value pair "111":"data" to Player B's "FriendRequests" Shared Group Data object, via Cloud Script. The "data" value could be anything else you need, or even a custom message from the player.
  • When Player B signs in, read his FriendRequests with no Key specified, so that you get all of them.
  • Display the potential friend list to Player B, and let him choose which ones to accept/decline. Remove those Key/Value pairs from FriendRequests.
  • For unfriending, you could do something similar with an "UnfriendedMe" Shared Group Data object, just without offering the player any options - just take care of it when they sign in.
  • You could also have an "OutstandingFriendRequests" Shared Group Data object for each user, so that you have tracking on unanswered friend requests. When a user accepts or declines a request, in addition to the script updating their FriendRequests data, you would also update the other user's OutstandingFriendRequests, similar to the above flow.

The two things to think about in any implementation list this are:

Only add users to a Shared Group Data object if they should be able to view and update it. And since a hacked client could send the Update call with whatever data they want, make sure to only do your updates via Cloud Script if you need this to be secure.

When multiple players are able to update Shared Group Data (even through Cloud Script), always write to a Key which incorporates the player's PlayFabId, so that there's no chance of two players trying to update the same Key with different Values at the same time.


1 Comment
Brendan Vanous said on Tue, 03 February 2015 at 11:59 AM

As a Web API-style of service, we don't specifically have the notion of an "offline" status (there's also no Logout API call, for instance). One way to compute the "login" state for the player would be to query for the player's info using GetUserCombinedInfo. The LastLogin property of UserTitleInfo can be used to see when the user last signed in, and the timestamp on other user data values could be used to determine recent actions, depending on the specifics of how the game uses user data.

The Friend system in PlayFab is more akin to a "follow" system, in that you add players you want to have on your list - it does not require two-way confirmation. One way to force a two-way friend system for your game would be to have a "FriendRequests" Shared Group Data object for each user - just don't add any users to it, other than the owner. You'd use the PlayFab ID as they Key for any Values you write, and do the updates in Cloud Script. That way, there are no contention issues to deal with. So, for example:

  • Player A (PlayFabId "111") wants to add Player B (PlayFabId "222") as a friend, and so chooses that option in your game.
  • The title adds the Key/Value pair "111":"data" to Player B's "FriendRequests" Shared Group Data object, via Cloud Script. The "data" value could be anything else you need, or even a custom message from the player.
  • When Player B signs in, read his FriendRequests with no Key specified, so that you get all of them.
  • Display the potential friend list to Player B, and let him choose which ones to accept/decline. Remove those Key/Value pairs from FriendRequests.
  • For unfriending, you could do something similar with an "UnfriendedMe" Shared Group Data object, just without offering the player any options - just take care of it when they sign in.
  • You could also have an "OutstandingFriendRequests" Shared Group Data object for each user, so that you have tracking on unanswered friend requests. When a user accepts or declines a request, in addition to the script updating their FriendRequests data, you would also update the other user's OutstandingFriendRequests, similar to the above flow.

The two things to think about in any implementation list this are:

Only add users to a Shared Group Data object if they should be able to view and update it. And since a hacked client could send the Update call with whatever data they want, make sure to only do your updates via Cloud Script if you need this to be secure.

When multiple players are able to update Shared Group Data (even through Cloud Script), always write to a Key which incorporates the player's PlayFabId, so that there's no chance of two players trying to update the same Key with different Values at the same time.

10 |1200

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

ye avatar image
ye answered

why is is recommended to use shared group data? can player readonly data be used instead?

10 |1200

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

brendan avatar image
brendan answered

Yes, User Read Only Data can also be used for this. Shared Group Data is simply a convenience, so that you're not using up the User Data space for this. If that's not a concern, please do feel free to use it for this.

1 comment
10 |1200

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

Chethan V avatar image Chethan V commented ·

Hi @Brendan I see this thread is almost 6 years old. Is there any API call which can send a friend request to a player from another player now?

0 Likes 0 ·

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.