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 is the difference between a game framework (e.g. 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? Can they be used mutually exclusively?

I take it there are separate engines for both 2D and 3D?

share|improve this question
up vote 17 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
This is a helpful distinction thanks. – Calum Murray Jul 6 '12 at 18:33
In my company someone designed a framework over the engine. this framework serves as a collection of missing parts the engine doesn't provide, unifies stuff that are otherwise a bit untidy in our (old) engine. And provides helpers to facilitate dev. – v.oddou Jan 5 '15 at 3:54

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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