1.8 KiB
C++ gameplay
In the first version of Faset, a "script" is C++ gameplay code compiled into your game. It is not an interpreted text file. The gameplay library is statically linked into a separate Player executable.
The intended iteration cycle is:
- Stop Play.
- Edit your C++ behavior or system.
- Build the changed code and export its property schema.
- Start a new Player session.
The Editor reads a schema generated by a separate SchemaExporter. It does not load your gameplay library into its own process. A gameplay crash therefore does not automatically crash the Editor. Editor native extensions have a different lifecycle and run inside the Editor process.
!!! note "API examples are added with implementation" This page describes the accepted execution model. Exact function signatures and complete examples will be documented alongside compiling runtime examples, rather than presenting proposed APIs as available functions.
Behaviors and systems
A behavior gives an individual object lifecycle callbacks. A system operates on a set of objects with matching components. Both use the same runtime state; the visual scene and Inspector are the authoring view of that state.
Persistent scene IDs and runtime handles are different. A scene ID survives saving and reopening. A runtime handle belongs to a particular world/session and can become invalid after an object is removed. Do not store raw component pointers across structural changes or treat a runtime handle as a save-file ID.
Physics ownership
Physics owns the position of a dynamic rigid body. Move it with the supported physics commands instead of writing its presentation transform. A camera or other visual-only object can follow the interpolated result without modifying the simulation.
Continue with Frame and physics updates.