Crossplay between Steam and Epic while using OSSv2 Lobbies

Development Programming & Scripting Multiplayer & Networking
, ,
1

We are developing a title that using OSSv2 and Lobbies with 2 builds, one steam, and one EOS build.

We have a steam build that uses OnlineServicesEOSGS that allows the user to use their steam login as an external auth to EAS without requiring a linked EAS account.

We also have an EOS build which uses OnlineServicesEOS (not GS) which uses an EOS login.

Both builds can host a listen server that users on the same build can can connect to, but the opposite build cannot connect to it.

I looked at the connection process and when the steam client logs in to the EOS host, the EOS host tries to creates the unique id from the login data using [FOnlineAccountIdRegistryEOS::FromReplicationData] and then attempts to call this function [FOnlineAccountIdRegistryEOS::FindOrAddAccountId]

FAccountId FOnlineAccountIdRegistryEOS::FindOrAddAccountId(const EOS_EpicAccountId InEpicAccountId, const EOS_ProductUserId InProductUserId)
{
  FAccountId Result;
  const bool bInEpicAccountIdValid = EOS_EpicAccountId_IsValid(InEpicAccountId) == EOS_TRUE;
  const bool bInProductUserIdValid = EOS_ProductUserId_IsValid(InProductUserId) == EOS_TRUE;
  if (ensure(bInEpicAccountIdValid || bInProductUserIdValid))

And that “ensure(bInEpicAccountIdValid || bInProductUserIdValid)” gets triggerred because it looks like its expecting an Epic unique Id (instead of a Steam id).

Honestly, it looks like an OnlineServicesEOS and OnlineServicesEOSGS build are not crossplay compatible with each other since their FromReplicationData parse the buffers differently.

My intuition is that both builds need to be using the same OnlineServices, which seems to imply that it must be OnlineServicesEOSGS since OnlineServicesEOSGS can support both id types (vs OnlineServicesEOS which doesn’t appear to support other platform ids).

If I try to just use OnlineServicesEOSGS without providing a Platform service, things like the PresenceInterface doesn’t work since it doesn’t get added by OnlineServicesEOSGS the same way that it does with OnlineServicesEOS. What I came up with using the OnlineSubsystemEOS and the OSSAdapter, with the windowsengine.ini having these settings:

[OnlineServices.EOS.Auth]
EASAuthEnabled=true

[OnlineServices]
DefaultServices=Epic
PlatformServices=GameDefined_0

[OnlineSubsystemEOS]
bEnabled=true

[/Script/OnlineSubsystemEOS.EOSSettings]
bUseEAS=True

[OnlineServices.OSSAdapter]
+Services=(Service="GameDefined_0",ConfigName="GameDefined_0",OnlineSubsystem="EOS",Priority=1000)

This way, it tries to use the OnlineSubsystemEOS as its PlatformService, but it doesnt seem like an ideal solution. I believe this other [Content removed] encountered the same issue which is why they were similarly setting up EOS Service with EOS subsystem, but they appear further in development and are encountering double login issues in a production environment. I bookmarked that thread since maybe whatever solution they do would work for us. Are we going about this all wrong? Is there a better way to have the two crossplay builds connect to each other?

2

OnlineServicesEOS adds Account and Social Features (Epic Account Services) to OnlineServicesEOSGS. The design is for games to either use Game Services only OR to use Games Services with Account Services. Having OnlineServicesEOS enabled in one build and OnlineServicesEOSGS enabled in another build isn’t a scenario we’ve tested.

Is the idea here to allow players to choose whether or not to login with an Epic Games account? The SDK does support this flow, but the plugins at the moment do not. You’d need to modify the OnlineServicesEOS plugin to follow the login flow described here.

3

For our steam build, we don’t want to use EAS, only EOS Connect w/ a steam external auth flow, which looks like it is currently only supported by OnlineServicesEOSGS

For our epic build, we have to use EAS or else there is nothing to auth with, right? That looks like it is only supported by OnlineServicesEOS.

Are you saying we have to modify the OnlineServicesEOS plugin to support the EOS connect flow?

If that is the case, I took a look at it and it might be easier for us to support OnlineServicesEOSGS logging in to EAS just for the Epic build. Or am I misunderstanding how the flow is supposed to work

4

Sorry for the misunderstanding. I thought you wanted to give Steam players the option to log in with Epic. Yes, for your Epic build, you have to use EAS.

All of the Auth, Presence, etc… code for EAS is in OnlineServicesEOS. Depending on what you need, I’m not sure if modifying OnlineServicesEOSGS is the right approach. Interestingly enough, this is the first time this has come up. Do you have a detailed list of all the issues you encountered when testing crossplay between OnlineServicesEOS and OnlineServicesEOSGS?

5

I only went as far as the first roadblock which is that they can’t connect to each other. The protocol in OnlineIdEOS and OnlineIdEOSGS for ToReplicationData and FromReplicationData are expecting different things (like the buffer for OnlineIdEOS has some extra space for the EAS bits and a flag bit, but OnlineIdEOSGS does not). I made some attempts to get them to talk to each other, but it quickly broke no matter which way I tried it (converting EOSGS to the EOS buffer format didn’t work and neither did the opposite) since many of the surrounding systems made assumptions about the data.

While many of the EAS services are supported by OnlineServicesEOS, aren’t they also supported by the OnlineSubsystemEOS? In the world that we use OnlineServicesEOSGS, OnlineSubsystemEOS would be treated like any other OnlineSubsystem (like Steam). In some ways, it may make things easier since they are more consistent between different builds

6

Yes, OnlineSubsystemEOS supports EAS features. OnlineSubsystemEOS (OSSv1) differs from OnlineServicesEOS and OnlineServicesEOSGS (OSSv2) in that it incorporates both EAS and GS features within the same plugin.

This seems like a legitimate use case we simply haven’t designed the OSSv2 plugins for. I’m going to bring this up with the team.

I understand the idea here. Use OnlineServicesEOSGS, and for EGS builds only, use the Adapater with OnlineSubsystemEOS. I definitely recommend using the name platform feature I mentioned in the other thread, so both plugins use the same EOS_Platform instance. Can you test this scenario? We haven’t tested this on our end. I think it might work, but you might need to think through which calls should be replicated to both plugins. For example, you’ll need to call Login in both plugins, but you likely shouldn’t call CreateSession in both plugins for the EGS case. That may differ for Steam or other platforms if you want to mirror the session.

7

makes sense. We will try it out