question

juuso avatar image
juuso asked

Example datamodel for storing entity states? (for example async chess)

Hi,

I've researched and made a small tech demo for using Playfab and it seems like there's great many things that work out-of-the-box. Things like inventories, character data, save data, leaderboards and more. All stuff related to game "content".

I would like to know how one would go about doing a chess game. Let's think of one match between 2 players.

I went through the forums, docs, and assume "Shared group data" (for 2 people) would be the answer. I would like to see an example how chess data could be stored in shared group data (or elsewhere). Not the matchmaking info, but the actual info about player moves (or chess piece locations).

Let's assume cheating is not an issue.

Could the shared group data look something like this:

{
playerIds: [123,456],
whiteKingPosition : "g2", 
blackQueenPosition: "b3",
...
}

Or maybe something like this:

{
players: ["white:" 123, "black":456],
units: [
   ["position": "b6", "color": white, "piece": "king"], 
   ["position": "c5", "color": white, "piece" :"queen"], 
]
...
}

Of course "it depends on your game", but I'm interested in best practises here and also about the limitations of the shared group data (if that's the way to go). Assuming scenario with no-cheating (or using cloud script for handling those), async gameplay (no update problem), assuming matchmaking has been taken care of.

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.

1 Answer

·
brendan avatar image
brendan answered

The player data and shared group data key/value pairs are simply string/string, so it can be any format you like, but JSON is one of the more convenient ways to store data, so either of the models you presented would be fine. For a chess game, you might want to keep the history of moves for the game-to-date in a KVP in the data, for purposes of double-checking the state for potential cheating.

I'm not clear on why you're discounting cheating, updates, and matchmaking as problem spaces though, since those are some of the most critical elements. In particular, and specific to the limitations of shared group data, is the question of updates. Since we don't currently have a persistent socket connection to the client, it's not possible to notify the client when the opponent has taken their move (apart from Push Notifications or emails). So currently, if you're not using a dedicated server to host the game session (which would take care of all three issues), you would need to poll to check the state of the data. But since it may be quite some time before the other player makes a move, you shouldn't do this often - every couple of minutes would suffice.

4 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.

juuso avatar image juuso commented ·

Thanks for the answer Brendan. You have really helpful comments here on the forums (I've read quite a few).

How would history of moves look like? I don't know exact limits for those key-value-pairs so I'm not sure how one would store 1000 moves of a long chess game 8)

---

As for cheating/matchmaking: I mean, I don't worry about that now in the scope of this question. If somebody cheats in cooperative game with their buddies, that's fine by me. And yes, for competive games I go by mantra "never trust client". Matchmaking has been discussed in other topics so I don't think it's that important for the datamodel (maybe it is, just assuming it isn't :)

0 Likes 0 ·
brendan avatar image brendan juuso commented ·

Well as you say, it depends upon the game. But chess moves are pretty simple, given that a complete game could be expressed in simple notation (ex: http://www.chessgames.com/perl/chessgame?gid=1011478). So the majority of games could actually fit in the essentials tier limit for player data (let alone the indie/pro tier limit). So it would be fairly trivial to store that in a JSON object (stringified).

0 Likes 0 ·
juuso avatar image juuso commented ·

Thanks.

So, continuing with that chess example:

1) How those limits work? (I'll be aiming for "indie" tier by the way, at this point). I'm not sure if I understood what "1000 byte" limit means for Shared Group Data for example. Does it mean that when doing https://api.playfab.com/documentation/client/method/UpdateSharedGroupData then the "Data" can hold up to 1000 bytes (utf-8) for free tier?

Keeping in mind I'm total newbie for what it comes to Playfab. :)

2) If one shared group data contains values for one match, how would I go about storing N number of matches, each containing X amount of moves?

0 Likes 0 ·
brendan avatar image brendan juuso commented ·

The limits are a hard limit on the total number of characters in the string which is the value. So each KVP which has up to N characters in it, where N is your limit. It's also worth noting that it's a good idea to use fewer, larger KVPs, rather than a lot of little ones.

For storing multiple matches, it depends upon your use case. In general, I'd recommend storing the player's history in player data. Shared group data would really be best used for games in progress. Obviously, you have a limited amount of space to work with. Storing every game they play for all time may not be possible, particularly in the free tier.

1 Like 1 ·

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.