> dropping the scene graph/ECS way of doing things
A scene graph and an ECS are basically polar opposites, arbitrarily heterogeneous object trees to facilitate genaral manipulation vs. rigorously organizing data to facilitate good performance. Please explain what you mean.
engines like Unity and Godot encourage you to organize your conceptual model of your game in their scene/node and component systems. if this is the only way you learn to make games, you will only ever think about things in these high-level, abstracted terms, instead of thinking about what the computer is really doing, thinking about what you want the computer to do, and thinking about how simple you could make things if you didn't force yourself to use such systems inherent to these engines.
Do you mwean, why use a good, "abstracted" game engine if you can make a bad, "simple" one yourself? Or why make portable games "instead of thinking about what the computer is really doing"? Do you think advanced games could be made if the designer doesn't "think about things in these high-level, abstracted terms"?
I suggest an exercise to understand the value of abstraction: a remake of a Commodore 64 game using JavaScript (Canvas to simply draw pixels, nothing fancy).
> Do you mwean, why use a good, "abstracted" game engine if you can make a bad, "simple" one yourself?
you should definitely make something good instead of something bad. I don't understand what you mean by this.
> Or why make portable games "instead of thinking about what the computer is really doing"?
I'm assuming by "portable games" you mean the code is easily able to be ported to other platforms. code portability and "thinking about what the computer is really doing" are not orthogonal concepts.
> Do you think advanced games could be made if the designer doesn't "think about things in these high-level, abstracted terms"?
there is nothing wrong with thinking about game design in high-level, abstracted terms. what is misguided is thinking code should be written this way.
> I suggest an exercise to understand the value of abstraction: a remake of a Commodore 64 game using JavaScript (Canvas to simply draw pixels, nothing fancy).
I'm having trouble understanding why you've made this suggestion for me? what does it have to do with anything?
I was the engine architect for a couple of team game projects I worked on in college a few years back. at the time, the Unity ECS/scene hierarchy system was The New Hotness and everyone was evangelizing it, professors were encouraging us to explore using it (without giving any implementation or theory advice—our first project had to be written in C89, the second, C++).
it was a gigantic waste of time and resources. we could have made our games functionally identical in a fraction of the time if we just did things the easy, obvious way, and then we could have used all that extra time to make those games that much better.
A scene graph and an ECS are basically polar opposites, arbitrarily heterogeneous object trees to facilitate genaral manipulation vs. rigorously organizing data to facilitate good performance. Please explain what you mean.