Game engine

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A game engine is a software system designed for the creation and development of video games. There are many game engines that are designed to work on video game consoles and desktop operating systems such as Microsoft Windows, Linux, and Mac OS X. The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, and a scene graph. The process of game development is frequently economized by in large part reusing the same game engine to create different games.[1]


[edit] Overview

Game engines provide a suite of visual development tools in addition to reusable software components. These tools are generally provided in an integrated development environment to enable simplified, rapid development of games in a data-driven manner. These games engines are sometimes called "game middleware" because, as with the business sense of the term, they provide a flexible and reusable software platform which provides all the core functionality needed, right out of the box, to develop a game application while reducing costs, complexities, and time-to-market—all critical factors in the highly competitive video game industry.[2]

Like other middleware solutions, game engines usually provide platform abstraction, allowing the same game to be run on various platforms including game consoles and personal computers with few, if any, changes made to the game source code. Often, game middleware is designed with a component-based architecture that allows specific systems in the engine to be replaced or extended with more specialized (and often more expensive) middleware components such as Havok for physics, FMOD for sound, or Scaleform for UI. Some game engines such as RenderWare are even designed as a series of loosely connected middleware components that can be selectively combined to create a custom engine, instead of the more common approach of extending or customizing a flexible integrated solution. However extensibility is achieved, it remains a high priority in games engines due to the wide variety of uses for which they are applied. Despite the specificity of the name, game engines are often used for other kinds of interactive applications with real-time graphical requirements such as marketing demos, architectural visualizations, training simulations, and modeling environments.[3]

Some game engines only provide real-time 3D rendering capabilities instead of the wide range of functionality required by games. These engines rely upon the game developer to implement the rest of this functionality or assemble it from other game middleware components. These types of engines are generally referred to as a "graphics engine," "rendering engine," or "3D engine" instead of the more encompassing term "game engine." However, this terminology is inconsistently used as many full-featured 3D game engines are referred to simply as "3D engines." A few examples of graphics engines are: RealmForge, Truevision3D, OGRE, Crystal Space, Genesis3D, Irrlicht and JMonkey Engine. Modern game or graphics engines generally provide a scene graph, which is an object-oriented representation of the 3D game world which often simplifies game design and can be used for more efficient rendering of vast virtual worlds.

[edit] Hardware abstraction

Most often, 3D engines or the rendering systems in game engines are built upon a graphics API such as Direct3D or OpenGL which provides a software abstraction of the GPU or video card. Low-level libraries such as DirectX, SDL, and OpenAL are also commonly used in games as they provide hardware-independent access to other computer hardware such as input devices (mouse, keyboard, and joystick), network cards, and sound cards. Before hardware-accelerated 3D graphics, software renderers had been used. Software rendering is still used in some modeling tools or for still-rendered images when visual accuracy is valued over real-time performance (frames-per-second) or when the computer hardware does not meet requirements such as shader support or, in the case of Windows Vista, support for Direct3D 10.[4]

With the advent of hardware accelerated physics processing, various physics API such as COLLADA and PAL became available to provide a software abstraction of the Physics processing unit of different middleware providers and console platforms.

[edit] History

Prior to game engines, games were typically written as singular entities: a game for the Atari 2600, for example, had to be designed from the ground up to make the most optimal use of the display hardware—this core display routine is today called the kernel by retro developers. Other platforms had more leeway, but even when the display was not a concern, memory constraints usually sabotaged attempts to create the data-heavy design that an engine requires. Even on more accommodating platforms, very little could be reused between games. The rapid advance of arcade hardware—the bleeding edge of the market—meant that most of the code would have to be thrown out afterwards anyway, as later generations of games would use completely different game designs that took advantage of extra resources. Thus most game designs through the 1980s were designed through a hard-coded ruleset with a small amount of level and graphics data.

The term "game engine" arose in the mid-1990s, especially in connection with 3D games such as first-person shooters (FPS). (See also: first-person shooter engine). Such was the popularity of id Software's Doom and Quake games that, rather than work from scratch, other developers licensed the core portions of the software and designed their own graphics, characters, weapons and levels—the "game content" or "game assets." Separation of game-specific rules and data from basic concepts like collision detection and game entity meant that teams could grow and specialize,

Later games, such as Quake III Arena and Epic Games's 1998 Unreal were designed with this approach in mind, with the engine and content developed separately. The practice of licensing such technology has proved to be a useful auxiliary revenue stream for some game developers, as a single license for a high-end commercial game engine can range from US$10,000 to $3,750,000 (in the case of Warcraft III)[citation needed], and the number of licensees can reach several dozen companies (as for the Unreal Engine). At the very least, reusable engines make developing game sequels faster and easier, which is a valuable advantage in the competitive computer game industry.

Modern game engines are some of the most complex applications written, frequently featuring dozens of finely tuned systems interacting to ensure a finely controlled user experience. The continued refinement of game engines has created a strong separation between rendering, scripting, artwork, and level design. It is now common (as of 2003), for example, for a typical game development team to have several times as many artists as actual programmers.[5]

