A few questions about platform capabilities

Question

question

jashan asked Jun 6, '17

A few questions about platform capabilities

I'm currently evaluating both PlayFab and GameSparks to provide features that I originally planned to create myself (but that is probably a huge waste of resources, so the decision to use either PlayFab or GameSparks is pretty much made, just which one of those two we'll go with still has to be decided).

Our game currently uses Steamworks API heavily and will probably continue to do so in addition to any 3rd party platform for players that actually use Steam. However, we also plan to release for other platforms, like Oculus Home, Viveport and PlayStation 4, and would like to have a unified experience in addition to what the individual platforms offer. Also, some of the things we want to do simply are not possible using Steamworks API.

A few words about the game: Holodance is a Virtual Reality Multiplayer Rhythm game. After about a year of Early Access, we have sold about 4000 units, and given the adoption of high-end VR (HTC Vive, Oculus Rift + Touch controllers, PlayStation VR), if we ever get to 100,000 units sold, we'll call this game a huge success. So we expect to stay significantly below 100,000 MAU. Our peak so far was 1.3K MAU, 5K or 10K MAU is very likely, 20K MAU after official probably realistic.

So here is a list of requirements we have:

Unlimited number of Leaderboards because we have one for each song and there is no restriction of how many or which songs any player might play; with various segmentations based on play style, beatmaps and a few more. Those leaderboards are comparatively sparse (we currently have a lot of leaderboards with less than 10 players, and a few with more, and only one global one that has all players in it). I have seen that there is a limit of 250 leaderboards even for Professional / Full Platform, so that could be a deal-breaker.
Storing arbitrary data with each entry in the leaderboard and filter by some of those: One part of this is simply storing additional information, like an id that lets us look up the full play session, the environment used for that session; no filtering necessary for that one. But we also have data like different beatmaps for a given song, different game modes or numbers of players, where it does make sense to keep them all in one leaderboard but it's also important to be able to say "now show me only entries with this mode" or "entries with 1 player". Beatmaps in particular, will be a common filter in that scenario (we'll usually show only the entries for that specific beatmap, and only sometimes let players compare how different beatmaps for that same song work against each other). This also means that the leaderboard needs to store multiple entries for a single player (at least when the other variables are different).
I think this is "checked" (it's in the list of features): Connecting and disconnecting players from various platforms; e.g. a player could join from Steam but should be able to continue playing the game on PlayStation 4; so their Steam and PSN accounts need to be able to be linked. If that player stops playing on PlayStation 4, unlinking needs to be possible.
Can we also have custom platforms? Like Viveport, or Oculus Home?
Can we store player created beatmaps (JSON files) in the system? Players own the beatmaps they have created and should be able to set up who can see those beatmaps (private, friends, everyone) and also who can edit or clone those beatmaps. We need very fast lookup for beatmaps by ID (song ID, and also beatmap ID; one song can have many beatmaps associated with it but each beatmap only works for a specific song). Eventually, we should have many thousands of beatmaps, each approximately taking 5 to 50 KB.
Can we store player sessions (JSON)? Those only contain a small amount of data.
Can we store replay sessions and hook them up to the leaderboards (JSON)? These contain significantly more data because all movement of the player is stored, possibly with many moving objects (always head, left and right hand, but could be pelvis, two feet, two knees, two elbows in addition, for some players, up to full body motion capturing for very few players; we store 3d position and rotation in floats but using JSON bloats the data quite a bit). Reviewing some random play sessions (with only head, left and right hand, which is also most common), I see 1MB, 2MB uncompressed.

Sunny regards,

Jashan

Player Data Leaderboards and Statistics

10 |1200

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

Answer 1 · 2017-06-06T18:08:14Z

brendan answered Jun 6, '17

Yes, at this point, it doesn't really make any sense to build a complete backend for your own game, since a backend service like ours easily manages the majority of what you need, with unified player accounts across all platforms, and ensuring that you own your players and their data. That way, you can focus your efforts on the things that are key differentiators for you (like the actual gameplay).

For your specific requirements:

Technically, nothing can be "unlimited", apart from the number of players you can have. Our limits are designed to ensure that a title cannot cost more to run than we're actually charging (since I'm sure you'd want your backend to stick around long-term). But we can certainly work with you to provide as many leaderboards as you need - it's just a matter of making sure it's part of the contract we put together for you.
We provide access to the player profile (which includes other player statistics and arbitrary string player "tags") via the leaderboard API calls. As part of the Tournaments work we'll be doing later this year, we'll be enabling richer filtering options on leaderboards as well, so that you'll be able to get a different slice of your player population based upon elements of the profile. Currently, leaderboards store one entry per player, but given some of the work we're looking into for Tournaments (ex: racing games often have thousands of leaderboards, for each combination of car type, track, etc.), there may be other approaches in our future. I'd be interested in getting more details from you around your use cases on this, so that I have that for our design meetings.
Yes, we provide API calls to link and unlink all the various platforms we support, and we have some generic systems for any that we don't directly provide (though every major platform is in the list apart from Nintendo, and we're working with them on that now).
Yes, our generic sign-in mechanisms are one option there, but we're also looking into additional direct implementations for some newer platforms, as well as a more generic OAuth solution. If you have one that's a priority, making that work part of your contract would be the best plan.
We don't provide a generic User Generated Content (UGC) system yet, but it's easy to set one up in our service. Here's a link to a thread where we discussed that in more depth: https://community.playfab.com/questions/10054/user-generated-content-upload-with-attributes-sear.html. The discovery (search, ratings, etc.) part in particular is something you'd need to use an external table for right now, but we plan to add a UGC service in future.
Sure, you could easily store those in player data, either directly from the client if you trust it, or via Cloud Script (writing to player read only data, so that the client can read it, but not write to it) if you don't.
You'd use our Content (CDN) service for this. It would be fairly trivial to define a standard key naming system, so that from any given leaderboard entry, you could find the right data file. It might be as simple as using {PlayFabId}_{StatisticId} as the key.

