They are well-suited to communicating information between clients and servers without replicating this information to other clients, such as the server telling the client to ping its minimap in response to a game event that only that player detects.Ī PlayerState will exist for every player connected to the game on both the server and the clients. PlayerControllers exist while the client is connected, and are associated with Pawns, but are not destroyed and respawned like Pawns often are.
These are replicated between the server and the associated client, but are not replicated to other clients, resulting in the server having PlayerControllers for every player, but local clients having only the PlayerControllers for their local players. One PlayerController exists on each client per player on that machine. As an example, a baseball game could replicate each team's score and the current inning via the GameState. Information that is of interest to all players and spectators, but isn't associated with any one specific player, is ideal for GameState replication. The GameState exists on the server and the clients, so the server can use replicated variables on the GameState to keep all clients up-to-date on data about the game. For example, if a game has special rules like "rocket launchers only", the clients may not need to know this rule, but when randomly spawning weapons around the map, the server needs to know to pick only from the "rocket launcher" category. It generally stores information related to the game that clients do not need to know explicitly. The GameMode object only exists on the server. locked/unlocked status of special items), or even a list of maps to rotate through in a competitive game like Unreal Tournament. total number of games won), account information (e.g. Because the GameInstance exists outside of the game session and is the only game structure that exists across level loads, it is a good place to store certain types of persistent data, such as lifetime player statistics (e.g. A separate GameInstance exists on the server and on each client, and these instances do not communicate with each other. The GameInstance exists for the duration of the engine's session, meaning that it is created when the engine starts up and not destroyed or replaced until the engine shuts down.
See the Gameplay Framework documentation for more information - but at least keep in mind the following tips when designing your game for multiplayer are: Pawn (and Character, which inherits from Pawn) To add multiplayer functionality to your game, it's important to understand the roles of the major gameplay classes that are provided by the engine and how they work together - and especially, how they work in a multiplayer context: Most of the logic to make basic multiplayer work is thanks to the built-in networking support in the Character class, and its CharacterMovementComponent, which the Third Person template project uses. It's easy to dive in and start playing mutliplayer.
Unreal Engine 4 provides a lot of multiplayer functionality out of the box, and it's easy set up a basic Blueprint game that works over a network.
0 kommentar(er)
