Is a “game engine” a necessity for making a game? [closed]

Question

What's up with the terminology confusion anyways? Some have claimed DirectX SDK to be a game engine itself.

According to Wikipedia a game engine is a system for making games. But along what lines do what draw between the two concepts, such as "making or using an engine to make a game", and just "writing the code that the specific game will be executed upon". This is a hassle to break down. People enforce the idea of an "engine" to run games on or with, or written around, but a direct executable series of code that implements user I/O, graphics of some sort, and conditional logic, AI and animations, you have yourself a game.

Does this imply that every game is an "engine", or that a game has the potential to run as part of an engine? Confusing terminology.

Answer 1

There is no standard, canonical definition of the term "game engine." The Wikipedia article on the subject is reasonable, but isn't authoritative and you'll still find a lot of developers who disagree over various details. Consequently, you end up with a lot of slightly different (but generally similar) definitions in use and that's often what leads to the "terminology confusion." This is especially a problem when you get non-technical people (like video game journalists) using the term, because they often have a very poor understanding of what actual game development is like and tend to perpetuate half-truths and myths.

A "game engine" isn't required to make a game. A game is just a piece of software, and you can write software using a variety of tools. We tend to call some of those tools "engines" (you'll find that most developers agree that an "engine" of some sort is aimed at providing reusable building blocks).

But you don't need to use every tool at your disposal to build a product, and indeed you seemed to have demonstrated this already by building games "directly."

Answer 2

Well, the problem as I see it is that people use the term too loosely, inasmuch as they refuse to specify what kind of "GAME ENGINE" they're referring to.

It's not that "Game Engines" aren't full-fledged things, which handle all aspects of the game...
...or that they can be.

The problem is that a Physics Engine is an engine which is self-contained, and will accept inputs of things to do work on, and will output the equivalent in work, after the engine transforms the input.

So is a Lighting Engine.

So is a Graphics Engine.

So is a Sound Engine.

All of these things meet the qualifications of being an "engine", as a lexicologist might consider it, in the abstract sense, and all of these engines are game engines, in that they are all engines predominantly written to be used in games.

The extra layer of frustration comes in when you consider that you can have an overarching game-management engine, which wraps ALL of the other engines, as plug-ins, or as bolt-ons.

This is something which doesn't really happen often, in the real world, except when thinking more of fully-autonomous corporate subsidiaries...
Dell bought Alienware -- Alienware is still allowed to do its own thing, in a modular and self-contained way, but the self-contained entity known as Dell has wholly-encapsulated it (with a few "API" Alienware-branded touchpoints left exposed).

So now, most of the functionality of Alienware is still held by Alienware, still self-contained, still a revenue-engine...
...but it's owned and operated in a loosely-coupled fashion by Dell, who, themselves, are their own revenue-engine.

OpenGL isn't really an engine, because there's nothing particularly self-contained about it.
There are no well-defined inputs and outputs.
Consider it like Calculus -- something goes in, you know what's coming out.

A graphics engine might be one where the resource-management engine hands the graphics engine the textures, and the physics engine hands the graphics engine the transformed polygons, and then the graphics engine will make all of the magic happen, and can be loosely coupled through bolt-on/plug-in interfaces to work with OpenGL or OpenGL ES2.0 or DirectX or Canvas/JS or Flash/AS3 or a software renderer, based on switches, but without other graphics work happening externally.

Is it an engine? Sure. You've got well-defined inputs and outputs, you've got known quantities/properties for input (fuel) and you have expected results.

Wrapped inside of a game-engine, is a specific engine still an engine? Yes.

Do fans/journalists/etc get the distinction between Rage being an overarching game-engine, Havok being a physics engine and Euphoria being an AI+physics "natural and procedural animation" engine?

Not remotely.

Is it still an engine?
Yep.

Also: "game engines" aren't a requirement at all.
Pong is totally doable as a bunch of procedurally-called lines in Notepad.exe

But as complexity of game-code, as well as complexity of visual and state-managing (RPGs) expectations rose, engines made life better, whether they were physics engines, graphics engines, lighting engines, sound engines, combat engines, stat engines or just flat-out engine-configuring/running engines...