[DominikD]

That's not the point. You've got code responsible for audio, asset loading and streaming (which tends to be ad-hoc in "engines" that focus on rendering), UI, state loading and saving, visibility query DB, nav meshes, and a lot of system and gameplay logic further divided into unique modules (character management, damage management, etc.) Yes, editor is a must these days (and has been for over 20 years) but that's not the point DeathArrow was making.

[flohofwoe]

What if your game embeds all assets in the executable as runtime structures instead of loading files? What if savegames are just checkpoints instead of serialized game state? What if you render so little data that you don't need complex visibility checks, etc etc etc...

Simple 2D games don't need all the runtime components that a triple-A game needs, yet a game engine for 2D games is just as much a game engine as an engine used for triple-A games.

[Buttons840]

Does every game have an engine?

This is a good time to point out we're really arguing over the definition of a word here, and can probably agree on a lot of facts and observations, even if we don't agree on what the definition of "game engine" should be.

[kevingadd]

Even the mainstream 2d engines like game maker provide a lot more than just physics and graphics.

[skohan]

It really depends on the games you are making. Not every game needs nav meshes for example.

For things like audio and asset loading, you can get really far building on top of a library like SDL2 or GLFW as a cross-platform system interface, and using some single-header libraries for things like loading models or playing audio samples. There are also great physics libraries out there like Chipmunk or Bullet which neatly encapsulate most of the "hard stuff" in building a game engine.

For something like a 2D platformer for example, it's perfectly reasonable and easier than ever for a solo developer to take on building a small custom engine.

[NicoJuicy]

Play("sound.wav");

Load("Asset.png");

That wasn't so hard