There is often alot of programming code which two completely different games may have in common: both carmageddon and tetris need to be able to draw things on screen, play sound, receive input from the user, etc.

Because game companies don't want to spend development time on making these systems every single time they start a new project this code is reused.

We call it an engine because it is the code that "makes the game run" - It's actually just programming code like the rest of the game.

Because it takes alot of time and effort to make an engine there are companies that specialize in their development, other companies then use their code to run their game.

A library is a similar collection of programming code which you can "attach" to your project. The directX library is a collection of code which 'talks' to the graphics card for you - it is possible to talk to the graphics card without this library but it would be much more difficult than just saying to directx "draw this for me".

It's far easier to just use the code somebody else has already written (this is what programmers mean when they say "don't reinvent the wheel").

Think of it like this:

You're making your own car.

The body of the car is your game: you can make it look like a blue volkswagen, a green porche, anything you like.

The thing that makes the car move is the engine (hence the term) - you can make your own engine but it probably won't run as well as one you buy from the garage.

You can make your car with engine X or engine Y, that's up to you. The body of the car will look the same - it might not be as fast though.

The library would be something like a new CD player you install in the car, just a little piece of programming which is ready made for you.

You don't need to know how a CD is played - all you need to do is insert the disk and press play.

Relevant link: http://www.extremetech.com/computing/50938-game-engine-anatomy-101-part-i

I actually look at 4 major areas useful for a modern, rasterized game to play thru a computer to your screen, all containing libraries of coding.

1) System - includes hardware and a Runtime Environment working with the Operating System (one of several major Runtime Environments which may come with the computer from the factory or be installed later, several actually being allowed and installed in the same client) The Runtime Environment includes the lower level coding needed in the form of various libraries with interfaces or even Software Development Kits (SDK) to develop applications and software which will run with machines using that particular version of that OS or made for any system which has that particular Runtime Environment version or earlier version installed. If that is confusing, then just remember that the Runtime Environment comes with (or allows third party tools to create) coding which is expected to be fully compatible with that Runtime or earlier version which is installed. It gives libraries of lower level coding to provide the APIs, compilers, and various other tools for all levels of coding to be read implemented in the computer. (Note: some higher level and lower level coding tools are included but more of general tools for nuts and bolts programming, created "from scratch" applications and software which are original from top to bottom. These all either come with the Runtime or are made for it, many no cost and can be downloaded. Highly skilled coding and experience is needed usually to make large applications and software here, sometimes requiring a team.)

2) Development Framework - such as SDKs, IDEs (Visual Studio, MonoDevelop, Java IDE, etc.), or game engines (In order of size, complexity, and generalization: 1)IDEs 2)Game Engines 3)SDKs). These are all various sizes of framework which provide the ability to create applications and software targeting a specific Runtime Environment in most cases, though sometimes as in the case Java Runtime Environment or Mono they can be cross-platform with some time spent in testing and debugging. These three categories of framework provide more of the coding already complete such as UI interfaces, default sounds, access to lower level graphics APIs (OpenGL or Direct3D), input interfaces-device, voice command, or other inputs, configuration interfaces, compilers/ de-compilers, and so forth. So these frameworks all are more specific toward goals than the tools in the previous system based Runtime Environments and frameworks include libraries made for certain genres of development. There is less work in making custom made tools and applications within the software in terms of coding with one of these dedicated frameworks, being that a huge collection of standard libraries come with the framework to add to those of the Runtime Environment. Often the developer can do relatively little or no lower level coding with a framework, freeing them to spend more time on end-user features.

3) Default libraries - may be GUIs, templates (including games in some cases which come with a game engine as a building foundation for you), specialized tools ( such as terrain editors, effects editors, and so on ), actual ingame assets (such as models, effects, sounds, et cetera), and the like.

4) Third party libraries - can include any additions to the above items which are original creations: plug-ins (external connected libraries), add-ons (attached libraries), and patches (internal libraries).

That's a decent summary and over-simplification, but you get the idea now.

Clinton

And here I thought this would be a SQL thread :P

SQL is only one area of the game dev jungle, so choose your path wisely.

Enjoy!

Clinton

The term "engine" is perhaps a bit overused in game development. Typically it is just a collection of other separate libraries (i.e OpenGL, glm, OpenAL, SDL, libpng etc...) with a bit of glue code to hold it all together as a framework (often including extra things like a scripting layer, serialization, etc...).

If you're new to gamedev I'd suggest a library like SDL or SFML if you're using C++, or a similar library in another language. They take care of the basics that you don't necessarily need to worry about like creating a window and abstracting away basic rendering and input, then you can worry about just making a framework for your game code and treat SDL/SFML as just a library.

Yeah, that's the whole strategic purpose of using a game engine or even a custom collection of the lesser abstract libraries. One way or another, the game developer will have to extend the framework which they chose by creating game source code (the game coding framework itself) upon which they make versions of game (version 1.0, 1.1, 2.0, 2.1, 2.5, 3.0, etc.). As the game developer becomes more sophisticated, then the need for Source Control or Version Control software increases, which is the efficient way of managing development and keeping documentation (a sort of map of the lay-out) so good coding doesn't get lost in the processes but reused as Game Source Code.

Clinton