Yes, I do realize how much work people need to do to make games within arbitrary frameworks provided by game engines, and alluded to such in previous posts.

XNA never had a scene graph though, I don't know where you got that idea from. XNA and its descendants give you a basic game loop, and then it's entirely up to you how you structure your game logic from there.

There's nothing wrong with using someone else's structural backbone, like the library you made that you mentioned -- but everyone who wants to self-describe as a “game developer” should try to do this themselves, without such a thing, at least once.

Video games are computer applications, and computer applications consist of data, and functions that operate on said data. When you learn to think in these terms, stuff that seemed complicated before becomes very simple to reason about, and also very easy to write code for. Sometimes, a more generalized scene graph-type system is the best fit for what you're trying to do. Oftentimes though, it's not, and you're unwittingly contorting your thinking about the problem space to fit the shape of the predefined structure you've chosen to use.

One example of this is how Game Maker (in the old versions—I don't know much about the newer GameMaker Studio) is structured. You define “Objects”, and each Object has, in addition to many other properties, “Events”, each of which can have one or more “Actions”. You also define “Rooms” (scenes), with a 2D GUI editor that lets you place instances of Objects within the Room. The first Room in the Room list is where your gameplay begins.

When you first start using Game Maker, you make a Room for each level in your game, you define Objects, and you place instances of Objects in your Rooms. You define logic with Events within Objects -- init stuff goes in the “Create” event, and update stuff goes in the “Step” event. You drag and drop Actions into Events in your Objects to define gameplay logic.

This is all well and good, but eventually you grow out of using any Action except “Execute code”, which lets you type GML code in an integrated editor. Eventually, you learn that it's a good idea to keep your “controller” logic in a single instance of a single Object—separate from your player character Object—called “objController” by convention. You put a single instance of objController at (0,0) in your first Room, and mark the “Persistent” checkbox in objController so it persists across Room transitions.

At this point, you're “fighting the engine”. The engine does not provide a first-class means of defining “controller logic”, so your only means of doing something like this is as I described above: defining an entire Object type—which contains tons of properties and functionality that you'll never use for this Object—just to allow you to define some code that gets run every frame. As an advanced Game Maker user, you get used to it, but you wish that this common pattern was given first-class support, so you didn't feel like you were “fighting the engine” to do something so obviously common.

As you become an even more advanced Game Maker user, depending on the type of game you're making, you might end up eschewing most if not all of the structural features of the engine, just so it “gets out of your way” and lets you write the code you want to write to make the game you want to make. You might end up as I did—having only a single Room, containing only a single objController instance, and then handling everything else yourself from there.

When I reached this point as a teen, had Raylib or XNA existed and had somebody shown it to me, I would've said, holy crap, this is exactly what I'm looking for. (XNA did come about shortly thereafter, and it's where I ended up going after outgrowing Game Maker.) I just want to draw sprites and text and simple geometric shapes to the screen, and I don't really care about learning low-level graphics stuff to learn how to do that myself, so if you can handle that for me, that's great—but I can handle managing all of the game's data in structs and arrays myself just fine though.

But apparently this is not the case for many modern game engine users. They learn to “think in terms of” whatever primitives the engine provides them with, and then decide that that's good enough, they don't need to learn anything else. They're already thinking in Scenes/Prefabs/GameObjects/Components—why stop now?

I firmly believe this is huge mistake, because it's such a self-limiting way of thinking about game development, and it causes you to become entrenched in your limited way of thinking about gameplay logic. But before last year's Unity debacle, my views were very unpopular, because, what's wrong with just using Unity, man? Well, now we know: it's not a great idea to invest one's entire way of thinking about game development and one's entire business prospects so heavily in someone else's platform, when they can decide to fuck you at any point in time, causing you to suddenly realize how dependent you were on said platform.

Some of the upvotes I've been getting in this thread are somewhat encouraging—maybe people are starting to come around to my way of thinking? (Not that I have a monopoly on such thinking, by any means, of course.) But many of the comments are incredibly discouraging—people really like to tie their entire identity to the specific-engine-specific way of thinking about game design and development, apparently, even when pitfalls of doing so are clearly outlined, and it's blatantly demonstrated how easy it is to begin to think outside of that box.