I built a compact, high-performance Entity Component System module that embeds FLECS directly into Godot as a statically linked native module to simplify console porting and keep simulations fast and predictable. An initial prototype that used Godot Resource / RefCounted objects caused severe heap pressure under bulk create/destroy (stress tests spiked memory above ~40 GB), so I rewrote the bridge as a Godot Server exposing opaque RID handles via a FlecsServer API. This allows designers and scripters to access entities and components from GDScript without creating thousands of Godot heap objects. I validated the system with a real-time MultiMesh demo (the “Bad Apple” animation rendered as a grid of cubes). The module is production-oriented, lowers runtime overhead, and is designed with console/static-link requirements in mind.

The core uses FLECS, statically linked into Godot; entity and component lifetime, memory layout, and hot-path logic live fully in native C++. Script-side access is provided through RID handles managed by a FlecsServer Godot Server, avoiding per-entity Object allocations. The earlier Resource-based reflection layer was discarded after profiling revealed delayed reclamation and catastrophic memory growth when rapidly creating or destroying large numbers of objects.

Rendering validation used a single **MultiMesh** driven by ECS-managed transforms to confirm efficient batched updates. An experimental per-instance frustum/occlusion culling system was tested, but per-frame GPU buffer uploads caused CPU–GPU sync stalls and frame-time spikes. Future improvements include GPU-driven culling via compute shaders and indirect draws, asynchronous or double-buffered instance uploads through the RenderingServer, and editor-friendly serialization that avoids reintroducing per-entity Godot objects. Longer-term plans involve moving native simulation to worker threads while keeping Godot API access on the main thread.

In interviews I focus on the memory-debugging investigation, the trade-offs between RID and Object ergonomics, and approaches to eliminate remaining rendering bottlenecks.

Update — Expanding the Flex Module

I’ve recently expanded the Flex module with a more complete feature set. The main focus was on introducing Flex Queries and Flex Systems, separating them from the original Flex Script System to give the runtime a cleaner and more modular structure. This makes it easier to define and manage systems without mixing in script logic, and it sets a stronger foundation for future tools and extensions.

This update was mostly about rounding off the API — polishing what was there, validating how it all fits together, and making sure the module feels cohesive and ready for production use. It’s now in a place where I can confidently start building the editor toolset on top of it.

Once that’s done, I’ll move on to rebuilding my earlier Procedural City Generator demo using the new system. The idea is to push it further and show how these new features can drive larger, more complex simulations while keeping everything flexible and performant.

Source Code