Tropes Media Browse Indexes Forums Videos Ask The Tropers Trope Finder Media Finder Trope Launch Pad Tech Wishlist Reviews Tools
Cut List New Edits Edit Reasons Launches Images List Crowner Activity Un-typed Pages Recent Page Type Changes Changelog
Tips
Creating New Redirects Cross Wicking Tips for Editing Text Formatting Rules Glossary Edit Reasons Handling Spoilers Word Cruft Administrivia FAQ
Tropes HQ
About Us Contact Us Advertise DMCA Notice Privacy Policy Report Bug
Go Ad-Free Changelog
  • Show Spoilers
  • Night Vision
  • Sticky Header
  • Highlight Links
 

Follow TV Tropes

Following

Media Notes / Game Engine

Go To

In order to understand what a game engine is, it is necessary to first understand what video games are made of.

Video games are composed of two things: code and data. Code is what makes a game function, and data is what makes it fun.

Take Super Mario Bros. as an example. The game's code defines the rules of the game: that Mario can jump; that Mario can run; how fast he runs; that there are monsters, some of which can be stomped on; etc. The game's data defines what Mario looks like, how he animates, and the arrangement of the terrain and placement of objects and monsters, which form levels. Through Game Mods, you can change the data of Super Mario Bros. and create a Mario-like game that replaces how Mario looks, and how the terrain, objects and monster in levels are laid out. Unless you change the code, however, said game will have certain mechanics completely identical to Super Mario Bros., such as:

In short, a game that has its data modified to become another game is still, at the very basic level, the source game.

A game engine is game code that is designed to be data-driven. Unlike the above example, a proper game engine would allow the behavior of in-world entities to be defined in almost every way through data. Virtually all games have some data component, but only relatively recently has this component become flexible enough that two games built from the same engine can be very different from each other. The game's data thus defines both the function and the fun, while the code is just there to make the data do its job.

In a game engine where most features are defined in the game data, the game engine would be expected to carry out functions such managing memory, I/O, rendering the graphics for output to a display, interpreting the game's scripting language if it exists, doing general number crunching to make the game work, and so on.

A scripting language is effectively data driven code, interpreted by the game engine. The functionality and complexity will vary between game engines, from extremely simple functions such as telling the game to spawn an enemy in or load a new map file when you reach a trigger point, to directing the game engine to achieve more complicated results which may not exist as part of the game's default sandbox, to at its fullest being a feature complete programming language itself, usually based on an existing programming language.

The general goals of a scripting language are to provide level designers with tools to produce the desired gameplay, without needing them to be full on programmers, and without needing to edit the game's source code. Scripting languages are usually kept to a minimum, since they must be interpreted when run, which results in much slower performance compared to the compiled game engine code.

One of the first cases of a true game engine was Quake. It was a first-person shooter, but the game engine was much more flexible. It did not even make the assumption that the game was first-person; a user of the engine could pull the camera away to a third-person perspective. And the main character would be rendered there in third person with all of the controls intact and functional. With some work, Quake could have run a game like Super Mario 64, all without directly changing the code of the engine.

Please note that this is a simplification of a complex topic, as the amount of data-driven code varies from engine to engine. More often than not, supplementary code must be written for a game engine to be customised as needed. For instance, the Source engine (which powers several Valve games, such as Half-Life 2) can be modified by loading additional DLL files, which are compiled C/C++ code. Even Quake mods, written in so-called "QuakeC" code, were compiled directly into virtual machine assembly code. The entire process can be made more complicated through the use of scripts, which are code that is loaded like data. In that case, a game engine is basically just a library or module that handles 80% of the grunt-work in making a game: collision detection, that things can move, rendering things, etc. It is then up to the user to add the 20% that makes the game unique, whether through data and code, or purely data.

Making all this even more complex is the selling of a license to use a game engine to a third party, with the transaction including the provision of the game engine's source code to said third party. This is how most commercially available game engines are sold—no developer worth their salt will build their game based solely on the engine-maker's assurance that the game engine is bug-free. The inclusion of the game engine's source code allows developers using the engine to actually change the engine code itself, not just layering new code on top of the existing engine, and developers frequently avail themselves of this opportunity. As such, a developer that claims to be using a certain game engine probably made some changes to it in the process of developing their game that runs on said engine.

