Some of those things do have more formal or more commonplace definitions.

An API (Application Programming Interface) is usually a bunch of code and/or binaries, sometimes with documentation about how to use the code. It usually just specifies the interface between your program and someone else's programs. You generally need to do absolutely everything yourself to use their system, they just give you the information to interface with it. An API itself tends to be a smaller thing, just the interfaces necessary and not necessarily all the other useful parts.

An SDK (Software development Kit) is usually one or more API plus a collection of other things, the 'kit', that are associated with the API used for developing software. Often it comes with examples, documentation, build tools and build scripts, compilers, emulators, or whatever else you need to do whatever the SDK is for.

An engine is less defined, but very often is more than an SDK. As more than an SDK it includes all the things you need, coming with examples, documentation, and the parts needed to build and use the thing. Usually it is something that can run immediately as a game on its own right out of the box, and you modify it and make changes to turn it into the game you want it to be. Many game engines rely on multiple other SDKs and APIs and include them as part of the package.

Would making a project with these ideas and methods built-in make it an engine? It is, after all, a tool that makes life easier for devs.

If you were marketing it today, the pieces would probably be called an SDK rather than an engine.

This is one of those questions that doesn't have a single correct answer. If you go back in time when 8bit machines ruled the gaming world, most of the code could not be ported directly to work on another platform. We wrote pure assembly code, being close to bare metal. The code was tightly bound to the hardware and it wasn't really worth trying to use for example C, because it was very unlikely compiler would do better job that human. This way most of such written code couldn't be reused. Porting game to different platform meant rewriting it.

Times changed. Compilers became smarter, CPUs became faster. It made possible to use higher level languages like C. Still, the code and the machine were tightly coupled, but big chunks of such code could be reused for next, usually similar game. This gave birth to very first engines. It's worth noting that word 'engine' appeared lot later. It's not known who said "engine" very first time, but it's dated to early 90s. It means that probably the development of first 3D games and mostly contribution of Quake and Unreal made word 'engine' the term we know today. It doesn't mean there were no 'engines' before that time. After all SCUMM today is also called "the engine". It's just in 80s nobody used this word to describe certain set of functions.

So what the engine is?

Historically, it's reusable piece of software that delivers all major subsystems to built a game on top of it. How was it different from framework? Well, it wasn't. Many engines are also frameworks and vice versa. It's just term that became popular in video games but describing something that was already well known anyway ( like recently ECS ;) ). We could call engine any 'common code' that implements basic low-level subsystems (graphics, input, sound, resource handling, memory management, scripting, etc.) that has been reused in at least one game. Was "Wolfenstein3D" engine? It was never named, but the code was reused in several titles ( including weird case of "Super 3D Noah's Ark" ). I mentioned SCUMM already. Reused code could be improved for the next game, but it was still same code base.

Today we look at it little different. We see engine as some sort of player. There's set of libraries and tools. We do not fiddle with the actual engine. We create content that will play when loaded by the 'player'. For example Unity is such a player. This may also give us distinction between engines and frameworks. One might say, framework doesn't limit you, doesn't close programmer in hermetic environment. We may consider Ogre3D to be a framework. Some engines are also frameworks in that matter.

Defining the word "Engine" isn't simple, because everyone may understand it different way - and it's all correct. But at the core I think those old titles tell us, what engine should have, because otherwise nobody would call IdTech or Unreal "The Engine" back then ;)

I used to think as Norman Barrows does, that "if it contains the main loop" we could call it an engine. To some point, this may still be true; and in my personal case, reading this thread just kicked off another new post in my journal about it, in defining various aspects of my meta-game-creation. I still somewhat agree, but then the concept of an engine must still be more than just that.

As with what j_uk_dev wrote, I agree with that too, although in my writing I tend not to use the term "framework" as much, if at all, even though it may often apply to some parts of my development. The precise distinction between a framework and any other set of independent libraries is of interest to me, and something I may find useful to write about at another time.

Long story, cut short: is it really so important what we call an "engine" or a "framework"? The term has been in the general consciousness of gamers and game developers since, if what j_uk_dev wrote is true, about the mid to late 1990s if not earlier, but the general question is, is terminology so important to define in many concepts, especially where the end-user may never really need to know the game's parts or how the internals work? I only ask, because, as much as I'd love to create journal posts about any and every aspect of my game-development, ... at the end of the day, the end-user only wants to know that this game or program works as designed. (Now, I know I would like the end-users of my products to know the same things I do, but perhaps that "spoils the magic" in their particular case.)