Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualServant of the Lord

Posted 05 September 2012 - 09:56 PM

There is no hard and fast definition, so many people use the same words to mean different (but similiar) things. Here's my opinion:

Code at it's lowest level is very general. You build layers and layers of code to hone in on what you specifically want to do. The more layers you add, you (ideally) get more specific towards one field or problem domain.

A library is a set of code that abstracts certain tasks to make it easier to do that task. A library could just be a collection of functions and classes, or it could be an actual lib/dll/so/module file.
(An API is another name for a library or set of libraries)

In my opinion, an engine is a collection of libraries (and tools) abstracted to the point where they start handling and abstracting logic and interaction, and not just data and algorithms.

A game engine is a collection of engines that usually contains some or most of these:
- Physics engine
- Rendering (2D or 3D) engine
- Input handling
- Messaging system
- GUI system
- Resource system (loading, saving, and lifetime management)
- Networking system
- Scripting system

If you replace the word "system" and the word "engine" in the list above with 'module', then it helps you further see the distinct collections (or libraries) of code, that are each individually "layer upon layer" of code abstracting specific problems to make them easier to use.

Not every layer of code actually is beneficial. Sometimes a layer of code is written that is too general, and doesn't actually help abstract the problem and hone it with a specific solution. The best library is the one that knows what kind of problem it is solving, and goes and solves it in a succinct and non-bloated way - otherwise it's just a renaming of the functions belonging to the layer under it.
Not every game engine does a good job of abstracting and honing in to solve the problem of the type of game you are making. Some just wrap a bunch of libraries, to provide a common interface, but don't actually abstract them any further.
A good game engine should be focused on a set category of games. Then a game engine should be built over that, that abstracts it for a specific genre of games. Then, a game engine should be built over that, that abstracts it for a specific sub-genre of games. Then, the game should be built over that, to abstract it to your game itself.

Sometimes multiple layers of abstractions are actually often compressed into one actual layer of code, because (from a lack of good engines perfectly tailored to our sub-genre) we have to go from a generalized engine for "3D Games" and leap over "First Person Action Game Engine" or "First Person RPG Engine" on the way to get directly to our game itself, and what we consider our game, actually contains (compressed into it) the sub-genre specific code and the genre-specific code that should (ideally) be abstracted as a layer between (or modules alongside) the general "Game Engine" and the game itself. Also, this abstraction process doesn't always have to be done in programming code - it can also be done through scripting languages, config files, and other data-driven methods - but it should be (again - ideally) mentally distinguished from other layers or modules, for better reuse.

 

Another way that I think of it, is that where "Libraries" abstract problems to provide solutions, thus narrowing and honing down more and more through layers. Game Engines are the layers that actually start compiling separate libraries back together to actually make the project. Layers of libraries reduce the options from the layers below it, to hone it on solutions (so each successive layer should be less general than the one below), but the game engines start expanding (while still honing in and getting less general) by compositing libraries together.

#1Servant of the Lord

Posted 05 September 2012 - 09:52 PM

There is no hard and fast definition, so many people use the same words to mean different (but similiar) things. Here's my opinion:

Code at it's lowest level is very general. You build layers and layers of code to hone in on what you specifically want to do. The more layers you add, you (ideally) get more specific towards one field or problem domain.

A library is a set of code that abstracts certain tasks to make it easier to do that task. A library could just be a collection of functions and classes, or it could be an actual lib/dll/so/module file.
(An API is another name for a library or set of libraries)

In my opinion, an engine is a collection of libraries (and tools) abstracted to the point where they start handling and abstracting logic and interaction, and not just data and algorithms.

A game engine is a collection of engines that usually contains some or most of these:
- Physics engine
- Rendering (2D or 3D) engine
- Input handling
- Messaging system
- GUI system
- Resource system (loading, saving, and lifetime management)
- Networking system
- Scripting system

If you replace the word "system" and the word "engine" in the list above with 'module', then it helps you further see the distinct collections (or libraries) of code, that are each individually "layer upon layer" of code abstracting specific problems to make them easier to use.

Not every layer of code actually is beneficial. Sometimes a layer of code is written that is too general, and doesn't actually help abstract the problem and hone it with a specific solution. The best library is the one that knows what kind of problem it is solving, and goes and solves it in a succinct and non-bloated way - otherwise it's just a renaming of the functions belonging to the layer under it.
Not every game engine does a good job of abstracting and honing in to solve the problem of the type of game you are making. Some just wrap a bunch of libraries, to provide a common interface, but don't actually abstract them any further.
A good game engine should be focused on a set category of games. Then a game engine should be built over that, that abstracts it for a specific genre of games. Then, a game engine should be built over that, that abstracts it for a specific sub-genre of games. Then, the game should be built over that, to abstract it to your game itself.

Sometimes multiple layers of abstractions are actually often compressed into one actual layer of code, because (from a lack of good engines perfectly tailored to our sub-genre) we have to go from a generalized engine for "3D Games" and leap over "First Person Action Game Engine" or "First Person RPG Engine" on the way to get directly to our game itself, and what we consider our game, actually contains (compressed into it) the sub-genre specific code and the genre-specific code that should (ideally) be abstracted as a layer between (or modules alongside) the general "Game Engine" and the game itself. Also, this abstraction process doesn't always have to be done in programming code - it can also be done through scripting languages, config files, and other data-driven methods - but it should be (again - ideally) mentally distinguished from other layers or modules, for better reuse.

PARTNERS