u/Outside-Text-9273

Hi!
I am building a game engine in C++. The architectural style I am using is OOP with composition, also known as a "bag-style" ECS. The main difference from a classic ECS is that entities are not just IDs but rather own their components and can operate on them via Add, Remove, Get, and so on. The components themselves consist of data and behavior, and the systems are interested in specific entities that have specific components. For example, the Render system needs entities with Transform and Sprite components.

The current architecture is designed around the fact that this is C++ and there is no garbage collector. Additionally, it is not a good idea to destroy entities in the middle of the main loop. Because of this, I created an EntityManager that can create entities, mark entities for removal, flush pending entities, check if an entity is alive, and return a raw pointer to an entity so you can access it. The whole thing works because the manager uses EntityIds, meaning you cannot have dangling pointers. The manager also manages the entities' lifetimes so it always flushes them at the end of the frame.

For now everything is good, but after adding the BaseComponent and all the logic into the entity, I reached a point where adding or removing a component changes the entity's signature. A signature is a bitset where every index represents a different component, like Transform, Collider, or Sprite. If the bit is 0, the entity does not have it; if it is 1, it does. When this changes, every system needs to check the entity so it can add it if it now suits the criteria, remove it if it does not, or simply ignore it.

To achieve this, I either need something like a RegisterManager and make it a singleton, or I need to make every entity hold a pointer or reference to this RegisterManager, which feels wasteful. At the same time, singletons or making the pointer or reference static inside the entities are considered bad practices. I also want my components to have unique, recyclable IDs just like my entities. To do that, I need to make something like a ComponentFactory. When a component is destroyed, it should notify this factory to recycle the ID, which means the factory either has to be a singleton too or the entities will have to hold yet another extra pointer. One fix is to create an event bus to handle cases like this, but then again, either the event bus is a singleton or everything that uses it must hold a pointer or reference to it.

So my question is, is there a pattern or hierarchy I can follow to avoid this repetition of every entity holding a pointer to the same system, or should I just stop listening to the posts online that say singletons are bad because of multithreading and unit testing, and just make a few?

Thanks in advance!

Hi!
I'm not sure if this is the right place to ask this, but since I couldn't find a database java specific group, I’ll drop it here.
I know a fair bit of Java and I've started learning databases. I’ve done small projects for uni using Hibernate and Spring Boot, but never with just JDBC. I decided to build a small project using only JDBC and PostgreSQL so I can see how things work without all the annotations provided by Hibernate and other frameworks. When I was handling relations before, I just used annotations and never really thought about the implementation. Now that I'm doing it manually, I'm realizing I can either put the whole entity in the class or just the ID.

My first question is:
Should my DTOs and entities have private fields with no-args, all-args, and custom constructors (plus getters and setters), or is it better to just make them public?

The second question is:
When I define relations, should I use the actual entity objects or just the IDs of those entities?

If someone can explain the difference and which approach is better? I know Hibernate is an ORM and that can sometimes lead to the $O(n)$ (N+1) problem, so I want to understand the best way to handle this logic myself.

Hi! I am making an incremental game where the static data for my generators and upgrades is stored in JSON files like generators.json and upgrades.json.

My current flow is JSON -> TemplateLoader -> Template classes (GeneratorTemplate, UpgradeTemplate) which are mapped 1:1 to the JSON. I then have a TemplateRegistry that holds HashMaps of the IDs and the loaded data in memory. These HashMaps hold many different instances of things like generators with their unique static data.

I also have runtime classes called Generator or Upgrade that hold only runtime data, like an ID and a count, and I use a standard database pattern with entities, DTOs, DAOs, mappers, and repositories to store and load these runtime instances.

I was wondering if there is a proven or standard pattern for the static data side that defines exactly how to do it and how to make it scalable? I am looking for something as structured as the DB pattern because I am not sure if my naming is correct, and my registry class is already getting pretty beefy even though I am only on the demo of the game. Any advice would be appreciated!

Thanks in advance!