from reading the description

you basically need to put the code in the class it belongs

not make a code noodle soup

What about the " all-knowing object" description?

The "Game" class has access to every part of the program through it's members.

well it's just an object that references others

nothing special really

if you need to access the objects you can ask the god class I guess

1st, it's a very, very good idea to learn about this.
2nd: in game design, performance is god and many good enterprise design practices are sacrificed at the altar of performance, possibly including "never use god objects".

A "god class" is a class that knows too much; it knows that Processors need to update Entities, but some Entities have to talk to a Processor and check for collisions with non-entity objects in this Scene but not that Scene, and that UpdateSystem needs to run part 1 before part 2 and EntityManager can only have 4 objects at a time because... WHOA WHOA WHOA, this is supposed to be a high-level class, we are way too deep into the weeds, there are too many levels of abstraction are mixed together... this class is trying to do everything. If you want to add a new Entity you may need to update 40 lines of code scattered throughout the god class to make it work.

A SOLID class is only responsible for exactly one thing; if you want to add an Entity, you define the new behaviors in one 40 line chunk, then update maybe one or two lines in directly adjacent classes, to call the new behavior.

Of the two example diagrams, the 2nd is much more likely to be a god class than the 1st

Now that I think about it, I made every member in my composition public, only now I see how much nested access it has.

I think only tried to limit child -> parent access, but not the other way around.

and didn't even succeed at that lol

child -> parent and parent -> child can be ok... the problem becomes more obvious when you have parent->child->grandchild->greatgrandchild->...

I see

if greatgrandchild needs a change, you don't want to have to modify all 3 other classes

I feel like I get confused sometimes with names when talking about composition of objects. Are you refering to inheritance here?

Layers of abstraction

Program (yep, I'm running it on a computer) -> Game (needs to know how to be a game) -> Scene (particular collection of behaviors; here's how the update loop runs in the "pause menu" scene or whatever) -> EntityManager -> Entities (perhaps including the "save & quit" button)... Program should never ever need to know the damnedest thing about a save and quit button, frankly neither should Game or probably even Scene

I understand. What do you think about a situation when the "save & quit" button has access to other intermediate objects like for example Entity creator, or a list of sound files that can be played?

Those requirements should be gathered elsewhere and handed to the button, the button itself shouldn't know the details of how they were assembled.

class SaveAndQuitButton : Entity
{
    var _listOfSoundFiles;
    public SaveAndQuitButton(List<SoundFiles> injected){
        _listOfSoundFiles = injected;
    }
}

, not

class SaveAndQuitButton : Entity
{
    var _listOfSoundFiles;
    public SaveAndQuitButton(TightlyCoupledParent p){
        _listOfSoundFiles = p.SoundFilesListCreator.Create();
    }
}

I see, thanks, that's very helpful.

This is called dependency injection, there are other approaches that operate on the same principle (like, passing in a kinda godlike "dependancy manager" object) but that's the simplest I think

In terms of responsibility, each class should have a single responsibility. A god class has many. A common thing I see new game devs make is a "GameManager" class that just does everything

There's nothing wrong with a God class

I feel like "single responsibility" is very poorly defined. One could say that "Managing the game" is the responsibility of the "GameManager" class and there are no other things the class must do, so therefore it follows that principle.

People just decide to throw unnecessary shit in a God class

It's perfectly reasonable to create a God class if it's an entrypoint to the main behaviour of something. Like with a game, being able to start/stop it or adjust certain rules without going into the dependencies that hold the main logic for them

A God class is also a very good place to apply main communication between dependencies that rely on eachother, without making them communicate directly. This is a very good way to scale

I made a console for Unity yesterday doing exactly this and it's very easy to use, adjust and read in general

And that person would be right from a logical standpoint. I'd be surprised If I was the only one that doesn't really understand the scope of this principle.

if you have a class called SomethingManager that's quite a yellow flag to begin with

So you mean that there should be no classes that manage other things?

exactly, it shouldn't "manage", it should do something specific
if it's called Manager then you have no idea what it really should do
it has... all the responsibilities? which goes against previous said principle

I see, this makes more sense

I read Clean Code. Uncle Bob says that functions should be operating at a single "level of abstraction". A "manager" can be fine if the way it's interacting with other objects is at a very high level. But if it starts getting deep into messing with other objects it'll quickly become a mess and way too many responsilbilities.