Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
What is the difference between a game framework (for example, XNA with C#, SDL for c++) and a game engine?
Do game frameworks use engines? Does a game engine encapsulate sub-engines like physics engines, particle engines etc? Should they be used together, or are they mutually exclusively?
I take it there are separate engines for both 2D and 3D?
There really aren't strict definitions for "engine" or "framework."
Generally speaking, an engine is considered to "do more" or have more tools and related support than a framework, which is itself is often just a loose collection of related functionality exposed through some unified API.
To that end, things that claim to be engines may use things that claim to be frameworks to achieve functionality, but that does not always need to be the case. Similarly, a thing claiming to be a game engine can claim that it's constituent parts (the physics and rendering, et cetera) are implemented with a physics engine or a physics framework. The kinds of technology referred by both terms can be used interchangeably, or not.
There can be "engines" or "frameworks" for just about anything -- physics, sound, and yes, even 2D or 3D graphics.
It's really just a terminology issue, and it doesn't generally matter much. From a functionality perspective, a perspective focused on making your game, what should matter is whether or not the technology in question delivers what you need to make your game. Whether it calls itself an engine or a framework won't have any bearing on that.
Simple definition that I use: you can build an engine on a framework but you would never build a framework on an engine. One is the skeleton that determines architecture and program flow, the other is muscle that does the work.
For a concrete example, Artemis is a neat little framework for building component systems but you'd never call it an engine. You could build Artemis Systems and standard components to create an engine from it.
For a realy detailed explanation I recommend reading the one and only bible Game Engine Architecture by Jason Gregory. I guess it is the most complete work about this topic since it was published. It does not only handle the C++ part but also and important for every game engine programmer the theory/architecture behind. It's a good starting point independent of the language. To get an overview what we are talking about is this image from the book
Let me give it a try to answer the question.
Whatever you write it will be code :-) after years of experience, write what you need and how you need it or use what provides you what you need.
The terms engine and framework come from software architecture along with other terms. So let's start with the basic terms und lets move upwards.
Library
Typical examples: a math library providing all the basic types and functions for mathematical calculations (Vector, Matrix,...) or image (jpeg or png) library providing the functionality for writing jpeg or png images
In Unity 3D Math is a math libray.
Theory: a libray provides dedicated features around a topic (e.g. math) AND is called by the programmer on demand.
Some preview: there can be libraries holding frameworks aka being a framework library.
Framework
Theory: A framework introduces an inversion of control. This means the developer most of the time does not call the framework methods but the framework calls the code of the developer. Exceptions are when you have to integrate the framework library in your code and have to start the framework. A framework library provides all methods and functions and interfaces for a framework with a dedicated usage. So frameworks can be in a library.
Typical example: The Unity 3D MonoBehaviour provides methods like Awake, Start, OnUpdate. The developer implements these methods and then these methods get called by the (game object management) framework (this is the inversion of control). The same with the methods OnCollisionEnter, OnCollisionExit. They are in the same Monobehaviour but I would bet they are called by the physics framework.
An preview: Engine, Runtime, Editor, SDK
Since the term engine was always kind of vague and still is (and it does not become better with further technological developments) some preview explanation.
The term engine is used for multiple things and it can not be uniquely said which one is right. Back in 2004 when I first had contact with writing game engines it was vague too. You had a game engine in the meaning of some sort of code loading predefined data and let you play the game. Since it loads predefined data they were called data-driven engines. You compile them once and the external data could have been different games without recompiling it. At some point of time this was the same like a runtime.
The editor is clear. It lets you define the predefined data loaded by the engine/runtime.
An engine with an editor was called SDK (e.g. Hammer SDK).
Then there were/are dedicated engines. A phyiscs engine, rendering engine, sound engine, gameobject management engine, network engine,....
In my personal opinion those are not engines (especially a render engine IS NOT a game engine since it does only rendering). When I google game engine the results contain 90% pure render engines which are not game engines. I would call all of them libraries but since they may load predefined data they would match the term data-driven engine.
A last short side note before we get into details: I successfully graduated with a masters degree in computer science. My master thesis handled the topic "how to develop the core of a game engine". Meaning the part of the code which clues together all the other engines, does the game object management, the game loop, etc...
I published my master thesis as a (short) book. The only comment on Amazon from a buyer/reader is (after a few years out): this is not about a game engine. Since I graduated successfully and therefore have defended my thesis against 3 experienced programmers (2 of them dedicated to games and interactive applications) I guess I have written a game engine.
Editor
Easy: lets you define the data in the format the other parts require them and therefore eliminates the demand to write those files by hand or use external tools to create them.
This is what the Unity 3D editor does.
Runtime
This term is often used equally with engine (which can be correct or incorrect).
The runtime executes the generated data and does what it has to do with the data. E.g show you the game and let you play the game. It does not create any data (except maybe save games) in the meaning you can't modify the game itself withit.
The Unity Web Player is/was a runtime let you play Unity games within a webbrowser.
You can load and execute multiple different games with the same runtime.
In the case of the Unity 3D scripting API there is a cut between functionality that will work in the game and functionality that will only work within the editor.
SDK
This term is often also called framework.
Back then an SDK has been a bundle of tools like an editor, IDE (integrated developer environment) for programmers, exporters for dataformats and the runtime/engine.
So an SDK/framework provides you with a predefined workflow and utilities and shows you a (well designed) way how you can (easily) create a game.
Basically Unity 3D engine would be wrong since it would fit more into the SDK direction. But since Unity is even more a new word/definition is needed to match what it is.
Anyway, to introduce the other term, an SDK/framework provides you a predefined game development pipeline (not only a asset pipeline but maybe, like Unity, a pipeline for assets, logic, builds, deployments,....)
Engine
sarcasm on Used for everything since everybody wants to be cool by writing not only a library, a framework or a game but better writing a complete engine.sarcasm off
Let's trigger it down:
An engine
A engine can consist of multipe other engines (since everything is called an engine nowadays). A game engine can include
An example for an application based on a core engine providing a plug-in based framework for cluing everything together in a component based game object management model. Each subengine (rendering audio) is a module added to the game engine as plug in. Each component can be part of a subengine/module. And the (component based) game object management is the connecting link between the seperated modules.
The closest definiton for Game Engine
A game engine is the part of the source code of your game that provides all the functionality which is intended to be reused accross multiple games and let you code and execute your game. Therefore it clues together all the other parts of the code (rendering, audio, physics, game object management, networking) which are either libraries, frameworks or dedicated engines (rendering, physics,...).
The game engine is the mess in the middle.
A framework is a collection of (usually) lower level libraries and helper stuff that you can use to do whatever the hell you want (graphics, sounds, etc.). There is nothing game-related about a framework except they're usually optimized or designed to do things that are common in games.
Example: an engine allows you to have a list of entities, each with a position on the map. A framework allows you to render a 3d object at a certain position.
So you connect them by giving each of your entities a 3d object, and render them when needed.
And ta-da, you have a game.
As @Josh already stated, there's no strict definition of framework or engine but, in a conceptual sense, both are very different tools.
A framework contains a basic API abastraction to work with, giving the user higer level tools to interact with the platform or the functionality without (generaly) worrying about performance, compatibility, etc. In the examples you gave, SDL is a framework, it gives you abstarction over the platform, and you can build your software behind that layer without worring about window management, OS specific stuff, etc. If you want to build a whole software, you are going to need diferent frameworks, f.e SDL to manage the media and platform stuff, Box2D to manage physics, etc.
An engine is different, in this case, the tool ships everything needed for the development, a physics engine will provide you with everything needed to manage physics and will ship an easy to use API, so, if you want to build a physics simulation you wont need any other third party library. Engines are no more than a collection of frameworks, other engines, interfaces, snippets and general code who provides everything needed to complete the project without needing other 3rd parties nor worring about lower level stuff.
