koobas.hobune.stream
Networking pattern for team-based play
I'm developing a multi-player team-based game and would like some recommendations on a networking code pattern. Players should be able to select a game they want to play (I think I'll use the existing Master Server architecture for this). And then a player should be able to create a team or join a team. Once apart of a team, they should only view updates and information about the game from other players on their team. The objects they see and interact with should only affect the other players on their team - not any other team. Some objects in the system may look very different across teams. And some objects may only exist in one team's view.
Some events - like the current time and major scenario events will be seen across teams.
My question is what patterns should be used to isolate information between teams? Multiple network Views? I saw that the networkView class has a SetScope method, so I could potentially remove players from receiving updates on a networkView? I'm a little new so I don't really understand network views. Are they client side? server side? Can you have a network view that controls many objects?
For the creating and joining a team, I was thinking the client could execute an RPC call to the server.
Actually this question can't really be answered, so i was about to close it. This site is for concrete and specific development questions. "Avoid asking questions here that are subjective, argumentative, or require extended discussion."
However, i try to explain a bit how the networking system works.
First of all each player or peer (no matter if it's a client or the server) has it's own world and it's own set of objects. In the first place they have nothing to do with another object on a different PC. The NetworkView is the component which handles synchronisation across the network. It is linked with a NetworkViewID. A NetworkViewID is owned by the player that created the ID. When you call Network.Instantiate on a prefab that has a NetworkView, the player that calls this function will own the object across the network. Only the owner is allowed to send state updates. Every other peer just receives those updates.
Independent from the automatic state synchronisation there are RPCs. RPCs can be send both ways.
SetScope can be used to divide data into groups, but usually you use just RPCs. Generally stats synchronisation is used for things that should be updated very often (position / rotation / speed of the players), RPCs are ment for one-time-events but you can of course send them more often. Stats synchronisation is more optimised to reduce the required bandwidth, but it's up to you how you use them.
You have to decide what general network layout you want to use. When each player creates his own player object, he's automatically the owner and he can change everything related to his player object. The server just acts as kind of proxy to distribute the informations. An alternative is to let the server own all objects and clients can send RPCs to tell the server what they want to do with their player. This (authoritative) server has more control over what a client is allowed to do. This is the usual setup for most FPS games (quake, unreal, CS). However it usually requires a bit more work, but it depends on the type of game, max and average player count and how many objects have to be synched.
