For a realy detailed explanation I recommend reading the one and only bible Game Engine Architecture by Jason Gregory. I guess it is the most complete work about this topic since it was published. It does not only handle the C++ part but also and important for every game engine programmer the theory/architecture behind. It's a good starting point independent of the language. To get an overview what we are talking about is this image from the book
Let me give it a try to answer the question.
Whatever you write it will be code :-) after years of experience, write what you need and how you need it or use what provides you what you need.
The terms engine and framework come from software architecture along with other terms. So let's start with the basic terms und lets move upwards.
Typical examples: a math library providing all the basic types and functions for mathematical calculations (Vector, Matrix,...) or image (jpeg or png) library providing the functionality for writing jpeg or png images
In Unity 3D Math is a math libray.
Theory: a libray provides dedicated features around a topic (e.g. math) AND is called by the programmer on demand.
Some preview: there can be libraries holding frameworks aka being a framework library.
Theory: A framework introduces an inversion of control. This means the developer most of the time does not call the framework methods but the framework calls the code of the developer. Exceptions are when you have to integrate the framework library in your code and have to start the framework.
A framework library provides all methods and functions and interfaces for a framework with a dedicated usage. So frameworks can be in a library.
The Unity 3D MonoBehaviour provides methods like Awake, Start, OnUpdate. The developer implements these methods and then these methods get called by the (game object management) framework (this is the inversion of control).
The same with the methods OnCollisionEnter, OnCollisionExit. They are in the same Monobehaviour but I would bet they are called by the physics framework.
An preview: Engine, Runtime, Editor, SDK
Since the term engine was always kind of vague and still is (and it does not become better with further technological developments) some preview explanation.
The term engine is used for multiple things and it can not be uniquely said which one is right.
Back in 2004 when I first had contact with writing game engines it was vague too.
You had a game engine in the meaning of some sort of code loading predefined data and let you play the game. Since it loads predefined data they were called data-driven engines. You compile them once and the external data could have been different games without recompiling it. At some point of time this was the same like a runtime.
The editor is clear. It lets you define the predefined data loaded by the engine/runtime.
An engine with an editor was called SDK (e.g. Hammer SDK).
Then there were/are dedicated engines. A phyiscs engine, rendering engine, sound engine, gameobject management engine, network engine,....
In my personal opinion those are not engines (especially a render engine IS NOT a game engine since it does only rendering). When I google game engine the results contain 90% pure render engines which are not game engines. I would call all of them libraries but since they may load predefined data they would match the term data-driven engine.
A last short side note before we get into details:
I successfully graduated with a masters degree in computer science. My master thesis handled the topic "how to develop the core of a game engine". Meaning the part of the code which clues together all the other engines, does the game object management, the game loop, etc...
I published my master thesis as a (short) book. The only comment on Amazon from a buyer/reader is (after a few years out): this is not about a game engine. Since I graduated successfully and therefore have defended my thesis against 3 experienced programmers (2 of them dedicated to games and interactive applications) I guess I have written a game engine.
Easy: lets you define the data in the format the other parts require them and therefore eliminates the demand to write those files by hand or use external tools to create them.
This is what the Unity 3D editor does.
This term is often used equally with engine (which can be correct or incorrect).
The runtime executes the generated data and does what it has to do with the data. E.g show you the game and let you play the game. It does not create any data (except maybe save games) in the meaning you can't modify the game itself withit.
The Unity Web Player is/was a runtime let you play Unity games within a webbrowser.
You can load and execute multiple different games with the same runtime.
In the case of the Unity 3D scripting API there is a cut between functionality that will work in the game and functionality that will only work within the editor.
This term is often also called framework.
Back then an SDK has been a bundle of tools like an editor, IDE (integrated developer environment) for programmers, exporters for dataformats and the runtime/engine.
So an SDK/framework provides you with a predefined workflow and utilities and shows you a (well designed) way how you can (easily) create a game.
Basically Unity 3D engine would be wrong since it would fit more into the SDK direction. But since Unity is even more a new word/definition is needed to match what it is.
Anyway, to introduce the other term, an SDK/framework provides you a predefined game development pipeline (not only a asset pipeline but maybe, like Unity, a pipeline for assets, logic, builds, deployments,....)
sarcasm on Used for everything since everybody wants to be cool by writing not only a library, a framework or a game but better writing a complete engine.sarcasm off
Let's trigger it down:
- is a piece of code/software
- it is aimed to be reused in multiple projects (you can also write a game engine for only one game)
- for being reused the game engine seperates the reusable part from the game specific part
- for being reusable (depending on how it is intended to be reused) there are different flavours like a data-driven engine loading external data
A engine can consist of multipe other engines (since everything is called an engine nowadays). A game engine can include
- a render engine doing the rendering (AGAIN: god, damn, hell: code doing only rendering IS NOT a game engine)
- a physics engine doing the physics (it's a physics engine, not a game engine)
- an AI engine handling the AI stuff (it's an AI engine and not a game engine)
- a network engine (e.g. RakNet) doing the network stuff (it's a network engine, not a game engine)
- an audio engine doing the audio stuff (it's an audio engine and not a game engine)
An example for an application based on a core engine providing a plug-in based framework for cluing everything together in a component based game object management model. Each subengine (rendering audio) is a module added to the game engine as plug in. Each component can be part of a subengine/module. And the (component based) game object management is the connecting link between the seperated modules.
The closest definiton for Game Engine
A game engine is the part of the source code of your game that provides all the functionality which is intended to be reused accross multiple games and let you code and execute your game. Therefore it clues together all the other parts of the code (rendering, audio, physics, game object management, networking) which are either libraries, frameworks or dedicated engines (rendering, physics,...).
The game engine is the mess in the middle.