An unorthodox entry.

Having "factory" classes and that sort of thing isn't very Pythonic. The docstrings are nice but it could do with a few more comments.

I might use this some time and return better feedback, that's just what stood out from skimming the code.

I might

ECS in a dynamic language like Python tends to involve a redundant approach to architecture. You can already access the raw fields and check for existence. The only thing you need on top of that is something to maintain a global indexing of same-type fields. And then once you pursue that road further, and try to add more integrity constraints, you drift towards implementing a relational database, or at least some subset of one. If you want a game engine that is maximally data-driven, try writing all data in BCNF form. (You can spend well over a week thinking about how to implement a clickable GUI button, doing this.)

If you want to continue focusing on architecture from a performance angle I recommend thinking about how your system will treat memory allocation as that is the main thing separating "great" entity systems from "good enough" ones; zero runtime allocation is a good goal. If the entity system ends up being worse than just hand-rolling allocation strategies for each piece of data in the game, it loses by default.

Bottom line, though: you will get more done in gamedev, especially in game-jam scenarios, by writing a single large main loop that does everything in a semi-customized fashion. It is inelegant and CS Professors Hate It, but it has the result of making the code more like an art asset - fluid, easy to change, easy to toggle or cut bits out, or make one-off variations.

Thanks for the feedback guys!

@xgeovanni - I'll be adding more examples in the near future. Factory is really for fast/simple generation of a component. My first example avoids the use of the factory and uses the Component class a more traditional sense.

@triplefox - My goal was to make the interface easy to understand and use for rapid development. But I appreciate the constraints and considerations you've mentioned.

Seems like a start to a potentially useful project, but ATM it doesn't do enough to be worth the overhead.

Next steps seem to be things like adding a serialization engine, visual editor, asset importer, graphics pipeline and all the various parts necessary to support the "drawing system".

Python totally needs better game engines!

Hmm, not sure how to rate this. What an unusual entry :P
I don't use Python for gamedev but I can see this being quite useful, you should work on it and release for the community to use in the next LD. Good job!

I rated this fairly high since as a programmer I really enjoy looking at different architectures

Like others have said, what an unorthodox entry. I kinda dig it.

Looks pretty JAVA-ish, but it's okay, carry on :D

Thats actually a nice little library. For a game jam having a prebuilt ECS would be really nice, esp. in Python. The problem with languages like Python is they put you into patterns that don't work all that well for Gamedev. In a gamejam scenario almost any reasonable sacrifice in performance is acceptable as long as it makes development faster.