15

10 |1200

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

jashan commented · Jun 06, 2017 at 07:05 PM

Ooops, posted an answer instead of a comment, could not convert answer to comment because it's too long but also cannot edit answer. Feel free to delete the answer (I apparently can't), I'll post this as comments.

0 ·

brendan jashan commented · Jun 06, 2017 at 07:30 PM

The answer was simply waiting on moderation (new users start with 0 reputation, and it prevents spamming), but I've deleted it.

0 ·

jashan commented · Jun 06, 2017 at 07:05 PM

That sounds all very good :-)

I think the key point for 1 is that while we may need many leaderboards, the traffic/load generated on your systems by our leaderboards is probably fairly small (except, of course, the actual lookup for a specific leaderboard which takes more time the more leaderboards there are). You mentioned the racing games use case, which seems to be very similar to ours. We can easily work around "single entry per player per leaderboard" and "filtering for specific game modes" in the leaderboards by creating more leaderboards and while this does generate more data, it may end up being more efficient.

What I meant by "unlimited" is that we need to be able to create a new leaderboard whenever a player plays a song that we don't have a leaderboard for. We could have only 10 players, and if each of those plays 10 different songs, that would be 100 leaderboards - but each one of them would only have a single entry. Basically, each song that exists is a "level" in the game that needs to have its own leaderboard because it's only interesting to compare players playing the same song.

0 ·

brendan jashan commented · Jun 06, 2017 at 07:33 PM

One key here is that there are multiple ways you can get all of a player's stats in one API call. To support a very high number of leaderboards, we'd likely need to do some work there to add a limit to the total returned (with a continuation code, potentially - similar to our segmentation queries).

In terms of the total number of statistics/leaderboards, what you'll want to do is decide what the upper limit is on that, for purposes of any contract discussion. We can always increase the total later by updating the contract.

0 ·

jashan brendan commented · Jun 06, 2017 at 08:17 PM

> One key here is that there are multiple ways you can get all of a player's stats in one API call.

