Ok yes this is a stupid question and have read similiar questions but for some reason the answers they got just havent made sense to me. So if
someone would like to help me out I just have this one simple question: What is a Game Engine? Please be precise and explain exactly what it is.
Thanks in advance!
1
10 replies to this topic
Ad:
#2 Members - Reputation: 240
Posted 05 September 2012 - 08:55 PM
A game engine is, in general terms, the reusable portion of a game. For example, this would be the code for rendering a model, playing sound, for physics interactions, etc. Some of them are loose-knit functions that people have just put together over the years, others are designed from the beginning.
If you want fast results, then a game engine is for you. If you want to learn and learn every single piece of programming a game, then they are probably not.
If you want fast results, then a game engine is for you. If you want to learn and learn every single piece of programming a game, then they are probably not.
Looking for paid or open-source C++ programming work. Been programming since 2005. No degree.
#3 Marketplace Seller - Reputation: 8925
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.
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.
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.
Edited by Servant of the Lord, 05 September 2012 - 09:56 PM.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal
#4 Members - Reputation: 211
Posted 06 September 2012 - 04:28 AM
In short , a game engine is a set of tools that allow you to craft a game using those tools provided.
It makes more sense when you actually make a small game, and then another small game... you can take a few things from your first game and use them in the second game... in C++ and SDL that would be your initiating SDL functions, blitting functions, loading art functions, probably your text functions... stuff that doesnt change that much and each game can use.
The more games you make the more 'tools' (tricks, techniques, methods) you aquire and the more you put into your next game... eventually you have a nice set of tools.
A Game Engine allows you to bypass that building up of your tool collection and presents you with the tools (but you do now have to learn how to use the tools as you didnt aquire them normally).
A Game Engine is usually coded in a more robust manner concentrating on ensuring the interfaces provide only the actions that were intended, and not allow for unintended calls... proper encapsulation, whereas most beginner coders are more concerned with getting damn thing to run and dont worry if someone else uses the code.
It makes more sense when you actually make a small game, and then another small game... you can take a few things from your first game and use them in the second game... in C++ and SDL that would be your initiating SDL functions, blitting functions, loading art functions, probably your text functions... stuff that doesnt change that much and each game can use.
The more games you make the more 'tools' (tricks, techniques, methods) you aquire and the more you put into your next game... eventually you have a nice set of tools.
A Game Engine allows you to bypass that building up of your tool collection and presents you with the tools (but you do now have to learn how to use the tools as you didnt aquire them normally).
A Game Engine is usually coded in a more robust manner concentrating on ensuring the interfaces provide only the actions that were intended, and not allow for unintended calls... proper encapsulation, whereas most beginner coders are more concerned with getting damn thing to run and dont worry if someone else uses the code.
#5 Members - Reputation: 422
Posted 06 September 2012 - 05:44 AM
I believe that the actual term 'game engine' was coined by id Software back during development of their game Wolfenstein 3D. They didn't know what to refer to the game program itself, so they just called the code that compiled into the game exe the 'engine'.
Games (more often than not) consist of a variety of media, eg: audio, graphics, models, etc. The game 'engine' is what coordinates grabbing user input, and creating the actual game experience itself via the screen and speakers. This does not require anything other than creating an interactive experience through the use of programming.
Games (more often than not) consist of a variety of media, eg: audio, graphics, models, etc. The game 'engine' is what coordinates grabbing user input, and creating the actual game experience itself via the screen and speakers. This does not require anything other than creating an interactive experience through the use of programming.
#6 Members - Reputation: 1052
Posted 06 September 2012 - 06:40 AM
The game engine is a mysterious temptress that seems to capture the gaze of newcomers, entrancing and enticing them with whispers of technical titillation and bittersweet promises to reveal more earthly knowledge in the flesh than meets the eye.
However, once in it's embrace, this fell creature injects an insidious venom into it's unsuspecting prey, paralysing them with horrors of architectural decisions and designs that lie far beyond the reach and comprehension of mere newbies. With it's victim doubled over in pain, crying out to veterans to help slay this fearsome beast, it mockingly laughs, triumphantly declaring "Where is your game now?".
However, once in it's embrace, this fell creature injects an insidious venom into it's unsuspecting prey, paralysing them with horrors of architectural decisions and designs that lie far beyond the reach and comprehension of mere newbies. With it's victim doubled over in pain, crying out to veterans to help slay this fearsome beast, it mockingly laughs, triumphantly declaring "Where is your game now?".
#7 Members - Reputation: 900
Posted 06 September 2012 - 08:13 AM
This link is a good start:
http://en.wikipedia.org/wiki/Game_engine
Afterwards you should try play around with one:
http://www.unrealengine.com/udk/downloads/
http://www.garagegames.com/products/torque-3d (click on demo download)
http://unity3d.com/unity/download/
All three about is free to try out and the last one comes with a free version. You can read all you want about what an engine is but their is really only two ways to find out what a game engine is and that is to one: make a small game from the scratch(a small engine) or two try out a game engine already done and ready for use.
Most engines wont do you any good unless you have some basic programming skills as scripting is a pretty common way of making them do what you want. The world editors are more point and click though.
Have fun
http://en.wikipedia.org/wiki/Game_engine
Afterwards you should try play around with one:
http://www.unrealengine.com/udk/downloads/
http://www.garagegames.com/products/torque-3d (click on demo download)
http://unity3d.com/unity/download/
All three about is free to try out and the last one comes with a free version. You can read all you want about what an engine is but their is really only two ways to find out what a game engine is and that is to one: make a small game from the scratch(a small engine) or two try out a game engine already done and ready for use.
Most engines wont do you any good unless you have some basic programming skills as scripting is a pretty common way of making them do what you want. The world editors are more point and click though.
Have fun
"The only thing that interferes with my learning is my education"
Albert Einstein
"It is a miracle that curiosity survives formal education"
Albert Einstein
#8 Crossbones+ - Reputation: 743
Posted 06 September 2012 - 03:36 PM
There is a broad spectrum to the definition and what exactly the line is between an engine and the game itself. To put it in layman's terms, an engine is the software that turns the basic instructions a CPU and GPU and audio hardware are physically built to do into a platform that a creative person can use to make a game. It is just the same as any other software (input data, process, output data), but it's output is data in a different format, an interactive multimedia experience.
"The only thing stopping you from what you want in the future is what you want right now." - Zig Ziglar
#9 Members - Reputation: 378
Posted 06 September 2012 - 05:53 PM
This is actually a really interesting question.
I kinda feel that game engines are now a little bit deprecated. For example we no longer need a large monolithic "thing" to control our games logic.
If we say split our example game's core tech up into the libraries used. e.g...
OpenGL (graphics)
OpenAL (sound)
Glut (OS/Graphics binding layer)
ODE (physics collision)
Lua (entity scripting)
Would all of the above class as an engine?
Lets say I created a very small hierarchical entity management system to add objects and screens to the world easily... Would this very small bit be the engine and the other stuff be kinda like the plugins? Or maybe the shader manager defines an engine? This afterall, is generally where I spend the most lines of code.
Perhaps in the days of Quake 1 when there wasn't really the OpenGL or DirectX there is today, an "engine" had much more of a meaning. Now, games development is often more about integrating other libraries suited best to their role. An engine would be a limitation since it would get in the way if I wanted to use an alternative sound system for example..
I kinda feel that game engines are now a little bit deprecated. For example we no longer need a large monolithic "thing" to control our games logic.
If we say split our example game's core tech up into the libraries used. e.g...
OpenGL (graphics)
OpenAL (sound)
Glut (OS/Graphics binding layer)
ODE (physics collision)
Lua (entity scripting)
Would all of the above class as an engine?
Lets say I created a very small hierarchical entity management system to add objects and screens to the world easily... Would this very small bit be the engine and the other stuff be kinda like the plugins? Or maybe the shader manager defines an engine? This afterall, is generally where I spend the most lines of code.
Perhaps in the days of Quake 1 when there wasn't really the OpenGL or DirectX there is today, an "engine" had much more of a meaning. Now, games development is often more about integrating other libraries suited best to their role. An engine would be a limitation since it would get in the way if I wanted to use an alternative sound system for example..
Edited by Karsten_, 06 September 2012 - 05:57 PM.
#10 Members - Reputation: 106
Posted 07 September 2012 - 02:08 AM
Game engine is a "basis" of the game. There is a "game" code, for examle characters behaviour, quest system, vehicle physical parameters etc. And an "engine" code that does not corrspond to particular game, it is a character animation system, sound player, resource system, scripting engine, physical engine, shader system etc.
You can share engine code between different games, but game code is unique for concrete game.
You can share engine code between different games, but game code is unique for concrete game.
