I have started explaining how a game is designed in layers to a friend of mine. I want to make sure that I explained things, correctly, so I wanted to verify my thoughts.

Basically, the way I understand it, games are designed with the following layers, in the following order:

  1. Rendering Engine
  2. Physics Engine
  3. Game Engine
  4. Scripted Game

Is this correct? Am I explaining this right?

  • 1
    \$\begingroup\$ That seems to be a totally arbitrary way to layer things. It's also unclear what kind of game you're talking about. Some games require a lot more (or other) libraries/subsystems/engines, while others require even less... \$\endgroup\$ – bummzack May 1 '12 at 19:01

Everytime someone uses the word "engine" in relation to a component of a game, the word loses a little meaning. The term was invented in the Doom days; imagine how much meaning it has left.

Right. Not much.

"Game engine" used to have a well-defined meaning. Nowadays, "engine" is just an overblown synonym for "library" or "module".

The "Rendering engine" is nothing more than that part of a codebase which is told where to draw stuff, and that stuff gets drawn there. The "Rendering engine," in a well-architected game (hard to come by, I know) has no knowledge of who tells it what to render or where to render it. All it cares about is doing the rendering.

The "Physics engine" is again simply the part of the codebase that decides how things move around and whether they collide. It should not know or care how this information is conveyed to the user. A well-architected physics engine should not have any particular dependencies on the rendering engine, or even know that it's feeding a rendering engine. It just moves stuff around.

The "Game engine" is a concept so nebulous as to be non-existent.

A "Scripted game" (one of these things is not like the other) is a game that has scripts that control some aspect of it. Which aspects is up to the game developer. Some games expose the renderer directly to the script, thus coding most of the game in the script. Others only expose basic things like the ability to spawn entities at fixed, predefined locations to scripts. Most are inbetween. Obviously, some don't even have scripting to begin with.

Ultimately, none of these modules needs to have any relationship to one another. They can be said to be hierarchically composited, but none of them needs to know that the other exists in order to do their jobs.

  • \$\begingroup\$ yeah. pretty much this. \$\endgroup\$ – Toni May 1 '12 at 10:08
  • \$\begingroup\$ To be fair, the OP never mentioned "Scripting engine" - it says "Scripted Game". But I agree with you. \$\endgroup\$ – Oskar N. May 1 '12 at 20:00
  • \$\begingroup\$ @OskarN.: Fixed. \$\endgroup\$ – Nicol Bolas May 1 '12 at 20:14
  • \$\begingroup\$ I disagree that "Game Engine" is too nebulous or vague to be considered a component of a game. I've always known it as the encompassing executable that runs the game (hence "engine"). This all ties into data-oriented design for games, or having the core of a game (rendering, sound, script interpretation) independent of the actual game logic (I click here to kill X person). Look at the UDK for a modern example. \$\endgroup\$ – Alex Shepard May 3 '12 at 3:28

This screen from Game Engine Architecture (ISBN 1568814135) provides a pretty good overview on what components you may find in a typical game engine.

  • \$\begingroup\$ I like these images because they illustrate how many subsystems a finished game can actually contain. Sadly your answer would immediately lose all of its value as soon as these links go down.. adding the Title and ISBN of the book you're quoting would certainly improve the quality of your answer (hint hint) ;) \$\endgroup\$ – bummzack May 1 '12 at 18:58
  • \$\begingroup\$ @bummzack Point taken :) \$\endgroup\$ – Oskar N. May 1 '12 at 19:46

I'm not sure you can explain it in terms of layers. A game engine has a lot of components, some of which you mentioned, but they are interconnected in several ways.

First of all, #3 in the list is pretty meaningless I think.

Second, Rendering and Physics may or may not be directly connected (most of the time the renderer depends at least a little bit on physics for object placement, etc.), and they may or may not be controlled by a custom scene manager. This also involves controlling the scripted entities.

I would say the components are equals that act mostly independently but can access each other's data if they need to.


Well, not quite. The process is not necessarily so linear, and what you have listed here is mainly what is required from programmers.

Depending on requirements, some of these things are not necessarily needed. Rendering engine is needed for 2d or 3d games, but for games that only rely on sound or some peripheral device output or such it might not be needed. Physics is not necessary for a broad range of games. Game engine is something that sits on top of the architecture and is compiled. Scripting is not absolutely necessary for games, and most games do not have any scripting support. Scripting is to avoid having to recompile on every small change, which will help, but for smaller games the compilation times may be so negligible that it doesn't matter.

The order in which these are built not necessarily strict. But since "Game engine" is essentially on top of the structure, it is beneficial to have the interfaces of the graphics engine and physics engine consistent during the development. Usually you would use existing solutions for graphics and physics, because the available solutions are generic enough, usable and robust and it saves a lot of time.

What you have ignored to mention here is that you need a lot of assets created too. Sounds, music, models, textures, maps, items, etc. depending on game.


Not really layers, more like parts.

There is part that deals with drawing to the screen. Another part deals with collisions. Another part deals with physics, that is, how objects get moved around in the game. Another part deals with sound and music. Another part deals with input. Another part deals with in game events. Then there is the part that contains all of the actual game content; IE the enemies, items, whatever that makes the game. You could have another part solely dedicated to AI.

All of these parts have jobs to do. Ideally, they don't care who is talking to them. All they care about is doing their job. They get something, process it, then spit something out. They don't care who sent it to them or where its going. All they care about is their job.

A game engine could be considered all the parts that are not the game content. The game content would be the assets specifically unique to a particular game; the art files, sound files, music files, and code files that get processed by the other parts into output on the screen. They are two halves of a whole.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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