Cloudstrike 2.7.0: A Flexible Rendering Layer for New Platforms

Cloudstrike 2.7.0 focuses on an important technical foundation: separating the game logic from the engine. Ebitengine is not the problem. It allowed me to quickly build a complete game for Windows, Linux and Android. At the same time, I want Cloudstrike to remain flexible for new build targets and platforms. That is why I am introducing a small rendering interface through which the game emits neutral sprite, triangle and rectangle commands.

Ebitengine currently executes these commands. In the future, the same interface could also be used by a Raylib backend. This keeps the game logic stable while allowing me to evaluate different engines and platforms. The migration is happening incrementally. Terrain, particles, the player, enemies, shields, explosions and major boss elements already use the new boundary. The render queues have fixed capacities and remain allocation-free in critical gameplay paths.

My benchmarks currently show:

• Gameplay updates: 0 bytes and 0 allocations per operation
• Render-queue construction: 0 bytes and 0 allocations per operation
• Engine-specific costs measured separately
• Raylib testing can begin without rewriting the game logic

The goal is not to replace Ebitengine. The goal is flexibility. I want to test new platforms, compilers and rendering backends without rebuilding the game from scratch each time.

This incremental approach lets me measure technical decisions while preserving Cloudstrike’s visual identity.