What a Game Engine Actually Does, for People Who've Never Opened One
A game engine is a restaurant's kitchen infrastructure — the stoves, the walk-in fridge, the plumbing — not any single recipe made with it.
A restaurant kitchen has to have working stoves, refrigeration, plumbing, and ventilation before a single dish can be cooked in it — infrastructure that has nothing to do with any specific recipe, but that every recipe made in that kitchen depends on completely. A game engine plays exactly that role for a video game: the shared, reusable infrastructure that every game built on it depends on, regardless of what that specific game is actually about.
Concretely, that infrastructure covers a handful of core jobs, all of which have to work correctly before a game's own unique content can run on top of them. Rendering draws every frame the player sees, translating a 3D scene's data into an actual image on screen dozens of times a second. Physics handles how objects move, collide, and respond to forces like gravity, so a designer doesn't have to hand-calculate what happens when two objects bump into each other. Input reads what the player is pressing, on whatever device they're using, and translates it into something the game's own logic can react to. Audio plays sound and music, positioned and mixed correctly in the game's 3D space. An asset pipeline imports and manages every model, texture, and sound file the game uses, and a scripting or programming layer is where the actual game-specific logic — this specific game's rules, characters, and behavior — gets written on top of everything else the engine already provides.
None of those six things is specific to any one game's genre or story — a racing game, a puzzle game, and a first-person shooter all need working rendering, physics, input, audio, an asset pipeline, and a scripting layer, even though the actual content built with them looks nothing alike. That's precisely the value an engine provides: without one, every studio would need to solve "how do I draw a pixel to the screen" and "how do I detect a collision" completely from scratch, for every single game, instead of starting from a working kitchen and getting straight to cooking.
This is also why choosing an engine is a genuinely consequential decision made early in a project, not a detail to sort out later — a studio is choosing which kitchen's specific stoves, fridge layout, and plumbing it's going to build every future recipe around, for as long as that project uses it.