I'm confused about to large, generic, ambiguous classes like Engine, Game, Level or Scene that we usually see around videogames and engines. Does "Engine" have a "Game", does the "Game" have "Levels", does "Levels" have "Scenes"? I've seen engine without "Game", games without "Engine" class, "Game" or "Application" was the "Engine", I've seen "Game" that play the role of "Levels", and "Levels" called "Scene".

Could someone provide some clarity and precision about these concepts and terms and their relationships?

Usually in tutorials these are abstractions that just logically pack something that usually, by intention of the author, that is closely related and it is context specific. This is done to help you focus on that functionality alone.

In practice you do not see, classes like "Engine" or "Game" as these are just some concepts that provide some functionallity. The Engine is just a set ot structs/classes/function/etc. that provide the functionally of the so called "engine".

These are vaguely defined and vary from project to project. but when someone talks about the gameplay engine, they probably mean something that does managing of the playing objects like relationships between them, calling the update function, serving queries about the game scene (like the closest enemy, path finding).

Usually "Scene" and "Level" mean the same thing.
In tutorials and small projects "Game" usually means something that holds the whole state of the game that is currently being played, like
it hold the data needed for the gameplay, the level, maybe some resources for rendering. sound or the state of the players input.
"Application" is usually an abstraction around the window system of the OS, haling keyboard and mouse input.

You are not obligated to use these same abstractions, you can build you code the way you think makes more sense.

PS. Usually I do not use the word "usually" as often

https://github.com/g-amador/JOT

Click on link to the the article.

But resuming:

Game engine is a term. 
Historically, it arose from the need to reuse games code and not building them from scratch.
In short, a game was made but some sort of personalization was allowed to make another game (e.g., FPS engine you changed the damage and sprites for models scenarios and voila another game).
Latter specific tools to make games where developed to build generic games, providing modules for components often needed in games (Unity Engine).

Often a AAA game engine (Unreal engine) is the great great great grandchild of a game that became an engine and was re-re-re-re-re-engineered.

This is a generic overview of what is a game engine.

Today many games are built using major engines, but some places and some games continue to use their internal game engines.

Basically it worked like this:

Start with a simple game. Make it work. Celebrate the launch of a product.

Take that simple game, remove the parts that don't make sense for the second game, add the parts that you need for the second game. Create and release the second game. Celebrate the launch of your second product.

Take that code, remove the parts that don't make sense for the third game, add the parts that you need for the third game. Create that and release the third game. Celebrate the launch of your third product.

Repeat several more times, each time pruning the things that don't make sense and adding the parts that are extra.  Soon you'll build a common set of functionality that most of your games rely on.  THAT is the engine.

In the case of Unreal, Sweeny started building games in 1990 and releasing them every few months starting in '91.  By the time they hit Jill of the Jungle in '92 it was a fairly stable engine. I remember wasting a lot of time playing Epic Pinball and Silverball, both released in 1993, and I'm quite certain they reused a huge amount of the ever-growing engine for the graphics and audio.  By the time they did a massive rewrite and created Unreal they were around game #40 or so.  

Engine code tends to include the generic forms of graphics, animation, audio, networking, AI, math, disk access, and assorted other systems. The game includes assets like models, textures, animations, sounds, music, levels, plus all the code that combines the assets in interesting ways to create gameplay. 

21 hours ago, Goyira said:

Could someone provide some clarity and precision about these concepts and terms and their relationships?

While we all have some vague ideas what the concepts that you mention mean, there is no universally agreed precise definition of any of those terms. As such, "Engine" in one game is not the same thing as "Engine" in another game, and this holds for all terms.

That is, you can understand the relation between the terms within a single game, but that relation normally doesn't exactly carry over to any other game.

Classes like Game or Engine are often used to solve a couple of needs. The most important one might be to initialize the game/ engine code from a given entry point. Think of your game as a program that runs on the OS, every program needs an entry point the OS passes control over to the program code from a process entry.

Engines like Urho3D provide a macro for it that you just use and fill the parameters with your function names. The macro-processor then generates the matching entry point for your platform, a method called Main or WinMai, that calls your functions Initialize, Loop and Shutdown to perform actions on these steps of your game.

Another approach is to provide real engine related properties like a version number or the names of plugins loaded. These informations are used if you want your code run on an engine regardless of which version you use so you can conditionally toggle single features of it