Perhaps if you're completely devoid of imagination.
It is in fact possible to make video games without deferring to open-source libraries for every single aspect of it.
NIH is a cultural pillar. Even scripting layers are relatively split on if they're in-house or not. It's not uncommon to find both an in-house fork of Lua + a few other completely custom scripting engines all serving their own purpose.
If you need to do efficient path finding on random triangle geometry (as opposed to running A* on simple quad or hex grids) it quickly gets tricky.
What has undeniably declined is the traditional "10k US-$ commercial middleware". Today the options are either free and open source (which can be extremely high quality, like Jolt: https://github.com/jrouwe/JoltPhysics) or fully featured engines like Godot, Unity or UE - but little inbetween those "extremes".
I did mention this was changing in particular with physics engines. That being said, proprietary dependencies still reign supreme in places like audio engines. Something like OpenAL isn't really a replacement for FMOD or Wwise. I know those off-the-shelf engines roll their own replacements, but then they also roll their own pathfinding and navmesh generation as far as I know.
> Industry Standard - Recast powers AI navigation features in Unity, Unreal, Godot, O3DE and countless AAA and indie games and engines
I see the industry is of full double standards :)
It's not a terribly long list, it seems, even if it's non-exhaustive.
> I see the industry is of full double standards
Absolutely, and that's why it's so great. No two companies are going to look the same. The culture of the video games industry is a rather unique one that's kept its archipelago syndrome alive against all odds. It'll be a sad day if that ever changes.
There are entire classes (even genres) of video games that don't require substantial third-party library support, and it's frustrating to see that this seems to be more and more of a minority view as time goes on.
Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params).
E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)):
https://github.com/floooh/sokol-samples/blob/d8429d701eb7a8c...
Dear ImGui is a bit of an outlier for C++ libraries though, since it is essentially a C API wrapped in a namespace.
OzzAnimation is also fairly trivial to wrap in an (abstracted) C API, for instance I use this in some of the sokol-samples:
https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
Implementation: https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
...used in this sample:
https://github.com/floooh/sokol-samples/blob/master/sapp/shd...
...WASM live version:
https://floooh.github.io/sokol-html5/shdfeatures-sapp.html
TL;DR: quite a few C++ libraries out of the game-dev world are actually quite easy to access from C or languages that can talk to C APIs, mainly because the game-dev world typically uses a very 'orthodox' subset of C++ (no or very restricted C++ stdlib usage, no rtti, no exceptions, ideally no smart pointers in the public API).