Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

closed as not a real question by Kylotan, Tetrad Jan 4 '13 at 16:30

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

The way I see it is that a car's engine makes it go (in a nutshell). A game engine makes the game go. If all you need for your game is I/O, and the default libraries that you're working with provide the necessary I/O, I would consider the default libraries to be my engine. Probably not a truly accurate view, but it's a way of thinking about it. – Orin MacGregor Jan 3 '13 at 17:43
So if OpenGL is your "engine" then, how do you suppose people write their own "engines? People are not writing OpenGL, they are using its source and linking it into a program. – Andy Harglesis Jan 3 '13 at 18:42
It's like slapping a turbo on your engine. Don't build the turbo if one is available. Modify it if you need to, but don't build it from scratch. – Orin MacGregor Jan 3 '13 at 20:29
Life's too short for obsessing over questions of semantics. My advice: make games, instead. More fun and more rewarding. :) – Trevor Powell Jan 4 '13 at 4:16
This is hardly a real question, are you actually trying to solve a problem? faq – Tetrad Jan 4 '13 at 16:30

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

share|improve this answer
By "directly" I mean that yes, I used libraries, but is OpenGL an engine itself? I MEAN that software developers coin anything, such as a library on Windows to achieve rasterized images, a "game engine". Us that the correct terminology, saying ang library or SDK is your "engine"? If so, how are people "building" their owb engines? That would be insane to write your own library like OpenGL. – Andy Harglesis Jan 3 '13 at 18:39
I wouldn't call OpenGL an engine, personally, and I don't think many would. Other than the actual interface to the hardware (the drivers), writing something like OpenGL -- a 3D graphics pipeline and rasterizer -- is not actually that complicated (but that's another subject entirely). – Josh Petrie Jan 3 '13 at 18:40
There isn't really any "correct" terminology, that's sort of the point I was trying to make. – Josh Petrie Jan 3 '13 at 18:42
But isn't OpenGL a wrapper to OS APIs? And software developers use OpenGL calls and a language to build ab engine then. – Andy Harglesis Jan 3 '13 at 18:45
@AndyHarglesis not OS APIs; at least not on Windows or Linux. It's an API implemented by drivers, which are run by the OS. There are also fallback implementations (software rendering), which are provided by the OS, but they are also provided as a driver. OTOH, I don't know the architecture of mobile devices, so... – Liosan Jan 3 '13 at 20:18

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?

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

share|improve this answer
So you really don't need an engine ever then, so as code can work without it, it is not magic, in fact, it makes the job easier(sometimes too easy). – Andy Harglesis Jan 4 '13 at 1:24
@AndyHarglesis: No, he's saying that the term "engine" is so poorly used that it has no definition. You could claim that anything is an engine. In short, stop worrying about it. Just write your code, using whatever tools make that easier for you. – Nicol Bolas Jan 4 '13 at 1:52
@NicolBolas Pretty much. Engines can contain other engines, and other engines can contain other engines... If you're looking for that much encapsulation, then writing or reusing other engines is a great thing. If you aren't, then don't. Regardless of being Object-Oriented, or Entity-Systems or Functional, an engine can save you time, or cause you headaches -- if it does what you want, write/use it, and if it doesn't, don't. The term gets thrown around so often that even engineers aren't sure what "engine" means, without somebody specifying what the engine is meant to DO. – Norguard Jan 4 '13 at 7:00
And that's the point of an engine -- to take one kind of input, do one kind of work (or specific kinds of work) and output a specific kind of result (like putting gas in a combustion engine to get mechanical-force: newtons as torque, HP, RPM, etc). Do most people have any idea what they mean when they're talking about a car engine? They think they get it -- fuel goes in, explosions push pistons and wheels move... But it's a black-box. Asking a journalist about differences in game engines is like asking your friends' sisters about fixing car engines -- one might know. Maybe. – Norguard Jan 4 '13 at 7:06
I don't like when things are too "easy" for me. – Andy Harglesis Jan 5 '13 at 22:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.