After trying to evangelize this exact mindset to people in the wake of the recent Godot drama, I've given up (or not, judging by my posts here…). Most people aren't willing to even investigate how easy it is to make “a game engine”, because the term “game engine” has been mythologized (due to Unity, Godot, etc.) into being this thing that's for all practical purposes impossible for the average programmer to build.

“As a solo developer, either you work on building an engine, or you work on building a game, but if you're going to do the former, then you'll never complete the latter,” they say (in this very comments section, even). Well, sure… if by “game engine” you mean “general-purpose super-generic game engine,” and not “the smallest set of things absolutely necessary to transmute the idea I have in my head into playable form on this supercomputer I'm sitting in front of.”

I don't really get it—I started programming games by learning Game Maker in the early 00s. By the time I was ready to move onto something more like “real game development” (C#/XNA), I was more than eager to structure things more according to how I wanted for whatever given project I was working on, rather than trying to cram my ideas into a somebody-else's-engine-shaped hole.

But the freely-downloadable general-purpose game engines available these days, with their innumerable layers of wholly-unnecessary overly-generalized one-size-fits-all abstractions have gotten most people who use them to never even consider even imagining doing things in any way other than the way they're now used to doing them, using their tool of choice. They're more than happy to settle with thinking about game design purely in terms of whatever high-level primitives are exposed by their preferred engine, rather than even consider even imagining what it would be like to have complete control over how their game logic is organized and executed.

Why simply define structs and make arrays of struct instances and iterate over them, when you could make a byzantine web of Nodes/GameObjects in the engine-provided scene graph? I guess that's how indie “game developers” these days have been trained to think.

And it's crazy because compared to only a couple short decades ago, there's more information and resources available out there on the Web for free, that anyone can read and use to make building something “from scratch” (where “from scratch” means “using open-source libraries to do the parts you don't want to learn more about for the time being, such as rendering”) easier than it ever has been before! You can use something like SDL or Raylib to “sketch out” a gameplay prototype in shockingly few lines of code, then refactor everything so that all library calls are wrapped in function calls more suited to your use case, and then, later, if you want, you can replace those library calls with your own code!

It's not difficult to do at all, but I think there's just some level of comfort people take in having a GUI editor for their “game engine” that they can open a blank project in and start clicking around to make things happen on the screen, compared to staring at a blank source code file and figuring out where to go from there.

The ever-decreasing baseline level of curiosity and hacker-thinking in younger programmers continues to both baffle and depress me.