A short vocabulary used on every other page. We use these terms strictly, because networking documentation becomes confusing when “server” means three different things.

Roles #

Term	Meaning
Dedicated Server	A process that hosts the session and has no local player.
Listen Server	A process that hosts the session and also plays. Its own player is a local connection with no wire.
Any Server	Either of the above. Anything the documentation says the Any Server does applies to both.
Client	A process connected to an Any Server.
Standalone	A single process with no networking, still using the same data model.

Netcode terms #

Term	Meaning
Schema	The data description of your network model: the types, fields, messages and sync settings. It is a JSON file with the extension .netschema, edited in the Netcode tool.
NetRecord	One replicated row of data of a Schema type. It is not an AZ::Entity. A game object is bound to a NetRecord by a component.
Aspect	A named share of a NetRecord’s fields. Access control grants and revokes aspects.
Transport	The pluggable layer that moves bytes between processes and owns delivery behaviour.
Access Profile	A .netaccess file describing roles, providers, conditions and rules for who may hold what.
Subsystem	The part of the gem that owns the NetRecord store and drives sessions each tick. In the Editor it is called the Netcode Subsystem.

Why there is no serialisation #

The subsystem keeps your network data in its own memory in a packed layout the Schema defines. A packet is a header followed by raw bytes of that store, and the receiver copies them to the same offsets. This is the same data oriented thinking as our DataLens, without sharing any code with it. The layout rules are a documented contract, pinned by a test.

How a tick works #

The subsystem receives and applies incoming data at the start of the engine tick and sends at the end of it. The network tick rate defaults to 60 Hz, and each group of fields is sent at the rate its sync stage specifies.

Next: The Data Model.