What Is An Engine?

"Engine" is not a formal term, so it has no strict definition.
It's an umbrella term for all the code libraries, APIs, SDKs, tools, scripts, embedded languages, frameworks, samples, documentation and assets that can be used to make games in general. Bundle all those things up and you've got yourself an engine. Some engines might just be an API and some crummy tools. Other engines might be a suite of APIs and some all-encompassing tools.
You could call Monogame an engine if you wanted to, and people can argue otherwise, but no one is right because it's not formally defined

If you write a game, and then write a second game... then all the stuff that you can scoop out of the first game and reuse in your second one is your engine

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'm beginning to settle on the following definition:

if it contains the main loop, its a generic or custom engine. else its a library.

i sort of don't consider games that use custom code in lieu of a generic engine to have an engine at all, but "custom engine" isn't a bad way to describe the custom code, i suppose.

if it contains the main loop, its a generic or custom engine. else its a library

Glut, xna and monogame control the mainloop. Are these engines? I would consider the first an api and the second two frameworks.

To me an engine is anything that performs a sealed black box function. For example a graphics engine. In a non game program I used to be involved with for example the entire thing would be considered an irc server framework and the irc server itself. However inside it was a threading engine (specific to platform) and a socket engine (also specific to platform). All the framework facilities were tied into a module system which we called an api. In the end it was me as developer who decided what to call an engine, what to call an api and what to call a framework.

For example a graphics engine

yes, last night it occurred to me that "engine" is used for a lot of things.

graphics engine, physics engine, etc.

but by and large these are all libraries of some sort.

a generic exe with a main game loop makes it a data driven app - more what i'd consider an engine.

as stated elsewhere in this thread, there's no official, de-facto, or even relatively common definition of an "engine" - so its all probably a moot point. .

wait! i know what an engine is - its the thing that makes your car go!

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.)

i think the term might have been originally coined by the gaming press, and referred to "those parts of title A which remained once it had been (heavily?) mod-ed to create title B" - as in the "Doom engine".

and then it caught on. suddenly everything was an engine. similar to the way that SIMCity inspired the naming of lots of "SIMwhatever" games, including my own first release, SIMTrek.

my definitions might change tomorrow, but for now, they are along the lines of:

engine - a data driven generic game app with main loop. game specific code is hung off of callbacks. inclusion of additional compatible tools and libraries is common.

framework - a set of general OO classes from which app specific OO classes can be derived. IE OO specific.

library - a collection of related subroutines called directly or indirectly by the main game loop.

I would agree with the fact an engine is not a defined term, but rather just a term to describe a collection of tools and other devices to allow someone to use to create or complete a specific task. Thats why there are game, physics, and game engines. A game engine is more general, and usually allows one to create any game of choice with it. Some game engines are more specific, such as the Spring Engine, which is designed for RTS games.

Generally I see that when people make a structure in which someone could design a game, such as an ECS, they call it a framework.

In the end it really comes down to what you really want to acomplish in creating.