It’s been a while since the initial roadmap plan for 2024 for EOS Online Subsystem, so I thought I’d do another update on how we’re tracking and what the latter half of 2024 will look like. Spoiler alert: The initial timeline was overly optimistic, and there’s been a few unforeseen issues that will mean it takes us longer to complete the outlined roadmap.
Once again, this is a long post, so for those of you that want the tl;dr, here’s the summary:
First off, the good news. We’ve made significant progress on the foundational work required to support the future of EOS:
RedpointEOSAPI
module for calling the EOS SDK directly is now stable design-wise, and is available for developers using the Marketplace Edition. While it doesn’t yet cover every SDK call, adding new call wrappers is now trivial thanks to the extensive macros in place. This new API also handles string marshalling, logging, performance tracing, asynchronous callbacks, exponential back-off and automatic retries, which is vastly reducing the time taken to write new code interacting with the EOS SDK.IOnlineLobby
to use it. This includes emulating lobby member lists on search results, enabling the Matchmaking plugin to work on newer versions of the EOS SDK.IOnlineUser
interface in the online subsystem (OSSv1). This work was an eventually required to allow us to implement the new online services (OSSv2) APIs, but ended up happening sooner due to a string of unforeseen dependencies in switching IOnlinePartySystem
over to use the new rooms system (which I’ll get into in a moment). As an added benefit, users fetched through IOnlineUser
now include information about the Epic Games account linked to that user, if present.We also fixed a ton of bugs over the last 6 months, improved VR/XR support and did a lot of internal refactoring.
After tackling IOnlineLobby
, we started to work on switching IOnlinePartySystem
over to use the new rooms system underneath. This work has been almost entirely completed, and has allowed us to internally add support for “password protected parties” (where a joining player needs to know a password to join the party), but this code is not yet enabled by default.
Blocking the new party code from shipping is now the implementation of “synthetic parties/session” code, which is very old and relies on the engine’s platform integrations into e.g. Steam, etc. in order to function.
If you’ve never used synthetic parties/sessions in the plugin, it is the feature that enables players to join parties or games through their local platform overlay such as Steam. Instead of developers having to integrate each platform manually, the plugin handles advertising the EOS party/session on the local platform to enable invites and “Join Game” behaviour:
The synthetic party/session code was written very early on in the development of EOS Online Subsystem (in 2020), at a time when modules such as OnlineSubsystemSteam
were still seeing maintenance by Epic Games. We relied on the engine providing a “good enough” online subsystem integration for various stores and platforms that we could rely on that engine code to implement synthetics.
However, as 2024 rolls on, it is clear that much of the store/platform code in the engine is no longer receiving the maintenance required for a good developer experience. As an example, the Steam online subsystem is still hard-coded to only find sessions that are geographically nearby, it’s been like this for years, and there’s no fix other than patching the engine. It appears most of the upstream development around store/platform code is focused on OSSv2, and the existing APIs we’re relying on here aren’t going to be updated or fixed any time soon.
As we write the new IOnlinePartySystem
implementation, there’s really two options:
We’ve decided to go down the latter route. While it’s more short-term pain now in the sense that it extends our roadmap, it will ensure that we’re able to fix and improve platform integrations regardless of whether engine code is deprecated or unmaintained in the future.
In order to be able to extricate ourselves from our reliance on OSSv1 APIs for presence and synthetic invites, there are quite a lot of knock-on effects:
IOnlineFriends
IOnlinePresence
IOnlineIdentity
IOnlineUser
.Of note:
RedpointEOSRooms
should not rely on the OSSv1 IOnlinePresence
interface to do it’s work. These interfaces will still be available for developers to use in game code.IUserCacheSystem
to replace state tracked in IOnlineUser
and we’re about to ship IIdentitySystem
to replace state tracked in IOnlineIdentity
.Now we could implement our new presence system with a strict focus on the local platform - simply track and advertise presence information on e.g. Steam, and leave presence for cross-platform friends unavailable. This is how the current system works. If you’re playing on Xbox, and you have a Steam friend on your friend list because you’ve been playing on both platforms with the same account, the Steam friend will also show as offline, even if they’re currently in-game.
It’s been this way for a long time, since the EOS SDK’s presence APIs require the use of Epic Games accounts, and there wasn’t really a clean way of supporting cross-platform presence with the built-in engine online subsystem APIs.
However, if we’re reimplementing both presence and our local platform integration code, we now have an opportunity to implement cross-platform presence such that, even if your friend is on another platform, and even if the game isn’t using Epic Games accounts, you’ll be able to see them as online, and join their EOS party/session.
Our design goals for this cross-platform presence overhaul is as follows:
We want this system to “just work” out-of-the-box as much as possible, ideally with no additional configuration or setup from developers.
Hopefully this a guide on what to expect over the next 6-8 months of development. Once this work is complete, we’ll have a suitable replacement for the existing synthetic parties/sessions code, we can switch to the new IOnlinePartySystem
implementation, and then proceed with the remainder of the roadmap.
If you have any questions about this work, feel free to ask in the sales-questions channel or the eos-online-subsystem support forum in the Discord server.
All code examples are MIT licensed unless otherwise specified.