> Sounds very much like the description of a big ball of mud.

I mean, yeah, kinda.

For any given object in the game world, it's funnest for that object to be able to interact with as many other objects as possible in as many ways as possible. A game object's handles for interaction need to be globally available and can't impose many invariants—especially if you don't want level designers to have to be constantly re-architecting the engine code to punch new holes for themselves in the API. Thus, a lot of the logic in a given level tends to live inside the callback hooks of level objects, and tends to depend on the state of the rest of the level for correctness.

Modularity is a property of high cohesion and low coupling, which are themselves only possible when you can pin down your design and hide information behind abstraction boundaries. But games are a flexible and dynamic enough field that engines have to basically let designers do whatever they want, whenever they want in order for the engine to be able to build arbitrary games. So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.

> So game design is naturally a highly-coupled, incohesive problem space that is poorly suited to unit testing.

Poorly suited? Perhaps, but so are certain web system architectures as well, neither is impossible to test.

I think Factorio is an example that it can be done if you care about it... it's just that most studios shipping games don't.

https://www.factorio.com/blog/post/fff-438

https://www.factorio.com/blog/post/fff-366

Of course, in their case it can actually be justified, because the game itself is very dependent on the logic working correctly, rather than your typical FPS game slop that just needs to look good.