Not much honestly.
I made 4 prototypes on tiny-ecs until build the “add-content” flow (you all know that I’m about 
). Tested different approaches with various things like saving, network, level design, UI, available tools, how iterate over balance and levels. And looking how in general the development flow is going with that. It’s pretty fun way to understand tech by trying it in various cases!
Hard to compare about convenient, cause all have different development flow. It was pretty hard to me start thinking in fully data driven component way, like on this shooting circles. But what it seems to me (from code side):
- Most systems will be equal between your projects
- Annotations for Lua works good in this way
- For most feature/task for your project you will have only one way to start doing this. Feels like low friction before start implementing anything in the game. About one way I mean it can be even “step by step” flow to add instruction to yourself or your team members.
- System’s code are pretty easy to understand and debug due it’s mostly standalone file logic.
- More debug tools will be required as you grow. To see kind of chain of events, different collisions and leaks.
- Saving process was different in my case. I had like “save_transform” or “save_field_state” components and each corresponding system save/load this component separately (they was linked by tiled_id field from level editor)
- With Tiled the content design are linked with code development. I usually place data as I wish to design in this game and going to write systems to make this level work. From some time it feels like “game first” and not “code first” way to do game.
Also it’s hard to stay in this ECS rules. And probably not required and each should modify them. And sure use this as a tool in your toolset for games.