What exactly is a Game Engine?,
Members - Reputation: 436
Posted 05 September 2012 - 08:49 PM
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!
Members - Reputation: 1154
Posted 05 September 2012 - 08:55 PM
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.
Crossbones+ - Reputation: 33032
Posted 05 September 2012 - 09:52 PM
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.
It's perfectly fine to abbreviate my username to 'Servant' or 'SotL' rather than copy+pasting it all the time.
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 | [Fly with me on Twitter]
Members - Reputation: 212
Posted 06 September 2012 - 04:28 AM
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.
Prime Members - Reputation: 1611
Posted 06 September 2012 - 05:44 AM
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.
Crossbones+ - Reputation: 1263
Posted 06 September 2012 - 06:40 AM
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?".
Crossbones+ - Reputation: 2122
Posted 06 September 2012 - 08:13 AM
Afterwards you should try play around with one:
http://www.garagegames.com/products/torque-3d (click on demo 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.
"The only thing that interferes with my learning is my education"
"It is a miracle that curiosity survives formal education"
Crossbones+ - Reputation: 810
Posted 06 September 2012 - 03:36 PM
C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.
Members - Reputation: 2176
Posted 06 September 2012 - 05:53 PM
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...
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.
Members - Reputation: 106
Posted 07 September 2012 - 02:08 AM
You can share engine code between different games, but game code is unique for concrete game.