This is a humongous question, but I’ll do my best to describe most of the high level details.
As many of you know, every place in the game is a “map”. The engine can run in several modes (client/dedicated/listen/standalone).
In this case Paragon has several maps (main menu, lobby, Agora, transition map)
- transition map is an empty map used to garbage collect between real maps when using seamless travel
- connecting to a server always requires a hard travel, once connecting travelling between maps can be done seamlessly
– hard travel requires a loading screen
– seamless travel ticks the engine, keeps network connections open, can even work with Actors/RPCs
- leaving a server back to main menu is also hard travel
- dedicated servers are running, advertising with our session backend (IOnlineSessionInterface), but devoid of game configuration, waiting for a client to contact them via beacons
- probably a little much (and possibly I’m not allowed) to go into details about our cloud hosting, but Linux instances are running, monitored, and autoscaled
- the important part is that they are preallocated, not spawned on demand. We keep a buffer of servers and spin up/down based on that
- start in the main menu as a standalone map with no networking running.
- the party system uses XMPP to connect social party members together for an evening of gaming.
The party API is a higher level construct that provide UStruct and other simple POD reflection of data to other party members to share
- party state (UParty, UPartyGameState)
- party member state (UPartyMemberState)
- signaling what server to join
- signaling matchmaking progress
Matchmaking occurs, using the session interface and the beacon classes to find and join a server
- party leader find preexisting games already being filled to join first
- failing that, empty servers are contacted by the party leader, told to configure themselves for the right game type, and load into a lobby map ready to receive new players
- beacons (UOnlineBeacon) are used to make reservations on the server
– in a high concurrency game, prevents dozens or hundreds of players from rushing the same server
– provides a guarantee that one particular server will make/have room for you
- beacons are used to keep all clients in contact with the server until the server is full of players
– makes searching for another match easy if things go wrong
– real server travel is expensive (hard travel and therefore loading screen, full map load, etc) and hard to recover from gracefully (ie automatically getting back into matchmaking)
- server fills up on the beacon, notifies all party leaders to tell their party members to connect “for real”
Regular Unreal networking occurs
- connect to the lobby map as any UE4 game would (ClientTravel(URL))
- normal server logic, replication, RPCs, client logic
- additional xmpp chat lobbies for teams
- draft lobby ends
seamless travel into our game map
- game ends
- players return to main menu, keeping their xmpp connections intact the whole time for both rooms
- post game ends, team chat is destroyed
Super high level, hope it helps, I can try to field more questions, we’ll see how it goes.
This may be a little dated, but here is a linkto a GDC talk I helped write (but didn’t give) that describes how Gears of War 3 (and Judgment) did this. It was my first iteration on dedicated servers. The hosting information isn’t as relevant, but some of the work around servers certainly is.