3 ms·

I'm not really impressed with this article. I'm glad the author learned some things and enjoyed it. Writing your own game engine is a good exercise and I highl

I'm not really impressed with this article. I'm glad the author learned some things and enjoyed it. Writing your own game engine is a good exercise and I highly recommend it. But this feels very much like a breakdown of one specific rudimentary engine disguised as an overview of game engines in general. The biggest thing that bothered me is that there is a huge portion of the engine missing here. He mentions physics, graphics, math (which I see more as a set of helper libraries, not an engine component), but nothing really about game logic, audio, or input. Every engine I've worked with (or written) has had a lot of its architecture dedicated to these. He does mention entities but nothing about them. I'm a graphics programmer myself but even so this seems the most central system to me. It drives everything that happens. What do the objects represent, how do they behave, how do they interact beyond bouncing off each other. Without these systems your game engine is nothing but a silent physics simulation without any player input.

LadyCailin 5y ago
I stopped reading when I noticed that every image had a copyright tag on it. This blog isn’t primarily for teaching people things, it’s for something else, if nothing else, the author’s ego.
midnightclubbed 5y ago
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.
meheleventyone 5y ago
I’d also say that 90% of the utility of a general purpose engine is in the tools that expose the rest.

LadyCailin 5y ago

I stopped reading when I noticed that every image had a copyright tag on it. This blog isn’t primarily for teaching people things, it’s for something else, if nothing else, the author’s ego.

midnightclubbed 5y ago

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.

meheleventyone 5y ago

I’d also say that 90% of the utility of a general purpose engine is in the tools that expose the rest.