Yes, this is basically correct. When you start writing a game with MonoGame, all you get is basically a class with two methods, Update() and Draw() that MonoGame will be calling in a loop, plus a bunch of libraries for input, graphics, audio, content loading etc. you can use in your code. It's a step beyond something like bare raylib or SDL2, but it's a far cry from Unreal, which lets you think in terms of game entities from the very start: "here's the map, here's where the player will spawn, here, add some buildings and you can run around them".
With MonoGame/XNA/FNA, LOVE2D, libGDX, HaxeFlixel you are getting a bunch of tools instead, which is probably not bad if you like coding and your game doesn't fit into one of existing popular genres.
I think a lot comes down to whether a game is art-first or code-first, and almost all modern games are art-first, so it makes sense to have your platform be one that artists and designers are immediately productive in, and the software people are basically writing behaviour modules and plugins for that established system.
But it's good that code-first engines still exist. There are always going to be projects that are more experimental, or don't have a clear pattern of entities, or are dynamic enough that that kind of thing doesn't make sense.
This is a somewhat naive view of engines in modern game development. Full-featured engines allow every department to dive in head first in parallel. The first gameplay elements often get programmed before the first pieces of content arrive. Scenes can be blocked out and drafted immwdiately at the start of the project. Complex animations with states and blend trees can be created amd tested independently of the gameplay code. Audio scenes, complex cues and (dynamic) music can be mixed and mastered independently of any code to integrate audio into the game. The whole process is highly parallelized these days and the engine tools serve to insulate the departments from one another to some extent so that everybody can move faster.
Right, yes. I think all I meant is that in earlier generations you could do modeling/sprites and concepting from the beginning, but there was a hard line in terms of how much code had to exist before the whole thing started to look or feel like much.
Thinking here especially of the Doom / Quake / HL1 era where they were basically building the level design tools in parallel with the game.
Whereas nowadays you can have movement, mobs, dialog flow, etc all with very little code, and it's placeholders like "oh we need a custom shader for this effect" or "that boss needs some custom logic".
You don't have to reinvent all these systems, but in my experience, you still have to code a lot to wire these very generic building blocks up in a good way that fits your specific use cases.
With MonoGame/XNA/FNA, LOVE2D, libGDX, HaxeFlixel you are getting a bunch of tools instead, which is probably not bad if you like coding and your game doesn't fit into one of existing popular genres.