42 lines
1.8 KiB
Markdown
42 lines
1.8 KiB
Markdown
# 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:
|
|
|
|
1. Stop Play.
|
|
2. Edit your C++ behavior or system.
|
|
3. Build the changed code and export its property schema.
|
|
4. 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](lifecycle.md).
|