Question Connect to server to only receive snapshots for Spectator mode..

Hey Ali_Bakkal!

This is supported. Simply have the spectator client connect to the server (using the same flow as if they were an active player participant in the match). You just need some way for the server to identify these clients as spectators.

• E.g. By the user selecting "spectate" button in the UI, sending an RPC to the server informing said server that said client wants to spectate.
• E.g. By having your "parties & matchmaking" backend (whatever flavour of matchmaking your using) communicate to the game server the list of client GUIDs (and/or their join tokens) which are "players", vs the list which are "spectators".

The server can then use this info to:

• Correctly not spawn any "player ghost character controllers" for these spectators.
• Correctly spawn "spectator ghost character controllers" for these spectators, allowing them to fly around the map (for example).
• Correctly assign GhostOwnership (via the GhostOwner component) to the correct character controller.

 

Side note: The "Server whitelist" is important for its own sake. Why?

• Security: Every time the matchmaker backend creates a successful match, it should generate one "join token" for each player. It should send said token only to the client who needs it. The matchmaker backend will then forward those player GUIDs + tokens to the game server, which would then authenticate all joining players. How? Clients (when joining) can then send their own GUID + token via client RPC. The server will kick all invalid RPCs, and kick players who do not provide the aforementioned RPC within a time limit.
  
  This prevents both malicious and accidental joins.
• Correctness: Accidental joins can happen in a few cases:
  • You may have a mechanic that automatically attempts to reconnect a player if they DC from the game. If we assume this flow takes roughly 30 seconds, you could have a situation where this players match has finished, and a new match has started on that server. In this case, you do NOT want the re-joining player to be allowed into that match. The above whitelist will correctly kick said player. You may think that the reconnecting player should check with the matchmaking backend FIRST (to confirm that said match is still live before re-joining), but the game server is the authority over the match itself, so doing it the other way around is better.
    
    E.g. Attempt to re-join. If it succeeds, fine. If it fails, check match status with the matchmaking backend. If the match is finished, fine, otherwise, attempt to re-join the game server until success.
  • If your matchmaking backend has a bug, you may erroneously attempt to connect multiple sets of players to a single game server. The game server whitelist communication event can be used to raise errors, for dashboard tracking, allowing you to identify these issues even if players do not report them.
    
    Example log: "I (the game server) have not yet finished this match, but the matchmaker is requesting I start a new match with a new whitelist. Returning error XXX to matchmaking backend, and continuing this match until completion!"

I've seen both of the above issues show up in live games over the years (in prod).

 

You don't need to create a spectator ghost character at all. The only requirement is that you just make the network stream in game (by adding the NetworkStreamInGame component) on both server and client and you will just received snapshot data, without need to have character or player or anything similar.

If you want to fly around the map, you technically still don't need to have a character or a player entity on the server either. It is just locally controller by the player This is ok for simple scenario, where there is no relevancy involved or prioritisation necessary.

If you need to prioritise ghost, based on the "spectator" position, then an entity is necessary. And that will just use the regular commands as you usually do. Just don't have any "representation" and it is just a convenience to move the spectator position, so that you can apply your relevancy/priority rules.