A game engine is a piece of software that is used by developers in order to create video games. Previously, all games were created from scratch each time, requiring a rewrite of the same kind of code for displaying the graphics, accepting input, processing sound, managing gameplay elements, AI, etc. This was especially aggravating when creating games similar to each other since that would mean writing very similar code over and over again. Furthermore, before game engines, creating and designing content using assets was often-times hardcoded which meant most level design was done by programmers who typically have a poor track record for being particularly artistically minded.
Of course, after a while of doing this, some bright sparks had the idea of creating a stable base, which contained all these non-specific game elements from which games could then be created from.
Nowadays game engines are often created in house for the specific needs of the company and the kind of games they create. Despite the frequent specialisation of company's towards certain genres and types of games, the engines themselves are designed to be quite generalised. This is due to a few factors, including the rapidly changing desires of the market and also the possibility of selling licenses to other companies. Epic is the most obvious example of this. Creators of the Unreal Engine, Epic frequently sells the right to use the engine for other companies to use for their own games, from which Epic takes a cut of the sales. This has provesd quite lucrative and most games released by Epic are closer to tech demos and advertisements of the capabilities of their engine than actual commercial ventures in and of themselves.
But I digress, because first we should discuss what the engine does.
The most noticeable thing that a game engine handles, from a consumers point of view, is the graphics rendering. This is done in real-time (meaning every second thirty frames are rendered) because of the interactive nature of video games. This means games engines have be fast.
The next part the game engine handles is the player input, from a mouse, keyboard, controller, joystick etc, etc. This is what allows the person in front of the screen change what is happening behind the screen.
After receiving input the game engine has to simulate everything in the background. This includes AI, physics, triggers, event, loading and unloading and changing variables. In simpler games the game simulates these things every frame. However, for more complicated games this would cause massive amounts of slowdown, lowering the frame rate and making it an unejoyable experience. As such, many game run the simulation at fixed intervals and the engine then interpolated between the two simulation snapshots, displaying this interpolated information through the graphics. Of course this comes with its own set of problems such as AI not updating to new stimuli often enough or physics being inaccurate but for the most part this method works well.
AI is "artificial intelligence", a routine in the game program as a whole that controls nonplayer characters and allows them to make decisions. It often determines where the AI can and will move (with the aid of path nodes or a Names) and when it will take certain actions.
Physics are a part of the simulation that tries to mimic the natural movement of objects due to unscripted forces. There are actually pieces of middleware such as Havok that is "plugged in" to the engine and handles the physics itself without the programmers having to write an entire physics engine from scratch. Physics also handle any of the collision of a game, making objects solid and preventing the player from running through walls or falling through the floor.
Loading and unloading is part of the optimisation that game engines make so that the the designers can create larger and more detailed levels without massively increasing the computing requirements. Another part of this optimisation is back-face culling. The facing of a polygon is determined by the order in which it's points are defined and so anything that is designated as a "back-face" is not rendered at all saving massive amounts of computational power. A similar idea to this is called occlusion culling in which the game engines determines what the player can and can't see and then doesn't render anything that can't be seen.
The most noticeable thing that a game engine handles, from a consumers point of view, is the graphics rendering. This is done in real-time (meaning every second thirty frames are rendered) because of the interactive nature of video games. This means games engines have be fast.
The next part the game engine handles is the player input, from a mouse, keyboard, controller, joystick etc, etc. This is what allows the person in front of the screen change what is happening behind the screen.
After receiving input the game engine has to simulate everything in the background. This includes AI, physics, triggers, event, loading and unloading and changing variables. In simpler games the game simulates these things every frame. However, for more complicated games this would cause massive amounts of slowdown, lowering the frame rate and making it an unejoyable experience. As such, many game run the simulation at fixed intervals and the engine then interpolated between the two simulation snapshots, displaying this interpolated information through the graphics. Of course this comes with its own set of problems such as AI not updating to new stimuli often enough or physics being inaccurate but for the most part this method works well.
AI is "artificial intelligence", a routine in the game program as a whole that controls nonplayer characters and allows them to make decisions. It often determines where the AI can and will move (with the aid of path nodes or a Names) and when it will take certain actions.
Physics are a part of the simulation that tries to mimic the natural movement of objects due to unscripted forces. There are actually pieces of middleware such as Havok that is "plugged in" to the engine and handles the physics itself without the programmers having to write an entire physics engine from scratch. Physics also handle any of the collision of a game, making objects solid and preventing the player from running through walls or falling through the floor.
Loading and unloading is part of the optimisation that game engines make so that the the designers can create larger and more detailed levels without massively increasing the computing requirements. Another part of this optimisation is back-face culling. The facing of a polygon is determined by the order in which it's points are defined and so anything that is designated as a "back-face" is not rendered at all saving massive amounts of computational power. A similar idea to this is called occlusion culling in which the game engines determines what the player can and can't see and then doesn't render anything that can't be seen.
Once all these simulations have finished or the game has determined the where everything is on screen through interpolation, the game renders the graphics, processes the sound and displays the output to the player, ready and waiting for more input.
Of course some game engines do more or less than these things and different aspects are emphasised or removed depending on what the engine will be used for.
Of course some game engines do more or less than these things and different aspects are emphasised or removed depending on what the engine will be used for.
An important thing to note is two distinct types of game engines. Again, of course there are more and different combinations of styles of engines can be made. But for now, an part of designing a game engine is deciding on its dimensionality: should it be 2d or 3d. The difference between the two is, in a way, small. A 3 dimensional game simply as an extra coordinate, z. There are.things that are affected by this change but for the most part that is the difference between those two types.