The general rule of thumb is this: you know it's a game engine if you don't have to actually change the engine's source code to make a game that is substantially different from other games made with this engine. This said, some game engines were originally designed for very specific types of games, such as DICE's Frostbite engine for the Battlefield series, and this needed a lot of work to support different game types, such as the RPG Dragon Age: Inquisition. Other modern engines like Unity or Unreal are very flexible, though as mentioned above developers will usually customise the code for their specific requirements.

As a bonus, games that run on a game engine that emphasises more on data-driven code can be modified very easily, and games using the same engine are easy to port if other games using the same engine have already been ported.

Engines can be internal, restricted to a particular development company, or external, which can be licensed for use by others. In-house "engines" are really just common codebases that multiple development teams in a company share. It is impossible to know whether these truly fit the definition of "game engine" because the different teams modify the source code for their own needs. Unless an engine is external, it is difficult to know what you can do with it without modifying the source code.

It's also worth noting that as game development has evolved over the years, the number of in house engines has reduced in favor of commercially available game engines. One reason for this might be that as development costs continue to rise, using a well known engine like Unreal not only makes it easier to hire and onboard staff which keeps these costs down, but also saves a lot of time not needing to reinvent the wheel, since each game engine is generally trying to solve the same challenges and carry out similar functions.

Modern game engines come with built-in skyboxes, which are likely to be the first thing you see when you load up the development environment.

This may sound like a Game Maker, but there is a difference. A game maker is limited to a specific style within a genre. This limitation is what allows them to be easier to use. Nonetheless, a Game Maker is a superset of a Game Engine, as games created on a Game Maker will still need to run on something. Game engines cover a wide range of possible game types. Super Mario World level editing is effectively a Mario-style game maker—you can never make anything other than that kind of game.

