Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You would see similar things in something like Unreal, or even in-house engines. The implementation is likely also to be way more interested in acting on aggregate data streams rather than enforcing strict encapsulation and object boundaries and such.

It's still very OOP, but not in the sense of representing real-world taxonomies.

I know there's an argument that this real-world metaphor is good for beginners, but at least in my personal experience I don't think that's the case. I remember when I was a kid, my dad tried to teach me coding with a lot of object oriented examples with like Cats and Dogs and stuff. He was really well meaning, but it never really made sense to me. I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. Awful code, but 10 year old me was able to reason about that a lot easier than polymorphism/encapsulation/scoping/etc.