Closed AMZN-puvvadar closed 1 year ago
Can we highlight the delta from the old RFC? Lets provide some context as to whats new and whats from the old RFC, to help guide reviewers.
Can we highlight the delta from the old RFC? Lets provide some context as to whats new and whats from the old RFC, to help guide reviewers.
I've added a delta section at the top of the document. Thanks for the suggestion.
Accepted in SIG-Network triage on 10/20. Approved by @AMZN-Olex @lmbr-pip
@lmbr-pip to archive.
This proposes an updated version of an accepted RFC:
What is the delta produced by this Amendment?
Feature Design Description
The amendment proposes moving from a Client and Server target with a CMake target to allow Client to include Server to a Client, Server and Unified target. This is largely what was described as the alternative solution in the original RFC. The prior solution is now listed as the alternative.
Technical Design Description
Example CMake was updated for accuracy and updated Feature Design Description.
Macros
Added further details on macro usage and expected user interactions.
Open Questions
Added a question around AutoGen usage in CMake for modules using Client/Server split
RFC Feature: Client and server build target separation
Summary:
For some O3DE applications, like multiplayer and live service games, server code cannot be shipped to the clients. Doing so creates incremental security and cheating risks. Servers that include client code and resources can also bring unnecessary dependencies which causes long build and relocation times. That being said, customers may also require a unified build containing client and server logic. This RFC proposes a hard client and server split by separating the client and server into different build targets when required while maintaining the option of a unified build for customers that require it.
What is the relevance of this feature?
With the solution proposed by this RFC, O3DE will support the following two hosting modes for multiplayer applications:
Feature design description:
This solution proposes adding two compiler definitions to allow the separation of client and server behaviors:
AZ_TRAIT_SERVER_ENABLED
: Compile the server code for the current target.AZ_TRAIT_CLIENT_ENABLED
: Compile the client code for the current target.O3DE developers can use these compiler definitions to separate the client and server targets, so that they can create a dedicated server for live service games, a client with no server logic or a client hosted server for console titles. These will be referred to as a Server build, Client build and Unified build going forward.
Technical design description:
CMake definitions
For any multiplayer O3DE project, as well as any dependent gems that contain multiplayer components, define separate static libraries for the Client, Server and Unified targets like below:
All the downstream targets should always refer to one of the Client, Server or Unified static libraries.
Multiplayer gameplay components will live in both of the client and server targets to keep a simple cook and replication pipeline. Their behavior and accessors will be different because of the compile definitions and macros.
If O3DE developers only need the client hosted solution and don’t want to generate a server launcher, they can just remove the following lines in the CMake configuration:
Macros
Macros would be enforced at the auto-generated component level. We should be adding additional
#if AZ_TRAIT_SERVER_ENABLED
and#if AZ_TRAIT_CLIENT_ENABLED
markup around authority, server, autonomous, client properties and remote procedure calls (RPC), which will force derived components to respect those same defines.Auto-generation provides a variety of logic overall. Some of this logic is declared and defined purely in AutoGen. Some however, is declared in AutoGen and defined by the user. RPC Handlers are an excellent example of this. In these cases, the declaration itself will be macro wrapped which will require users to macro wrap their definitions.
How to handle logic the user declares and defines that can be separated using Client/Server macros is left to the user's discretion.
What are the advantages of the feature?
What are the disadvantages of the feature?
How will this be implemented or integrated into the O3DE environment?
Are there any alternatives to this feature?
Using an extra CMake flag, remove the Unified solution and instead allow the Client configuration to function as the Client launcher or the Unified launcher based on said flag.
Project/Gem CMake configuration will look like below:
This solution has the same advantages as the proposed solution. Disadvantages include:
How will users learn this feature?
Are there any open questions?