Some [many] modules (mostly the v2 ones) feel like alpha or beta. When I used PF in 2016 - apart from a few things - most modules and even docs were intuitive, cleanly coded, well-documented, sync'd.
However, ever since the v2 modules (Microsoft/Azure), nothing seems as it should - nothing feels intuitive. Things are missing, broken (completely), undocumented.
See below for a list of oddities that I hope PF staff can fix in the near future. For now, this should help raise awareness so you don't have to repeat my mistakes on lost dev time:
(1) Client::Matchmaking does not working at all due to GameMode no longer existing.
No warning in the API docs - no link to recommendations. The overview description is 2 redundant words: "Matchmaking APIs". The old API doc descriptions would often have multiple paragraphs.
(2) Matchmaker does not work at all due to GameMode no longer existing.
No warning in the API docs - no link to recommendations - low effort overview description again.
This looks like a "newer" version of Matchmaking since it has more features; who would know there are 4 matchmaking modules, all with different severe limitations?
If there are 2 matchmaking modules completely broken (in a literal sense - it cannot be used unless you have a legacy account), why are there no deprecation banners and links to the new ones?
(3) PF OSS SDK has crippling limitations such as not being able to create premades or use the Multiplayer::Matchmaking API
If there is a warning regarding this, it's buried when it should be front+center. This renders any non-mobile games using OSS for matchmaking useless; something folks would love to know ahead of time.
Mac/Linux support is also killed here. I hear also Android (IOS too?).
(4) Why does the Unreal Matchmaking quickstart guide talk 90% about the Multiplayer::Matchmaking module, then a good 1 sentence mentions polling using OSS, as if you could interact with the 2 SDKs for matchmaking (you cannot)?
(5) Matchmaking and Lobby events are completely missing without using a completely external SDK despite the old APIs having ezpz event callbacks (as if the new ones are still in alpha testing).
This contradicts the misleading docs likely talking about the obsolete APIs that do not work, yet are still left here when it's not the case at all:
The client SDK simplifies your work for cross-network and cross-platform play by handling real-time notifications for you. Notifications are sent to clients on receiving invites, joining and updating lobbies, finding matches, and more. The client SDK enables cross-platform play and real-time notifications on any platform that PlayFab offers SDK support. Sending notifications to clients is automatic, and the developer doesn't have to do any work to enable notifications.
Update 3/12/2022: If you use the core SDKs Multiplayer::Lobby::CreateLobby, PF staff confirmed it creates a "stateless lobby". You cannot update it. You cannot query it. You cannot find friend lobbies. In other words: Pointless. This means you cannot even utilize the sister funcs like FindLobbies, FindFriendLobbies, UpdateLobby, etc -- what's the point of even having these? No one knows. Is it doc'd, despite being absolutely breaking? No. Is PF aware? They seem to have been aware for 2 years, if you dive into forum questions and check out the dates answered. This seems to further support the theory that all v2 APIs are rushed to simply save Microsoft money by porting to Azure without caring for stability/features/docs left behind.
Update 3/12/2022: If you use the core SDKs Multiplayer::Lobby::CreateLobby, PF staff confirmed it creates a "stateless lobby". You cannot update it. You cannot query it. You cannot find friend lobbies. In other words: Pointless. This means you cannot even utilize the sister funcs like FindLobbies, FindFriendLobbies, UpdateLobby, etc -- what's the point of even having these? No one knows. Is it doc'd, despite being absolutely breaking? No. Is PF aware? They seem to have been aware for 2 years, if you dive into forum questions and check out the dates answered. This seems to further support the theory that all v2 APIs are rushed to simply save Microsoft money by porting to Azure without caring for stability/features/docs left behind.
(6) Friend systems don't even natively have request/approve, despite every game having this.
No dev would expect you would have waste dev time reinventing the wheel for a feature found standard in pretty much every game with friend systems.
(7) The new APIs unnecessarily require more API calls - and some hidden ones.
For example, if I have a matchId, I can't simply join a lobby with a matchId - I have to GetLobby() to get a connection string, then join. Another example is for Auth, I can't simply pass a display name at register. Another, for Groups, I can't pass any arbitrary data to the groups (eg: for Clans) -- I have to create it then pass just the arbitrary data. Optional? Great. Required? Tedious, unnecessary, extra API calls.
In regards to hidden: When you call a cloud script, why would there be a proxy fee if we're using Microsoft Azure with Microsoft PlayFab? This made sense when PF was AWS-based, but why is this still here if we're going from Azure to Azure? This is also not documented (or buried) when reading about cloud scripts.
(8) There's no warning that PF devs can't help you with Azure - it's extremely difficult to actually get Azure setup, working and with collaborators:
The biggest gripe was how easy the docs made it sound to setup cloud scripts with a vague link to a non-PF Microsoft doc for how to setup Azure. You can't just write scripts, you need the entire Azure infrastructure setup. Expect to spend a massive amount of time on this because it's just raw Azure. It's like if I just sent you a generic guide to "how to use AWS".
PF devs will not assist you in any form with Azure - not even how to collaborate with others (assuming you're not a solo dev). When you get vague errors for following Microsoft (not PF)'s minimal guide, since the guide is not specific to PF, you are not actually getting what you want.
The quickstart pushes you to a Windows Azure build without any disclaimer mentioning you are charged 50% more for Windows vs Linux. They also guide you to use a semi-premium setup instead of the free cores.
No guide mentions that if you click on "free trial" for Azure, you actually can't even use the features since Functions require 64-bit when the free trial limits you to 32-bit. This is something a PF-specific Azure guide could resolve, but none exists. PF staff was completely unfamiliar with the topic - for what seems like it should be a common issue, no PF staff was able to resolve this (only a delayed Azure support). I don't believe any PF staff is actually trained in Azure.
(9) Unreal OSS docs are a mess.
Even at the start, the only documentation is to setup before you even open the code. Want entry points? Best practices? Code examples? OSS to PF map of vocab? You won't find it.
No online documentation, no inline documentation, no support. Similar to Azure, no PF dev seems to actually know about OSS. For what little documentation is offered, they refer to the C++ documentation and C++ SDKs (not to be confused with Unreal SDK; we're talking raw C++, vastly different than the Unreal C++ architecture). You have no clue where the entry points are, how the limitations are, how OSS interacts with the marketplace plugin SDK (it doesn't interact with each other at all). This is essentially just a dump of code that seemed to miss the lecture on how to write standardized documentation for collaboration.
While you may expect the inline docs or param names to match the PF vocabulary, this does not happen. The [outsourced?] folks that made the OSS SDK clearly had no clue what PlayFab even was - it's just a generic OSS SDK (opposed to a PF OSS SDK). You have completely different arg names that leave you in absolute confusion as to what you actually are working with. For example, PF LobbyId == OSS ResourceId. How could anyone possibly know this? Now that's just a single example: take that and compare that vs 30 other args with differently-mapped names to the PF docs. You're poking and prodding in the dark, like a legacy phone operator with unmarked wires/holes. There are 0 API references to the OSS SDK.
Since the marketplace SDK's Multiplayer::Lobby::CreateLobby (undoc'd) creates a stateless lobby, you would only know by directly asking PF staff that you need to create a lobby from OSS. Since Matchmaking has 0 interaction with the marketplace plugin, does Lobby also have 0 interaction? Who would possibly know without asking PF staff directly? If there's no interaction between the two, what is the point of the marketplace plugin FindFriendLobbies, for example? But if they do interact with OSS and the Matchmaking module doesn't, this creates even more confusion!
This is undoc'd, but so are many other oddities -- from what I've seen in PF forums and Discord, it seems like OSS SDK can't be built in Win64. This means no Linux/Mac/console. No PF staff has confirmed or denied this - since no PF staff seems familiar with OSS, we can only assume this is correct and be cautious.
3/15/2023 Update: Asked questions here and with more specifics here after getting answers that did not suffice (Epic's OSS docs do not suffice, since terminology diffs and restrictions alone are enough reason to have PF wrapper docs).
(10) Socket-based events were removed in v2, obsolete in v1
As if the SDK/API changes are in alpha, there is so much missing from "v2". One big one is event callbacks so you don't have to pull. Socket-based callbacks. OnLobbyUpdated(Result), for example. Usually you just sub to it and whoo it works! This used to be the case, even. However, you must setup an external SignalR app that, like Azure, PF has nothing to do with. You're on your own; and it's complex.
What's worse is that you don't even know this until you get to it. Let's take a look at at example for Multiplayer::Lobby::SubscribeToResource API doc. The meager and redundant description is "Subscribe to lobby resource notifications.". If you CTRL+F, you won't find a single mention of SignalR. You won't find external links to a guide. You won't find... anything. How could anyone possibly know? You don't - until you're already locked in and coded this stage, wondering what to actually pass to these args.
Let's look at ResourceId arg description for the link above - "The name of the resource to subscribe to." Not only is this useless info, there's still no hint as to what this is - no mention that this is actually a MatchId (randomly name-changed). How about "PubSubConnectionHandle"? Opaque string, given to a client upon creating a connection with PubSub.** Where's the link to PubSub? Wait, I though it's SignalR? This is yet another naming inconsistency that causes confusion, especially with no links. Why would there not be a link to what PubSub actually is - and isn't - as legacy PubSub is different from the SignalR PubSub. All kinds of confusion, here.
(11) Inconsistent Naming - args and SDKs
Leading in from #10, there are all kinds of naming inconstancies.
PubSub != SignalR. Events == both SignalR and OSS, but context is generally not included; you must guess. There are also references to the legacy PubSub that was actually named PubSub.
ResourceId == MatchId
Unreal OSS SDK == Multiplayer SDK (not to be confused with the also-named Multiplayer/Party SDK) == Game SDK (but the marketplace plugin is also sometimes called this) == Client SDK (again, the marketplace plugin); Matchmaking SDK (not to be confused with the 4 other matchmaking modules); but != the C++ SDK linked... from the Unreal quickstart. Confusing! There actually is no guide for Unreal OSS; only a pure C++ one mentioned above.
Multiplayer SDK != Multiplayer:: API. Party SDK == Multiplayer SDK. Now what's confusing is that The Multiplayer SDK is also referred to the OSS repo, which is completely different. They refused to change the name of the repo for parity's sake.
For APIs: Matchmaker != Matchmaking != Client Matchmaking != Multiplayer Matchmaking. Generally talking about "Matchmaking" often swaps back and forth between the OSS SDK and Multiplayer::Matchmaking ... despite not being able to interact with each other.
Marketplace SDK == Core SDK (which is also named in OSS) == Client SDK (also named this in Unreal OSS).
"V1" APIs and "V2" APIs are also mentioned often in the forum/chat, but never actually in official documentation. At one point, a staff member said "there is no v2 API", despite being thousands of mentions of v1 vs v2 from staff in both forum and Discord.
(12) No inline documentation
Now, this may just be Unreal or the new APIs because I remember back in 2016 the docs used to be awesome when I used Unity.
Expect 0 inline documentation, even if it involves breaking modules (like the Matchmaking confusion above) -- and even if it requires external SDKs (like OSS / SignalR mentioned above).
(13) Extremely low-effort models in Unreal
You will find some deeply-nested callback models simply returned as a single TMap field of implicit (untyped) key-vals, forcing you to create custom models. I was just shocked to inconsistently see this multiple times. Whoever was managing this SDK clearly did not quality check.
There are 0 utils for CPP and BP parsing - you must reinvent the wheel and unnecessarily create your own custom models just to parse between Cpp and Bp. No constructor overloads. Nothing.
The annoying FEntityKey object wrapper that is different in every single namespace. For example, when interacting between Auth, Matchmaking and Lobby (a common trio), you can't just wrap 1 FEntityKey -- you need to remake it each time for that specific namespace, despite being the exact same object. 0 utils for this, no constructor overloads, no helpers -- just more low effort models.
(14) Unexpected Party SDK Limitations
I haven't looked into this, but I keep coming across it in my search (since Party and Multiplayer keywords often intermingle, I often pop across this topic). If you plan to use the party SDK, dive into the forums and Discord to see what I'm referring to.
Heck, this is just what I came across so far - and what I remember. The experience has been rough. I hope this helps others, and helps PF fix some breaking issues that really destroy both sanity and workflow.
