python-tcod-ec VS python-tcod-engine-2023

I've also added a new class called Composite to tcod-ec which allows for multiple components per class and looking up components by a base class. While this is more flexible than ComponentDict I feel that the extra complexity detracts from its usefulness greatly and the new container quickly leads into anti-patterns in my attempts to use it. I struggle to make examples for Composite which couldn't be better expressed in other ways. So far it feels like the restrictions of ComponentDict are a feature rather than a flaw.

For my own project I've been skipping the entity repository and systems and implementing only entity/component frameworks for practice and since I might not need systems most of the time (although there are big downsides for entities and components not being in a repository). My own project can be found here.

I don't have ECS yet, I've tried the current Python libraries but didn't like their typing support, so right now I'm experimenting with basic EC frameworks. I have a decent example right now, and it should be clear how this is better than the Python tutorials implementation.

This month I wanted to work on a new Python tutorial, but I'm having trouble getting parts of my test engine to work cleanly (right now involving interactions with how actions poll their inputs from the UI). I might have to settle for making another "bad" tutorial and then fix architectural issues later.

I have repurposed a recently failed game jam project into my next Python libtcod engine. The source is here. This will be the 2023 Python engine. I plan on working on this over the month and then using it for the upcoming 7DRL. I intend to implement the tutorial features in a simpler and less intrusive way than before so that the engine is easier to extend with new features.