Oh, I see ... maybe that is something we'd want to exclude in our contract ;-) ... I don't need that functionality and I can totally see how this could wreak havoc. As long as there is a way to get player stats without leaderboards we should be fine.

0 ·

Show more comments

jashan commented · Jun 06, 2017 at 07:06 PM

Re 2: I don't think we need any sort of player segmentation for the leaderboards except the obvious "show only friends". So, filtering a leaderboard by user profile properties is something that we will probably not use at all.

The arbitrary data I talked about was more related to the session. Like, a player could play a beatmap using only his hands, or his hands and the head, or with hands and feet. Or, he could play it alone, or together with other players (which will result in a combined score). From a data-design perspective that tries to avoid redundant data, it would be nice to have all of this in a single leaderboard, plus filters, so we can get the relevant data (this is a filter on session properties, not on player properties) ... but thinking about it, for performance it's probably better to have separate leaderboards for each case. This does mean that we'll have a lot more leaderboards (instead of one per song, it will be many per song; in fact, many per individual beatmap, there could be several beatmaps for any given song) but it might be a better way of doing it, anyways.

0 ·

brendan jashan commented · Jun 06, 2017 at 07:35 PM

What I mean is that the profile info will be useful for getting subsets of players based upon literally anything in the profile once we add that functionality. So there may well be ways you'll want to use this later. For example, you could use tags to indicate the play style you describe (hands only, etc.), and then filter on that.

0 ·

jashan brendan commented · Jun 06, 2017 at 08:23 PM

> tags to indicate the play style you describe (hands only, etc.)

But if that's part of the profile info, what about players that change their style? I might usually use both hands, feet and head but then, one of my friends tells me I'm a loser because I don't play like real men with only my left hand like he always does. So I check out his session history and play his favorite beatmap with my left hand to beat his highscore.

In fact, which "catchers" are used (left hand, right hand) will usually be determined at the end of the session, so it's usually not even something the player tells the system before playing a session.

One use case that may be interesting for us is a kind of "handicap" feature: New players may want to compare themselves to other new players instead of getting frustrated by the skill level of advanced players. So a skill level or hours played player filter could be really nice to have.

0 ·

Show more comments

jashan commented · Jun 06, 2017 at 07:06 PM

I guess what we'll end up with is very few (less than 10, probably less than 5) "global leaderboards" that are based on player properties like accumulated score (that's kind of a "grinder leaderboard"), and skill-based scores. These leaderboards will be heavily populated because every player will have a rank on those. Then, we'll have a huge amount of sparsely populated leaderboards, probably with a bit of redundancy, like: One "song" leaderboard for each song, which mixes different beatmaps, different play styles and so forth, maybe a beatmap leaderboard for each beatmap (similar to the song leaderboard but specific to the actual gameplay generated for that song), and finally, several specific beatmap-leaderboards that separate different play styles that are usually not fair to compare (like, players only using their hands, players using head and hands and so forth).

0 ·

jashan commented · Jun 06, 2017 at 07:06 PM

I'm not sure how 7 would work with such a system. Sessions stand on their own, so players could browse their sessions globally (e.g. just a chronological history of their sessions), or by song, or by a specific beatmap. Or they could come from a leaderboard that stores the score of a session (song or beatmap or any of the specific leaderboards).

0 ·

brendan jashan commented · Jun 06, 2017 at 07:36 PM

Those would be the two simplest. A player checking his own history would have the data stored in player data, most likely, while a leaderboard as a way to look up the info you need to find the key is straightforward.

0 ·

jashan brendan commented · Jun 06, 2017 at 08:27 PM

> while a leaderboard as a way to look up the info you need to find the key is straightforward

So I can store arbitrary data with the leaderboard entry? For this use case, I don't need to filter - all I need is to retrieve that information with the rank, score, player and so forth.

Thinking about it, given that those leaderboards are usually fairly sparse, I can simply get all entries and do any filtering I might need on the client.

0 ·

Show more comments

question