EOS Online Subsystem: 2024 roadmap update

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:

• We’ve made good progress on the foundational work
• We now have to write our own code to better integrate with platforms and stores (and reduce our reliance on engine code no longer receiving maintenance)
• A new cross-platform presence system should improve both the player and developer experience in cross-platform games

The good news

First off, the good news. We’ve made significant progress on the foundational work required to support the future of EOS:

• Our new higher-level 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.
• We’ve shipped the new rooms system with support for lobbies, and updated 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.
• We’ve shipped a new user caching system, which internally allows us to retrieve information about EOS users outside of the 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.

Switching parties to use the new room system

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.

What are synthetic parties/sessions?

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:

• Write new code that relies on these older APIs that we know are broken and have a negative impact on developer experience, or
• Write our own store/platform support code that we have control over.

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.

Writing our own presence code

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:

• To send an invite to a platform (e.g. Steam) friend, we need to able to retrieve a list of platform friends, requiring us to replace IOnlineFriends
• To be able to advertise a local player as being in a party or session to the platform, we need to be able to set and query presence information, requiring us to replace IOnlinePresence
• For any presence replacement to be able to keep track of local users, it needs to know when local users are signed in/out, requiring us to replace IOnlineIdentity
• In order for us to sign users in and out, we need to be able to fetch metadata about users accounts, requiring us to replace IOnlineUser.

Of note:

• When we speak about replacing these interfaces, we mean internally - i.e. code written in 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.
• We’ve already shipped IUserCacheSystem to replace state tracked in IOnlineUser and we’re about to ship IIdentitySystem to replace state tracked in IOnlineIdentity.
• This work was eventually required to support the new online services (OSSv2) APIs, it’s just that it ended up blocking us on shipping party system improvements, instead of being deferrable to a later point in time.

Can we have cross-platform presence?

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:

• A cross-platform presence is handled by creating an EOS lobby when a local user signs in.
• This lobby advertises the current presence information, including current EOS party and session ID, as well as the local user’s platform user ID.
• Cross-platform presence will generate a “friend code” for the local player, and advertise it on their EOS lobby. Other players can then send friend invites to online players via a friend code, without needing the full product user ID.
• The plugin syncs the cross-platform presence back to the local platform whenever it changes, keeping the view of someone on the e.g. Steam friends list in sync with their EOS state.
• Presence enabled lobbies and sessions include the party/session IDs of the local platform, and users locally join those platform party/sessions when joining rooms. This doesn’t have to be handled by the party/session owner either, for example:
  • An Xbox player creates an EOS party, and creates an Xbox party, advertising the Xbox party ID in the EOS party attributes.
  • A Steam player joins the EOS party, recognises that no current member has created a Steam party for this EOS party yet, creates a Steam party and sets the Steam party ID as a party member attribute.
  • Someone else on Steam finds this EOS party through the Xbox player, joins it, sees that there’s an existing Steam party ID on an existing member’s attributes, and joins that Steam party. The Steam friend list/overlay can now show both of these players as being in the same party.
  • Another friend on Steam joins the party on Steam. Prior to that friend launching the game and getting into the EOS party, the owner of the Steam party will update their member attributes to signal to the original Xbox player that someone is about to join. Once the game launches, it discovers the EOS party ID from the Steam party attributes and joins it.
  • As this process happens, the players who own platform parties are reducing the “max players” of their platform parties so that once the EOS party is filled, these local platform parties will show as filled and not joinable on the local platform. This might end up with some odd looking behaviour where a player on Steam appears to be in a party with a maximum member count of 1 (since the EOS party is otherwise filled with non-Steam players), but we think this is an acceptable trade-off, and a significant improvement over the current behaviour where players on the same platform don’t show as in the same party or game at all.

We want this system to “just work” out-of-the-box as much as possible, ideally with no additional configuration or setup from developers.

Wrapping up

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.