In Netcode, observation is access control as well as bandwidth saving. The Any Server never sends a Client data the Client may not hold.
Pieces #
| Piece | Purpose |
|---|---|
| Aspect | A named share of a NetRecord’s fields, declared in the Schema. Clients are granted or denied aspects. |
| Role | A label that connections can be bound to, per record. |
| Provider | Computes what a connection may hold. Providers include Tagged, Occlusion, distance and group. |
| Condition | A test against facts you set from game code. |
| Rule | Ties roles, providers and conditions to aspects. |
| Observation level | How much of a record a Client holds. |
These live in an Access Profile, a .netaccess file edited on the Access page of the Netcode tool, which tells you at every change whether it still fits the Schema.
From script #
NetcodeAccessRequestBus provides LoadAccessProfile, Bind and Unbind, EnableProvider, SetFact, TestCondition, GrantAspects and RevokeAspects, and metrics for the session, connections and types.
A worked example #
The Arena sample uses an Occlusion provider and a Tagged provider with the aspects Observed and Radar, so a Client is never sent a player a wall hides. See Samples. Box colliders used by an Occlusion provider need real dimensions, because non uniform entity scale is ignored by the physics shape at run time.