Version:

Icon of a magnifying glass.

Multiplayer Sample Network Features

Multiplayer Sample Network Features

The Multiplayer sample offers the following features.

  • Dedicated Server Split \(Partial\) – Because the clients can also host game sessions for LAN play, a true split is never done even when the client has no server code. However, the code itself is compartmentalized in such a way that the split can be done easily. A dedicated server split is used in the following component:

    • GameManagerComponent – Designed to be available only on the server. It relies on the GameModeBus to synchronize the state to display \(for example, whether the game is ready to start a round, or whether the current round is complete\). For details, see the source code files in the \dev\Code\MultiplayerSample\Modules\MultiplayerSampleModule\Source\Components\GameLogic directory.

  • Client Authoritative Control – Enables the client to maintain exclusive control of an object whose actions are processed on the server. Client authoritative control is used in the following components:

    • ShipComponent – Client commands that control a ship trigger a series of RPCs that the ShipComponent exposes. The RPCs are then processed on the server. The commands are restricted to the owner of the object. For details, see the source code files in the \dev\Code\MultiplayerSample\Modules\MultiplayerSampleModule\Source\Components\Ship directory.
    • ManualPlayerControllerComponent – Represents the human-controllable player. For details, see the source code files in the \dev\Code\MultiplayerSample\Modules\MultiplayerSampleModule\Source\Components\ShipController directory.
    • BaseAutomatedPlayerControllerComponent – Represents an AI-controllable player. It maps computer-generated input to the RPC calls. For details, see the source code files in the \dev\Code\MultiplayerSample\Modules\MultiplayerSampleModule\Source\Components\ShipController directory.

  • Encryption – Encryption is performed using FileDataSource with self-signed certificates and certificate pinning. The files expected are a set of X.509 PEM files, which are split into a nonpassword-protected key \(`multiplayersample.key.pem`\) and a cert file \(`multiplayer.cert.pem`\). These are located in the MultiplayerSample\certificates directory. If either of these files is missing, a set of certificates is generated using RSA2048 and some default answers that can be customized from the wscript file. For more information, see How To Generate a Private Key and Public Certificate. For important information about self-signed certificates in the Multiplayer sample, see About Self-Signed Certificates in the Multiplayer Sample. In the Multiplayer sample, encryption is used in the following features:

    • GameManager – Exposes a function called SetupEncryption, which handles the configuration of certificates for the game. For details, see the source code files in the \dev\Code\MultiplayerSample\Game\Game directory.
    • MultiplayerUtils \(in Multiplayer Gem\) – Has utility functions that handle configuration of the carrier description for hosting and joining. The code shows how to configure the SecureSocketDriver and use an EBus event to signal its use for the connection. For details, see the source code files in the \dev\Gems\Multiplayer\Code\Include\Multiplayer directory.

  • RPC Traits – In Lumberyard, RPCs allow games to send events or requests to remote nodes through GridMate replicas that synchronize the state of the session. In the Multiplayer sample, RPC traits are used to control ships, manage the HUD state, and manage audio controllers. To see how they are attached to RPCs, see the source code files in the following locations.

\[See the AWS documentation website for more details\]

  • Custom Component Net Binding – For a Lumberyard component to share data on the network, it must include the NetBindingComponent. A number of Multiplayer sample components demonstrate custom component net binding.
    • CoreGameHUDController – An illustrative example that has datasets, RPCs, RPC traits, and callbacks. For details, see the source code files in the \dev\Code\MultiplayerSample\Modules\MultiplayerSampleModule\Source\Components\GameLogic directory.
  • Custom Type Marshalling – In GridMate, all data marshalling, whether for a dataset or an RPC, is written using a specialized Marshaler type. If the type is a complex type like a class or container, then that marshaler marshals each of its fields with nested marshalers. Custom marshalers can be implemented to support custom types. Custom type marshalling is used in the following component:
    • ScoreAttackGameModeComponent – The PlayerRoundInfo struct demonstrates the simplest way of defining a custom marshaler for a custom type without needing to specifically override it in the dataset definition. For details, see the source code files in the \dev\Code\MultiplayerSample\Modules\MultiplayerSampleModule\Source\Components\GameLogic directory.