Building the Component System: GameObjects, Components, and Behaviours
Lenga's component model is built around a simple idea: keep scene objects small, let focused components do one job well, and use PHP `Behaviour` scripts for gameplay glue. That is a much better fit for the kind of editor-driven workflow we want than a deep inheritance tree full of special-case object types.
At the C++ runtime layer, a GameObject owns a Transform and a list of components such as SpriteRenderer, Rigidbody2D, BoxCollider2D, Camera, AudioSource, or SpriteAnimation. In PHP, a gameplay script extends Behaviour and talks to those components through familiar methods like getComponent(...), fixedUpdate(), and lateUpdate(). That split is deliberate. Rendering, physics, and scene serialization stay native. Iteration-heavy gameplay logic stays in PHP where designers and scripters can move quickly.
What matters most is that the authored workflow stays predictable. Add a component in the Inspector, tune its public properties, then attach a Behaviour script for custom rules. Public script properties are serialized into the scene and exposed back in the Inspector, so the same script can be reused across many objects without hardcoding values.
That workflow is the backbone of the sample projects and of the way Lenga organizes scene logic: small game objects, explicit components, and behaviours that stay readable. The same model keeps the editor, serialization, and gameplay scripts aligned around one clear mental model instead of fragmenting into separate authoring systems.