Understanding Multiplayer Architecture: Steamworks vs Gamesparks vs Both?
Think this is the best forum for this, but feel free to move.
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?
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).