Components
Components are special structs that can be attached to entities, and used for filtering them (iterating only a subset of the active entities based on its attached components).
They are useful to pass in values for initialisation. A basic example definition of a component:
DSL
Domain specific language. In the context of Quantum, this refers to files that are written in Quantum's DSL, or .qtn files. The Quantum compiler will parse them into an AST (Abstract Syntax Tree), and generate partial C# struct definitions for each type (definitions can be split across as many files if needed, the compiler will merge them accordingly).
The goal of the DSL is to abstract away from the developer the complex memory alignment requirements imposed by Quantum's ECS (Entity Component System) sparse set memory model, required to support the deterministic predict/rollback approach to simulation.
This code generation approach also eliminates the need to write "boiler-plate" code for type serialization (used for snapshots, game saves, killcam replays), checksumming and other functions, like printing/dumping frame data for debugging purposes.
ECS
Stands for Entity Component System.
Entities
In Quantum all synced objects are Entities. Gameplay is driven by entities, Entity Views are synced across the network, and statis Entities are baked into a map which is also shared and used to interact with the non-static Entity Views. The Quantum simulation code does not handle any rendering (this is done by Unity), however the EntityViewUpdater instantiates a GameObject for each entity that has an EntityPrototype with an EntityView MonoBehaviour on it in Unity. This view GameObject acts as the visual representation of the entity. The transform of the view GameObjects are also automatically synchronized from their respective entities by the EntityViewUpdater.
Each entity has a set of components. Components are not Unity MonoBehaviours and are added to the entity on the EntityPrototype MonoBehaviours's Entity Component list or via code. Some components are added by checking the checkboxes in the Entity Prototype component such as the PhysicsBody2D component on the cube entity.
Filters
The most common pattern in Quantum ECS is to have a system iterate over a collection of entities which contain a set of components. With the Quantum ECS this can be achieved using a system main thread filter. Each filter must always contain an EntityRef field and any number of component pointer fields to filter for. Always use pointers for the component types in the filter.
FP
FP stands for Fixed Point and can be seen as an alternative to Unity's float type. FP data types ensure that Quantums simulation is deterministic.
Namespace
A namespace helps organise code, specifically in large projects. The namespace is optional, and another name can be used. When not using the Quantum namespace add using Quantum; to the top. In Quantum however it is important to use namespaces as the SystemsConfig object uses these to help find systems to run in the simulation.
Preserve
The [Preserve] attribute needs to be added to all Quantum systems to ensure that Unity does include them in the build and ignore them when running code stripping.
Queries
Physics queries check for dynamic entities and static colliders. They basically detect if anything is in range of the parameters set. Queries can be used much like raycasts, or check for objects with in a sphere.
For more information, visit the documentation
The below shows a physics query for a raycast, or checking for objects within a line of an origin and a destination vector.
The below shows a physics query for a shape, in this case a sphere:
Systems
Systems contain physics and simulation code and are normally attached to an Entity. Systems by default will not run, unless they explicitly added to the Entries list on the SystemsConfig object.
Unsafe
The unsafe keyword allows for use of unsafe code such as pointers in the system. Example:
