Don't get caught up on the concept of a "game engine". While it is true that game studios often have some sort of game engine which they create in order to speed the process of producing games, many independent developers get hung up on trying to create a game engine that they never actually make something that works.
A game engine can be whatever you want it to be. If you find enough in common between your games that you can subclass an
Engine class like your example, that's fine. If an "engine" is really just a small library of functions which you've found to be handy in past games you've developed, that's great too. Whatever it means to you, the concept of an "engine" is just reusable code to help you make more games.
If you're trying to make a game though, don't focus on making an engine. Make a game. Once the game is done and you're ready to make your second one, start making the second one, and you'll find bits that you already made in your first game; then you can extract those bits into a library or engine, to be shared between the two games. That's how an engine should be made. It's not typically something that you decide to write before making a game, because you'll end up with tons of code which is untested and you are essentially writing things before you know you need them (therefore you might not even need them). This is like premature optimization, but worse.
So to directly answer your question, basically a game engine is a reusable "thing" (library, tool, framework) which a game studio uses to aid in quickly producing games, and they typically create it with specific games in mind or after having created several games, extracting out the similar bits and moulding them into an engine which they know can be used in future games. It should almost never be created without either retrospect (two or more games already created) or EXTENSIVE planning.