> Ogre is not a game engine. Unreal, Unity, CryEngine, Frosbite are game engines.

Including the editor tools and asset pipeline into the term "game engine" has only really become fashionable after Unity became so incredible popular, from that moment on, Unity and 'game engine' became synomymous and everybody else (including Unreal) copied the Unity workflow model. Most of the team works in the integrated editor tool in Unity most of the time, thus the editor tool has become synonymous with "engine" but it is actually the "factory line". But this integrated game development model isn't the only possible model just because it has become so popular.

It's just as well possible to create a mainly "programmer driven" game engine where tools are only used to provide the asset data, but the actual game is fully built in code (IMHO it would be much less confusing if the term 'engine' would only be used for the runtime parts that actually 'drive' the game).

At its core a game engine is a render loop and a game logic loop. If you're using a 3rd party renderer, your "engine code" might fit in a single source file if you're making a game like asteroids or tic tac toe for example.

What you're talking about is a particular type of game engine: a tool with integrated editor, AAA 3D renderer, and which is general-puropose enough to support many different types of games built on top of it. That's a very very narrow way to define game engines, and imo it creates the wrong impression that games are this infinitely complex medium which it takes hundreds of people to work on at the most basic level.

I think the author's definition is also too narrow, but it's perfectly valid to get into game engine development through small toy engines which are built from the ground up by one person.

"Why do people keep repeating this? A game engine is a monstrous piece of software from which the renderer or the physics is just a tiny part."

Maybe it is also worth noting, that there is a difference between a AAA monstrous game engine - and a simple one for casual browser games and the like?

So there might be even value in an article from a beginner covering only the basics?

(but I do agree, that the teaching was in a style overly confident not warranted)

That seems like an overly narrow stance on the subject. Not all games are AAA level and not all game engines need to be competing in the same category with UE4/5/CryEngine/Unity etc. trying to reach maximal "realism". Not all engines are 3D, not all engines need/want to have realistic physics models or state of the art graphics and rendering.

Is Box2D not a "real" physics engine but a toy physics engine because it's not simulating physics in 3 dimensions?

Games are games and there are a multitude of categories and multiple different dimensions how to judge any particular game or its engine. Saying that something is not a real game engine because it doesn't meet some random narrowly defined criteria is pointless.

Surely a game engine = code that supported writing & publishing a single game. Nothing more than that.

If an indie author finishes a game on their own steam, without using a popular decades-old engine, I want to hear how they've focused their perspective to make it work.

(this is the engine the author made: https://github.com/untoldengine/UntoldEngine)

I think you're ignoring how small the definition of "game" truly is.

For example, you need exactly none of the things you just described you make Flappy Birds.

Hell, insisting that a game engine isn't a "real" engine unless it can render 3D graphics on a GPU ignores such a huge swatch of games it's hard to know where to even start.

Indeed, game engines are one of the prime destinations for game devs near the end of their career. Game engine companies are more relaxed and on average better paying than studio work since they are not tied to game releases and the related crunch.

Yet there also exists a sea of inexperienced programmers jumping straight into "engine dev". They have none of the critical production experience which drives quality engines. This flood of enthusistic yet unprepared engineers causes a bipartite population. With the majority of public articles or YouTube presentations coming from those least prepared to speak with knowledge.

If you want to become a game engine dev your first step should be joining a studio as a gameplay programmer. No one wants to use an engine written by someone who does not know how to make games.

It doesn't have to be monstrous. One of the first 3D FPS game engines is idtech1, from DOOM. It's less than 400KB zipped. I don't think anyone would argue that it's not a game engine, considered state of the art at one time and ported to every system under the sun.

I agree with your points on a renderer is not an engine, though.

> Why do people keep repeating this? A game engine is a monstrous piece of software from which the renderer or the physics is just a tiny part

Even playing sounds and music at the right time will likely trip most people up

Indeed, and the main reason why proprietary APIs are a non-issue on production engines, they are packed on the respective backend plugin and that is all.

>Math Engine >Rendering Engine >Physics Engine

And the AI(algorithms) is also a considerable part of the engine? Or does each game develops everything related to the AI from scratch?

What would be some good books to get started building these peices, assuming you already knew general programming, maths and physics?