Whether it's the scripting language or the physics engine, Godot's in-house solutions (and general differences to other game engines) always draw a bit of criti

Whether it's the scripting language or the physics engine, Godot's in-house solutions (and general differences to other game engines) always draw a bit of criticism. The article mentions the 'considerable amount of issues' for the in-house physics solution, but it doesn't make a direct statement about the quantity or severity of issues to do with including bullet over the years. Hugely powerful and complex physics engines have become the default solution to practically everything motion or collision related in games. But most games don't need most of what the big/serious physics engines provide. Unfortunately, there is an expectation that game engines come with one of these included and so they are, usually as the only built-in way to perform collision detection. If you're making a game that has modest 'physics' requirements, you're stuck trying to break the big physics engine to get it to do less. If you're making a game that does have a need for a high-end solution (e.g. PhysX), it becomes increasingly painful as you are forced to access the physics engine via the APIs that the game engine provided.