Would anyone be up for doing some form of code review?

I feel like I'm at a decent place in my game engine. This would be a good time to do some cleanup and review before moving on to the next engine features. I've already gone through a round of cleanup and documentation comments to make things easier to follow.

Game : Dungeon Crawler World Inspired by Dungeon Crawler Carl. So far it's just the game engine with nothing to differentiate it in terms of style or content. But architecture decisions are often influenced by necessary content for that series (ex: multiple races and classes)

Tech Stack : C# + XnaFramework using VSCode I'm keeping my framework and libraries as minimal as possible to force myself to build systems that I would previously use libraries for.

Repo : https://github.com/Kavrae/DungeonCrawlerWorld

Focus : Runtime efficiency and minimizing memory footprint. Future content like Brindlegrubs and the Over City will require the game engine to be as efficient as possible to handle tends of thousands of simultaneously active entities. If it requires overhauling a large portion of the game to deal with a bottleneck, so be it.

Architecture : Custom ECS with managers, services, and windows Entities are nothing more than an integer ID that's incremented and managed by the Components/ComponentRepo. Explanation behind it being an integer and how it's used are in that class. But the short version is to use it as an array index for dense component arrays without casting. If an entity has no components, it doesn't exist.

Components are strictly data structs. Trying to keep each to as small of a footprint as possible. Naturally DisplayTextComponent is going to be problematic, but the rest are relatively small. Components are split into dense arrays and sparse dictionaries indexed and keyed by the entityId respectively.

Systems perform individual pieces of game logic and I have few examples created. Systems can operate on multiple components rather than some ECS systems that bind them to one component. They run on individual frame rotations with offset frame starts to avoid performance spikes. HealthSystem is a good example of how I want most systems to operate, with MovementComponent being at the extreme end of complexity.

Managers handle core game logic outside of individual systems. ComponentSystemManager handles the update order of systems and keeps them running on offset frames. I need to do dynamic startup loading of systems instead of hard coding them. UserInterfaceManager is the largest by far. It contains the root windows, captures user input, and passes it to the relevant windows. Eventually I'll split it off into a UserInputManager when user input is more than clicking and scrolling. NotificationManager is a work in progress to manage popup notifications of various types that are important to the game. MapBuilder is a stub manager that currently only builds a testing map. EntityFactoryManager is a work in progress to build entities based on Templates. Where templates are a preset combination of components and modified properties. EventManger hasn't been started yet.

Services handle cross-domain features like managing game settings, fonts, and spriteBatches.

Map is effectively an in-memory 3 dimensional array of mapNodes. Each mapNode can contain a single entity, but entities can span multiple mapNodes.

Windows are the primary data structure and behavior for UI elements. This is where most of my recent work has been. Notifications, map window, textboxes, etc all derive from Window.

Next Feature : Buttons and overridable button events.