External Game Engines:

  • Serious Engine by Croteam (named for Serious Sam):
  • Roblox is a game platform itself, but has its own engine in which you can create any kind of game of your own dreams on the platform (which means there'll usually be blocky characters as players) with the software Roblox Studio. It's 3D, but can be used to create 2D games with enough GUI code. Roblox started off as a simple Game Maker where you could build simple games with blocks, but it grew powerful over time.
  • The Robot Odyssey engine was also used in Think Quick!, Gertrude's Secrets and Rocky's Boots.
  • PhyreEngine, engine provided by Sony Computer Entertainment for developing PS3, PSP, PS Vita, and (assumedly) PS4 games. Version 3.70 was leaked to the internet so you too can learn what makes your favorite console games tick. Games built on this engine include: Hyperdimension Neptunia, Demon's Souls, Dark Souls, the Atelier Series from Rorona to Ayesha, Disgaea 4: A Promise Unforgotten, and Journey (2012). Support for targetting Microsoft's Xbox 360 and Xbox One, Android, iOS, Nintendo Switch and even Windows was later added to the game engine, allowing games written on the engine to be easily ported to and from Sony's platform.
  • For fans of MUDs and MUCKs, there are a plethora of different engines upon which one can build - and with enough work in scripting, one can even turn a MUCK into a MUD.
  • Clickteam Fusion, formerly known as Multimedia Fusion, formerly known as The Games Factory, formerly known as Klik & Play, developed by French studio Clickteam. The bulk of the "programming" is done in the Event Screen for each level, which puts individual conditions into rows, and applies them to gameplay aspects and objects which have columns. The later iterations' functionality can be enhanced with various downloadable plug-ins. Games created with it include I Wanna Be the Guynote , Freedom Planet, The Angry Video Game Nerd Adventures, Wings of Vi and the Five Nights at Freddy's series.
  • Godot Engine, originally an internal engine created and used by the Argentinian developer Okam Studio, released under the MIT license in early 2014. Notable games created with it include the iOS version of Deponia, Tanks of Freedom, Cruelty Squad, Kingdoms of the Dump, EX Zodiac, Your Only Move Is Hustle, Brotato, Cassette Beasts, and Sonic Colors Ultimate, as well as Okam Studio's entire game library.
  • The Retro Engine by Christian "The Taxman" Whitehead is a game engine he developed while creating his own Sonic the Hedgehog fangame, Retro Sonic, which was based on the original Genesis Sonic the Hedgehog games and was notable for its accuracy towards those games instead of being a mod or ROM hack of an existing Sonic game. It was later used in a few other fan projects, Sonic XG and Sonic Nexus, which would then be formed into Retro Sonic Nexus. During 2009, Sega asked fans for suggestions of a game to be ported to the iOS devices, which Christian proposed with a proof-of-concept of a Sonic CD port using the Retro Engine running on an iPhone. Impressed by Christian's efforts, Sega hired him to develop an official remaster of Sonic CD and released it on PlayStation 3, Xbox 360, PC via Steam, and iOS and Android devices. The Retro Engine would later be used in collaboration with other Sonic community members such as Simon "Stealth" Thomleynote  and PagodaWest Gamesnote  in later projects with Sega. The engine has since led to the development of the Star Engine, a stylized HD 3D game engine named after the studio name Evening Star, which was founded during the development of Sonic Mania.
  • The Modding Tree is a JavaScript-based engine that lets players develop Prestige Tree-style game and other incrementals, with several features that didn't exist in the original. It's so well-made and comfortable to use that the original game's developer made a remake in it.
  • The Moai Engine, originally by Zipline Games. It's released under a Common Public Attribution License, meaning it's not fully Open Source, but nonetheless is Freeware. Some notable titles created using the engine include Crimson: Steam Pirates by Bungie and Broken Age and Spacebase DF-9 by Double Fine.
  • Blender used to be able to be used as a game engine as well, and the main program once could be used as a Game Maker. The feature was deprecated due to very few people actually using Blender to write a whole game and the game engine functionality was gone by Blender 3. However, the few people who did care forked the project and the end result is UPBGE.

Internally Developed Game Engines:

Things That Are Commonly Called Engines But Aren't:

  • The Havok "Engine". This is not an engine; it is a physics library.
  • RenderWare, developed by Criterion Games and bought out by Electronic Arts (notable for making PlayStation 2 development a lot easier). This is not in the most technical sense an engine, because it does not provide a means for using it without modifying the source code. It is a codebase, a large code library that serves as a useful starting point for making games, but it has no inherent extensibility built into it besides writing code. Games made using this codebase include Burnout (Criterion's flagship series), Grand Theft Auto (III, Vice City and San Andreas), Sonic Heroes and SpongeBob SquarePants: Battle for Bikini Bottom. It is no longer actively used; Criterion's last game to use RenderWare was Burnout Paradise (2008) and Burnout Paradise Remastered (2018), the latter's use making it the only RenderWare game on PlayStation 4, Xbox One and Nintendo Switch. Harry Potter and the Half-Blood Prince (2009) was the last original EA title to use it, Persona 4 Golden for the PlayStation Vita was the last game to use the vanilla RenderWare, and Taiwanese game Chinese Paladin 5 Prequel (2013) was the last to use any version of RenderWare (it used a modified version).
  • Cocos2d (along with its cross-platform offshoot, Cocos2d-X) (2008-present)): It is commonly used for making iOS games, but like RenderWare above, it is not an engine in the above definition.
  • The Box2D engine. It isn't necessarily a "game" engine more so a stand-alone physics engine made to make game making easier.
  • Old Apple Macintosh users might remember the Sprite Animation Toolkit (SAT), which was a 2D animation code library, though not a complete game engine.
  • SDL and SFML are commonly mistaken for game engines, but they are actually multimedia libraries which can be used to make engines.note 
  • XNA and its open source implementation MonoGame are not engines but frameworks for creating games and engines using .NET/Mono languages like C# and Visual Basic.

Previous

Index

Next

  • Show Spoilers
  • Night Vision
  • Sticky Header
  • Wide Load

Important Links

Ask The Tropers Trope Finder Media Finder Trope Launch Pad Tech Wishlist Reviews Go Ad Free!
Crucial Browsing
Resources
Top