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 has become the backbone of our sample projects and is already shaping how we think about future systems like UI, 3D tooling, and editor automation.

We still have work to do here. The component model is strong in 2D today, and we are actively carrying the same patterns into UI and 3D so the engine feels coherent instead of becoming two different products bolted together. But the core direction is settled: small game objects, explicit components, and behaviours that stay readable.