An important point to understand is that actors are only replicated from the server to the clients - it's not possible to have an actor replicate from a client to the server. An actor with its "Replicates" flag set to true will automatically be synchronized from the server to clients who are connected to that server. The core of the networking technology in UE4 is actor replication. The Pawn's health, therefore, would be stored on the Pawn itself, since that is specific to the actual instance of the Pawn and should be reset when the Pawn is replaced with a new one. For example, if a Pawn dies during gameplay, it will usually be destroyed and replaced with a new Pawn, while the PlayerController and PlayerState will continue to exist and will be associated with the new Pawn once it finishes spawning. The decision of whether to use the PlayerController, the PlayerState, or the Pawn for a certain variable or event will depend on the situation, but the main thing to keep in mind is that the PlayerController and PlayerState will persist as long as the owning player stays connected to the game and the game doesn't load a new level, whereas a Pawn may not. Pawns (including Characters) will also exist on the server and on all clients, and can contain replicated variables and events. Like the PlayerController, they are associated with individual Pawns, and are not destroyed and respawned when the Pawn is. This class can be used for replicated properties that all clients, not just the owning client, are interested in, such as the individual player's current score in a free-for-all game. 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)