First-person shooter games remain the predominant users of third-party game engines, but they are now also being used in other genres. For example, the RPG Morrowind and the MMORPG Dark Age of Camelot are based on the Gamebryo engine, and the MMORPG Lineage II is based on the Unreal Engine. Game engines are used for games originally developed for home consoles as well; for example, the RenderWare engine is used in the Grand Theft Auto and Burnout franchises.

Threading is taking on more importance due to modern multi-core systems (e.g. Sony's Cell) and increased demands in realism. Typical threads involve rendering, streaming, audio, and physics. Racing games have typically been at the forefront of threading with the physics engine running in a separate thread long before other core sub-systems were moved, partly because rendering and related tasks only require updating at 30-60 Hz. For example, Need For Speed on the Playstation ran its physics at 100 Hz as compared to Forza Motorsport 2 running its physics at 360 Hz.

Although the term was first used in the 1990s, there are a few earlier systems in the 1980s that are also considered to be game engines, such as Sierra's AGI and SCI systems, LucasArts' SCUMM system and Incentive Software's Freescape engine. However, unlike most modern game engines, these game engines were never used in any third-party products (except for the SCUMM system which was licensed to and used by Humongous Entertainment).

[edit] Recent trends

As game engine technology matures and becomes more user-friendly, the application of game engines has broadened in scope, and are now being used for serious games: visualization, training, medical, and military simulation applications.[6] To facilitate this accessibility, new hardware platforms are now being targeted by game engines, including mobile phones (e.g. iPhone) and web browsers (e.g. Shockwave, Flash, Silverlight, Unity Web Player).[7]

Additionally, more game engines are being built upon higher level languages such as Java and C#/.NET (e.g. TorqueX, Blade3D, and Visual3D.NET). As most 3D rich games are now mostly GPU-limited (i.e. limited by the power of the graphics card), the potential slowdowns of higher level languages become negligible, while the productivity gains offered by these languages works to the game engine developers' benefit.[8][9] These recent trends are being propelled by companies such as Apple Inc. and Microsoft to support Indie game development on more platforms, such as the iPhone and the Xbox360 using Java or the .NET Framework and OpenGL/OpenAL and XNA for graphics and audio rendering. It is becoming easier and cheaper than ever to develop games for platforms that support managed frameworks.[10]

[edit] Middleware

Some companies now specialize in developing software suites known as "middleware." Middleware developers attempt to "pre-invent the wheel" by developing robust software suites which include many elements a game developer may need to build a game. Most middleware programs provide facilities that ease development, such as graphics, sound, physics and AI functions. Gamebryo and RenderWare are such widely used middleware programs.[11]

Some middleware only does one thing, but does it more convincingly or more efficiently than general purpose engines. For example, SpeedTree was used to render the realistic trees and vegetation in the role-playing game The Elder Scrolls IV: Oblivion.[12]

Two widely-used packages that provide subsystems of functionality include Havok and several of RAD Game Tools' systems. Havok provides a robust physics simulation system and RAD Game Tools develops systems for video rendering, audio playback, and 3D rendering.

Some middleware contains full source code, others just provide an API reference for a compiled binary library. Some middleware programs can be licensed either way, usually for a higher fee for full source code.

[edit] MMOG Middleware

Middleware for massively-multiplayer online games is far more complex than for single-player video games. However, the increasing popularity of MMOGs is spurring development of such middleware packages. Some prominent solutions, based upon sales[citation needed], include:

[edit] FPS game engines

A well-known subset of game engines are 3D first-person shooter (FPS) game engines. Groundbreaking development in terms of visual quality is done in FPS games on the human scale. While flight and driving simulators and real-time strategy (RTS) games increasingly provide realism on a large scale, first-person shooters are at the forefront of computer graphics at smaller, more human scales.

The development of the FPS graphic engines that appear in games can be characterized by a steady increase in technologies, with some breakthroughs. Attempts at defining distinct generations lead to arbitrary choices of what constitutes a highly modified version of an 'old engine' and what is a brand new engine.

The classification is complicated as game engines blend old and new technologies. Features considered advanced in a new game one year, become the expected standard the next year. Games with a mix of older generation and newer feature are the norm. For example Jurassic Park: Trespasser (1998) introduced physics to the FPS games, but it didn't become common until around 2002. Red Faction (2001) featured destructible walls and ground, something still not common in engines years later (for example in Unreal Tournament 2004 there are still no destructible objects). Battlezone (1998) and Battlezone II: Combat Commander (1999) added vehicle based combat to the usual FPS mix, which did not hit the mainstream until later. Tribes 2, Battlefield 1942, Halo: Combat Evolved and Unreal Tournament 2004 fully realized the potential for vehicular-combat and first person shooter integration.

[edit] References

[edit] See also

[edit] External links

Personal tools