Absolutely agree. Explaining what goes into a game 'engine' is a great thing but this article misses on every front. Calling the math library a 'math engine'

Absolutely agree. Explaining what goes into a game 'engine' is a great thing but this article misses on every front. Calling the math library a 'math engine' more than bothered me, it is just plain wrong. It's just a few data type classes/structs and the associated templates and code to manipulate them. For an OpenGL game engine #include "glm.h" is going to do pretty much everything you would want in a battle-tested way. There is so much in here that is inaccurate, misleading and just plain wrong: "To render a pixel on a screen you need to communicate with the GPU. To do so, you need a medium. This medium is called OpenGL." What about WebGL, Vulkan, DX, Metal? What is a medium? "Scenegraphs are generic trees and they provide a fast way to traverse game entities. You may want to use C++ vector containers instead. This is all right. The problem is that they are too slow to traverse. Thus, if you can, use scenegraphs instead." How is a vector too slow to traverse? If I want to traverse linearly it is pretty much the fastest container. How is the scenography ordered? Is it ordered by an object/transform hierarchy, is it ordered for rendering speed, is it ordered by locality for culling/streaming, all of these? Why is he inventing terms like the 'engine loop' where most people use 'game loop'? And yeah, so many missing systems. Even the description of the physics 'engine' misses collision detection. So great that the author learnt about game engines, but dangerous for them to then present such an incomplete article with such an air of authority.