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.