Tech stack - ECS and languages

I love how structuring programs works in ECS, and I think it's an overall better design pattern to the others (Actors based - Godot, Unreal; and Components based - Unity), and would love to see a fully designed engine around it in the future. Bevy and the SEO-and-surveillance-state unfriendly Murder engine are promising in that direction. A lot of talks around ECS focus on performance, maybe due to years of Unity marketing, but when an ECS API is pleasant to use (sorry Unity...) the main advantage is also having more modular and easy to write code, and if there is a performance boost, it's just a nice bonus.

Bevy

I've used Bevy in some of my other projects. It's shaping up to be a great engine and has made good progress in the last years. It still has some quirks that are being worked on and are solvable. And with an editor it could become a major player in the engine scene. Unfortunately compile times are long and CPU heavy. I probably could have fried an omlette on my laptop while I was iterating on my bevy jam game. I love Rust (rewrite it in Rust is a very valid strategy, besides a meme) but I don't think it's a good language for experimentation heavy projects like video games because it forces you to upfront handle situations that you just don't care about while prototyping. It might be good for engine programming once the ecosystem matures a bit, but it is inherently a lesser choice for gameplay code.

Flecs

For my survivors project I've used Flecs through the Flecs.Net bindings, which is just amazing. The documentation and examples are great. It's extremely flexible, but at the same time the simple use cases are very straightforward. It has weaker typing than Bevy, so in some weird, rare cases you might end up passing the wrong things and have them break at runtime. Using it inside C# comes with some big caveats though: error messages are often cryptic and it's hard to pinpoint the problem. I had to comment out most of my code in two cases to find out just where an issue was happening. The stack traces between managed and native code are very hard to debug. This would probably not be an issue if using it in the same language as the library. The implementation also leaks details, unlike bevy, for example by having you iterate over archetype chunks explicitly, which is not a big deal, but an important thing to understand. The simple foreach entity callback examples you see in ECS quickstarts are cute, but they're not the best choice in like 50% of use cases, so the manual iterator syntax is very important.

I've also had trouble compiling both Flecs and Raylib in the same project to wasm. I can compile them separately with different configurations but doing them both and testing the whole project is an ongoing task for my survivors project. I want to avoid this here by setting up wasm early and testing regularly using CI. This also spares me the boiling laptop problem since I locally only compile the managed code, which is blazingly fast and easily supports hotswapping.

Pure C# ECS

For this project I want to test a pure C# library for ECS to avoid the issues with compiled languages above. In a real project, moddability is also a major thing to consider. The reason why Minecraft (Java), RimWorld and Kerbal Space Program are major successes is in no small part due to mod support.  Having most of the game code written in C# enables the kind of extreme moddability where you can swap out the underlying physics of the game (!!!) or turn it into an entirely different genre. That would be much harder to achieve if these game were compiled in native code or had just a thin scripting layer on top (which also causes maintenance headaches).

The main contenders were Friflo.Engine.ECS and Arch, and partly Entitas. Arch seems to be more battle tested in projects like SS14, but the API doesn't seem that great. It uses some weird unsafe wrappers for the full iteration. I still want to try it at some point, but the Friflo API seems to be cleaner and closer to that of Flecs, which I like. It also exposes a way to abstract over different chunks (which is understandably slower). Friflo is definitely newer and not as battle tested as Arch so we'll see how that goes. I also liked that it has an example ported to web, so it gave me some confidence that it can run that way.