Understanding Multiplayer Architecture: Steamworks vs Gamesparks vs Both?

Think this is the best forum for this, but feel free to move.

Hi all,

I’m struggling a bit to fully grasp the high level architecture for a game in UE4 (note, project this is for is Multiplayer MOBA). I see code plugins for things like Gamesparks and Gamelift which are scalable infrastructure services, but it seems like Steam also fills that niche, so I have a few questions.

  1. If you plan to distribute on Steam, do you need services like Gamesparks or does Steam fill all the roles where I no longer need to worry about databases, servers, etc?
  2. If you don’t distribute on Steam, I’m guessing Gamesparks fills that gap where you distribute it your own way and they fill the infrastructure/server piece?
  3. If they are all separate and since you don’t get your own Steam APP ID until you’re greenlit, is it smart/possible to use Gamesparks or something in the interim for quick multiplayer testing?
  4. Finally, in general, what’s the recommended architecture here? Of course, distribution is a different thing entirely which Steam obviously provides, but let’s say I decide not to distribute on Steam, am I going to be working harder in the long run deploying the multiplayer infrastructure on a service like Gamesparks?

Appreciate your help!

Hello,

  1. The Steamworks API does provide a lot of functionality. The most important functionality, in my opinion, is achievements, server lists, matchmaking, statistics, and saving player data in the cloud. On the last point, however, I recommend not using steam to save multiplayer data but use GameSparks instead for this. What do I mean by multiplayer data? It is data the player should not mattle with, like in World of Tanks the tanks the player has unlocked or in Overwatch the customes the player has unlocked. Most projects I have worked on use Gamesparks for initially storing player data and intended to port the data to a custom architecture later. None actually made it that far yet, thought it is a good approach nevertheless.

  2. It is perfectly fine to use both in the project, too. A project I used to work on planned on steam for saving player statistics, achievements, cloud data, etc. and using gamesparks for hosting the servers and matchmaking. You see while Gamesparks provides I think all the features that steam provides, in my opinion, you should not miss out on distributing on steam as Indie developer; it is where most your income will come from. And if you distribute on Steam, you really ought to use certain steam services, like achievements, because players simply expect those. Another point is that people are creatures of habit and most people use steam and are used to what they provide, like the Steam Overlay, which does not come with Gamesparks. With all that said, Steam generally provides those ‘side’ features while Gamesparks is best suited for a server framework hosting a bunch of servers.

  3. It is certainly possible but do consider that integrating gamesparks for the sole sake of testing mutliplayer is quite a waste of developmental time. A good idea would be to use the default implementation of IOnlineSubsystem, OnlineSubsystemNull, which provides an implementation for local area network games only. You can then establish a LAN using third-party software and join the session using mutliple computers. If you do not like Hamachi, like me, take a look at Wippien, which is easy to use; as well, it actually uninstalls properly and does not do non-sense you never asked for, like Hamachi.

  4. From a design point of view, make your code use the IOnlineSubsystem for all mutliplayer server framework, such as finding sessions, friends, achievements, etc. This way you can at any stage of development stick with the steam implementation, switch to another existing one, or even write up your own (the latter being quite a lot of work but it is possible). That way your main project code does not depend on where you distribute allowing you to focus on actual gameplay first and worry about distribution at a much later stage of development (it does not mean you neglect distribution though until it is nearly too late).

Cheers,
Univise

Hi there, sorry for the delay in replying your posts!

Univise has made some great points that I’d like to echo.

  1. While you can make use of Steam’s Matchmaking, Achievements etc… as stated above, it’s probably a good idea to use GameSparks in tandem with, and in some cases in lieu of the features that Steam provides. Cloud Save is just one example (you can retrieve a Cloud Save when you log in with GameSparks) but this also applied to things like Virtual Good Management, Player Messaging, Team/Guild configuration.

  2. Using both is the best bet here, we fill in a LOT of those gaps but we have a great relationship with Steam, in fact, you can even Authenticate a player using their SteamID. Launching on Steam is a fantastic experience that we hope you pursue!

  3. Depending on the type of Multiplayer you’re looking for this can be easy or difficult. We do offer Real-Time Multiplayer solutions, but as stated above, if you’re simply testing then this wouldn’t be appropriate. However if your game is more turn-based, then it is very easy to configure Events and Matchmaking to test basic Multiplayer.

  4. If you’re using a service like GameSparks, you should see it as an extension of your Game Engine. We’re here to make development easier, regardless of where you decide to launch you game on.

If you have any further questions about GameSparks please feel free to hit up our forums https://support.gamesparks.net/support/home or read through our tutorials https://docs2.gamesparks.com/ It’s free to evaluate too!