At the very least a bespoke engine will deal with state management, data loading and saving, audio, gameplay systems and probably AI. I'd even argue that these are more of a focus in indie games than rendering is.
You do not always need a sophisticated assets loading mechanism nor AI modules. Or you need them in a different way, than what the engine provides (mostly my experience).
My point is, "game engine" is not a static universal concept.
Not every game needs a physic engine, for example, nor even assets(I think there are engines for text only rpgs)
(A point where the article is indeed poor)
The term becomes a bit meaningless then.
Many a better approach would be to ask whether every game needs a game engine?
And maybe no, not every game needs its own engine, but after a while you could probably extract a game engine out of every game. Whether thats worth it, usually depends on the success of the game ..
However, I agree with the OP that there are certain low-level components that are common in most games and that you'd therefore expect when choosing an engine. I'd argue that you'll at the very least want to have a game loop (or engine loop), processing of player inputs, a renderer (even if it just renders 2D sprites), and probably audio output. That usually implies you have some sort of assets that have to be managed, even if those are just bitmaps and wav files.
All of this reminds me of the discussions about what makes a game, which are common in academic research about computer games. When one mentions "computer game", I'd argue, most of us immediately have a certain mental image, usually strongly influenced by AAA games. But technically, you could also just hand your player a folder of text files that they have to navigate through in "choose your own adventure" style - and you have a "computer game" without even having a program at all.
Yeah, I agree those are the features I would expect from a common game engine. Maybe with some DB as well.
Otherwise yes, a game engine is just a special framework in my opinion. And you always have to choose the right tool for the job.
"you could also just hand your player a folder of text files that they have to navigate through in "choose your own adventure" style - and you have a "computer game" without even having a program at all. "
And I think someone here recently just published that, as a game to learn bash..
"Game engine" outside of the context of making a game is just a runtime (and/or environment), and I agree it becomes a bit meaningless (as a prescriptive thing).
It's like saying a CPU needs to have vectorized operations, or even a hardware multiply, to be called a CPU. It's true that in many, if not most, cases those are essential components. However, I find it more useful to define "game engine" as "whatever takes care of the game, physics, and display logic implementation for a particular game".
> Many a better approach would be to ask whether every game needs a game engine? So, by my definition every game _has_ a game engine. I think a more interesting question would be, "when does a game engine need to be considered as its own logical layer or compartment?"