Few questions about Paragon lobby and game

[rajpootathar]

thanks alot man. I am going to implement the solutions and try it.

[anonymous_user_9d7a9e0b]

@'[EPIC

Josh.Markiewicz;549816’]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

In Paragon

Servers:

• 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

Clients:

• 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

Repeat

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.

The sheer amount of work and overhead expenses this represents is far too large for indie companies. Just hosting the amount of servers required…