If you have to ask... then no. Hard no.
This is a personal project with no virtually no developer support. Maybe in a few years it'll be production ready. Probably not.
Use the core ItemsHoldr. Modules should generally only keep caches for their internal members, and sections should not have any game state.
Or: doesn't forcing sections to inherit classes violate SOLID principles?
Arguably no. From one perspective, enforcing a rigid inheritance hierarchy here actually helps enforce the Open-Closed Principle. EightBittr sections are managed in a framework that sets up their dependencies and lifecycle. Classes in the EightBittr structure have defined purposes and, while they may be extended within their purposes, should not be drastically altered.
Quite a lot!
- Each package should have a fleshed out README.md, including usage examples.
- #227: Bring LevelEditr in as a first-class package.
- #228: Bring SpriteMakr in as a first-class package.
- #51: Fill in unit testing gaps for all packages.
- #194: Add rudimentary test coverage metrics.
- #190: Move relevant portions of Actors into members (e.g.
.box
for physics settings), so that modules can compose rather than inherit.