Writing your idea down is not starting the damn game.

Writing a
design document is not starting the damn game. Assembling a team
is not starting the damn game. Even doing graphics or music is not
starting the damn game. Its easy to confuse preparing to start the
damn game with starting the damn game. Just remember: a damn
game can be played, and if you have not created something that can
be played, its not a damn game!

MAKE SOMETHING!
(a seguir, alguns pargrafos com dicas valiosas para
game development)

Alternatively, find free graphics and music to use online, at least as placeholders (at The
Independent Gaming Source we had a competition in which a lot of free art and music was
created). Use ASCII if you have to. As an artist, I know Id much rather contribute to a project
that is already done but just missing art. And if you need a coder consider learning to code
yourself (if I can do it, you can, too!) or picking up some game-making software (see #3).

My codes a mess. And Ive learned so much already. If I started over I could do it a lot better
and faster, and then the rest of the game will go a lot faster, too!

lot of game-making is tedious and downright unfun. Its not play, its work (and this is why
you should choke out ANYONE when they joke about you playing games all day). At some
point youll suddenly realize that theres all this stuff you never thought about when you were
planning your project and prototyping - stuff like menus, screen transitions, saving and loading,
etc. Shoot! I was imagining this amazing world I was going to create, or this fun mechanic I was
going to play with I didnt think Id be spending weeks making functional menus that dont look
like crap! Or, you know, theres stuff thats fun in small doses, like animating characters, that
becomes nightmarish when you realize youve set yourself up for 100 different characters.

Feeling stuck? Push forward. Start working on the next level, the next enemy, the next
whatever. Not only is it helpful for motivational purposes, but you want to get a sense for how
your whole game will play out. Just like writing - you dont want to go through it sentence by
sentence, making sure every sentence is perfect before you move on. Get an outline down.

Importante: elaborar o projeto todo com vrios prottipos. (Programao Extrema).

SE POSSVEL, ENTRAR EM COMPETIES DE GAME DEVELOPMENT. (Muito importante
porque fora os desenvolvedores a tomarem decises crticas, lidar com recursos e gerenciar o
tempo de desenvolvimento)



Projeto K.T.A.

Basicamente, um survival RPG Live Action. Baseado em ondas de inimigos.
A cmera, a princpio pode ser como a dos Beatup como Double Dragon e Battletoads. Mas, o
objetivo final fazer uma cmera como o jogo The Legend of Zelda: A Link to the Past.

Os personagens usaram armas. A idia criar 4 personagens jogveis, onde 2 deles so
achievements. A verso 1 no vai suportar multplayer.

Escrevendo para no esquecer:
ETAPA 1 (mecnica do jogo)
1 - carregar uma imagem na tela
2 - carregar um personagem sobre a imagem na tela
3 - mapear os movimentos do personagem: norte, sul, leste e oeste.
4 - fazer o personagem se movimentar na tela
5 - carregar outro personagem, permitindo dois personagens na tela.
6 - fazer os 2 personagens se movimentarem simultaneamente e independentemente
(aprender concorrncia de threads)

Importante: But really, the most important piece of advice is, don't try to write a shrink-
wrapped game engine for later use. You're going to end up exactly where you are now: needing
to "rewrite it, and this time do it right". If you want to get something out of it that works, you need
to start with its use case. Write the game first. When you've done that, you can start refactoring
the code to separate the engine out. That way, you end up with an engine that works.

Most hobby developers who finish an engine that was designed and built in isolation (with
the goal of having an engine, not a game, upon completion) cant ever actually use it, and
neither can anybody else. Since the project didnt have any goals, any boundaries, or any
tangible applications, it essentially attempted to solve aspect of the chosen problem space and
consequently failed miserably. These engines tend to be little more than an inconsistent and
messy amalgamation of random functionality that isnt terribly practical, robust or reusable.

Opinies sobre game engine

If you've not made a game yet, then learning about how to make game engines is counter-
productive. The engine should emerge from the game, not vice versa. After all, for code to be
reusable, it must first be usable, and unless you have successfully written a game with it, you
can't prove that your code is usable for a game.
You might think that reading a book on game engines would tell you exactly what you need, but
the fact is that different games have very different requirements. The better the engine, typically
the wider a range of requirements it will cover, which means both a higher level of complexity
and a more abstract level of working, meaning it will bear very little resemblance to the sort of
problems you will face as a beginning game programmer.
As a beginner, you need to focus on keeping it small and simple. Your basic game loop will look
like this and you just have to fill in the functions:
init
while 1:
get_input
update_objects
render
shutdown
Obviously you will come across some specific issues, but the best way to approach them is
to ask a specific question about the sort of feature you're trying to implement, because it's
easier for someone to tell you how to do something than it is for them to recommend a book
that covers everything that you might possibly want to do (largely because such a book doesn't
exist). If you can cite existing games as examples, even better.
You didn't state whether you are new to programming or just to game programming - often, a
lot of the problems faced by game programmers are down to a lack of understanding of basic
programming fundamentals. Your Rube Goldberg comment implies the latter, and if so, it's
worth picking up good books like Code Complete to get you out of bad coding habits.

7 down
vote
accepted
The distinction between the game and the actual game engine is architectural.
The game logic is specific for one game whereas the game engine is something
that can be reused. Much like an operating system provides utilities for
applications the game engine does the same for the game code.
Game engines will typically have different APIs for:
Loading multimedia data like audio, textures, 3d models
Providing a game loop and firing off various events caused by the users
input
Networking
Graphics rendering and various techniques to make the game look nice
using lighting, particle effects or bump mapping
Audio
Artificial Intelligence
An API to allow for defining game rules, game play, and game logic
Most game developers do not write their own game engine. It would be too much
work. Instead they'll reuse a game engine their company has or license one. For
first person shooters, id Software, and Unreal are two popular choices.
Once they have the engine they have to start writing code to make their game.
This is done using the API provided by the game engine. For example Valve
makes developers use C++. If you wanted a monster you would extend off of the
Entity class and define how this monster behaves in that base class.
I would recommend reading through the documentation and tutorials provided
by the various game engine providers. Keep in mind some games are classified
as "mods" and some as "total conversions." Typically, a mod does not change
the engine of the game and the total conversion may add or remove significant
features to a game engine.
Here are a few sources I would recommend:
http://developer.valvesoftware.com/wiki/SDK_Docs
http://udk.com
id Software releases their game engines as GPL after a few years.
Reading through their code you'll learn a lot: ftp://ftp.idsoftware.com/
idstuff/source/quake3-1.32b-source.zip. I would also recommend taking
a look at Enemy Territory which was a based of quake 3 code: ftp://
ftp.idsoftware.com/idstuff/source/ET-GPL.zip.

It also depends on the "level" of the Engine. What I mean with that, is how abstract the Engine
is from a certain gamestyle. There might be small things like a engine that is focused on a FPS
might be built to be optimized for indoor areas, outdoor areas, that you fly at high speed. So
even if a Engine might not be locked to a game, certain game types will be easier to implement
certain Engines.
But as stated above, the game won't inherit the engine, it will more probably draw on it's
functionality, and you will probably attach components to it's existing components. Or expand
the components that are part of the engine.
class CoolDiscoLight : public Engine::Light
{
};

...
//and somewhere in the source

"CoolDiscoLight cdl = new CoolDiscoLight etc..."

EngineInstance.AddLight(cdl);
...
Even more probible is the fact that just by extending from light and overloading the correct
functions the light will be accessible to a level editor etc so you won't actually create them
trough the source at all.

How to build Game Engine From Scratch

A general game engine, which can be reused to create many different games, can be extremely
useful, but can also be very difficult to design and implement. The goal is to create games
simply by creating game content and letting the engine handle all the hard work. A great deal
of work can go into this endeavor. However, an engine can be as simple or complex as a
programmer wants it to be. The more complicated, the less the game creator would have to do
to create a game, but simpler engines are much easier to implement and can get a game up
and running much quicker.

Difficulty:
Challenging

Instructions

1.
1

Design the basics of the game engine. These include things like the memory
manager, the kernel, and the loggers that will be used by all components of the
engine. A memory manager creates a uniform interface for game object creation,
and allows you to track memory usage throughout the program. The kernel
is the guts of the game engine, the thing that is run every frame that makes
sure everything else runs. Loggers are invaluable, and should be a part of any
complex program.


2

Create a general design for a game engine that suits your needs. The main
components of the engine are the input component, the game state updater, and
the rendering component. The input portion takes user input and translates it to
something the game state updater can handle. The game state updater handles
the input to update the state of the game. The rendering engine draws the game
state to the screen. These can each be as complicated or simple as you need
them to be.


3

Design and implement the input component. This will often depend on the
system the game is to be used on, and a more complex design will allow use on
multiple operating systems and hardware configurations. The input engine should
accept input from key, mouse, joystick, and possibly other human-computer
interface devices and translate them into values that are meant to update the
game state. It might be useful to create a tool that maps certain inputs to game
actions.


4

Create the game state updater. This is often the most complex component of the
game engine. It will handle the game rules, game physics, and any networking
the game may need. A lot of time spent designing this portion can save many
headaches later.


5

Create the rendering engine. The complexity that this component needs
depends greatly on the game itself. Often, 3D games will have very sophisticated
rendering engines in order to create the most visually stunning graphics possible
while trying to use as little of the system resources as it can. Sometimes, though,
things just need to be drawn to the screen, such as in a poker game, and the
programmer need not care much about how the system resources are used.


6

Create tools for the various components. Tools, in this context, are programs
that allow game creators to add content or configure components for a specific
game. For example, an input tool would allow a content creator to map keyboard
inputs to various game actions, where a tool for the rendering engine could allow
a designer to devise a graphical user interface for a game. Tools also allow you
to test the components of your game engine without actually running an entire
game, and can help lead to better designed components.





WIKIPEDIA

Motor de jogo (tambm conhecido pelo termo em ingls, game engine, ou simplesmente
engine) um programa de computador e/ou conjunto de bibliotecas, para simplificar e abstrair
o desenvolvimento de jogos eletrnicos ou outras aplicaes com grficos em tempo real, para
videogames e/ou computadores rodando sistemas operacionais. A funcionalidade tipicamente
fornecida por um motor de jogo inclui: um motor grfico para renderizar grficos 2D e/ou 3D,
um motor de fsica para simular a fsica ou simplesmente para fazer deteco de coliso,
suporte a animao, sons, inteligncia artificial, networking, gerncia de memria, gerncia de
arquivos, gerncia de linha de execuo, suporte a grafos de cena e entidades e, suporte a
uma linguagem de script.[1] O termo game engine originou-se no meio da dcada de 1990,
especialmente em conexo com jogos 3D, como tiro em primeira pessoa. O primeiro motor de
jogo a ser usado em projetos de terceiros foi o Freescape Engine, usado para criar jogos de
tiro em primeira pessoa.[2] Preos de motores de jogos variam muito, desde a gratuidade e
valores baixos, como $98,00[3], at valores exorbitantes como $31.200,00[4] ou mais caros. O
processo de desenvolvimento de jogos frequentemente agilizado, quando um mesmo motor
de jogo usado para criar diferentes jogos.[5]

A maioria dos motores de jogo so distribudos em forma de API, porm, alguns motores
so distribudos em conjunto de ferramentas, que agilizam e simplificam ainda mais o
desenvolvimento do jogo, como por exemplo: IDEs, scripts pr-programados, e programas
que empacotam e deixam pronto o jogo para distribuio. Esses motores completos so
chamados de Middleware, pelo fato de conectar diversos softwares em um nico software.
Pelo fato de serem distribudos com outras ferramentas, eles suprem a necessidade da compra
de outras ferramentas, reduzindo os custos todos fatores crticos na altamente competitiva
indstria de jogos eletrnicos.[6] Como exemplo, pode-se citar: Blender, Havok, RenderWare e
Unreal Engine.
Um motor de jogo pode ser dividido em duas principais categorias: motor grfico e motor
de fsica. Motores grficos lidam com os grficos, sendo responsveis de processar dados
abstrados de alto nvel e gerar dados de baixo nvel entendveis pelo hardware. Como
exemplo, pode-se citar: Crystal Space, Irrlicht e OGRE. Motores de fsica lidam com a fsica,
sendo responsveis por simular aes reais, atravs de variveis como gravidade, massa,
frico, fora e flexibilidade. Como exemplo, pode-se citar: Bullet, COLLADA e ODE.[1]
Apesar da especificidade do nome, motores de jogo so tambm usados para criar outros tipos
de aplicaes interativas com grficos em tempo real, tais como demonstraes, visualizaes
arquiteturais, simulaes de treinamento (como de pilotagem de aeronaves e manuseio de
armas), ferramentas de modelagem e, simulaes fsicas para a criao de animaes e cenas
de filmes realistas.[7]
[editar] Histria
Antes dos motores de jogo, os jogos eram tipicamente escritos como entidades singulares
(no havia separao de reas, como grfica e fsica): um jogo para o Atari 2600, por
exemplo, tinha que ser planejado do incio, mantendo o cdigo o mais simples possvel, para
fazer uso otimizado do hardware, por causa de suas limitaes.[8] Mesmo em plataformas
mais favorveis, muito pouco podia ser reutilizado entre os jogos. O rpido avano do
hardware fez com que a maioria dos cdigos tivessem que de qualquer maneira, serem
jogados fora posteriormente, como as geraes posteriores de jogos devessem usar designs
completamente diferentes que tomassem vantagem de recursos extras e tecnologias mais
novas.[9]
O termo game engine originou-se no meio da dcada de 1990, especialmente em conexo
com jogos 3D, como tiro em primeira pessoa. Igual como, foi a popularidade dos jogos Doom
e Quake, ao invs de construir o jogo do zero, outros desenvolvedores licenciaram os ncleos
dos jogos, usando-os como base para seus prprios motores de jogo. Com o amadurecimento,
os motores de jogo deixaram de se restringirem ao desenvolvimento de jogos. Eles so usados
em outras reas, como treinamento, uso mdico e simulaes militares.[10]
Apesar de j serem criados jogos muito antes da criao de APIs como DirectX e OpenGL,
aps a criao dos mesmos impulsionou a evoluo das tecnologias usadas nos jogos e
a ajudou a desenvolver esse mercado.[11] A primeira verso do DirectX foi lanada em 30
de setembro de 1995 como a Windows Games SDK. Ele foi a substituio da Win32 API
para as APIs DCI[12] e WinG para Windows 3.1. Depois de criado, o DirectX permitiu todas
as verses do Microsoft Windows, iniciando com o Windows 95, a incorporar multimdia de
alto desempenho. Eisler escreveu sobre a loucura para construir o DirectX 1 at o 5 em seu
blog.[13] Apesar do OpenGL ter sido criado primeiro (janeiro de 1992.), o DirectX teve (e ainda
tem) mais aceitao na rea de desenvolvimento de jogos.[14]
Por muito tempo, as companhias fizeram seus prprios motores de jogo. Com o passar dos
anos, o custo de se fazer motores de jogo cresceu muito, e por esse motivo, vrias companhias
comearam a se especializar em construir motores de jogo, ou componentes de motores,
para vender para outras companhias. muito caro (e demorado) para uma companhia ter que
produzir seu prprio motor de jogo para depois construir o jogo.[15]
Motores de jogo modernos so umas das aplicaes mais complexas j escritas. A contnua
evoluo dos motores de jogo tem criado uma forte separao entre renderizao, scripting,
arte, e design de nveis. Atualmente, por exemplo, comum para um tpico time de
desenvolvimento de um jogo ter muitos artistas quanto programadores.[16]
Como a maioria dos jogos 3D esto, cada vez mais, se limitando ao poder da GPU e PPU, as
perdas de desempenho das linguagens de programao de alto nvel, como C, Java e Python,
deixam de ser vlidas, enquanto os ganhos de produtividade oferecidos por essas linguagens
trabalham em benefcio dos desenvolvedores de motores de jogo.[17]
Apesar do termo ser primeiramente usado nos anos 90, h alguns sistemas nos anos 80 que
tambm so considerados motores de jogos, tais como Sierra's AGI e SCI Systems, LucasArts'
SCUMM e Incentive Software's Freescape Engine. Entretanto, diferente da maioria dos motores
de jogo modernos, esses motores de jogo nunca foram usados em quaisquer produtos de
terceiros, com exceo do SCUMM System que foi liceniado e usado para Humongous
Entertainment. O primeiro motor de jogo a ser usado em projetos de terceiros foi o Freescape
Engine, usado para criar jogos de tiro em primeira pessoa.[2]
Preos de motores de jogos variam muito, desde a gratuidade e valores baixos, como $98,00[3]
, at valores exorbitantes como $31.200,00[4] ou mais caros. A indstria de jogos eletrnicos
tem constantemente expandido. O lucro dessa indstria em 2007 foi de $9,5 bilhes,
ultrapassando a indstria cinematogrfica.[18]
[editar] Abstrao de hardware
Motores de jogo fornecem abstrao de hardware, permitindo um programador desenvolver
jogos sem a necessidade de conhecer a arquitetura da plataforma-alvo, que pode ser um
videogame ou um sistema operacional. Por esse motivo, muitos motores so desenvolvidos a
partir de uma API existentes, como OpenGL, DirectX, OpenAL e SDL, ou at mesmo a partir
de outro motor, que pode facilitar o seu desenvolvimento. A abstrao de hardware tambm
essencial para o desenvolvimento de motores de jogo multiplataforma.[11][19]
Antes dos grficos 3D acelerados por hardware, renderizadores por software eram usados.
Renderizao por software ainda usada em algumas ferramentas de modelagem e
renderizadores de imagens, onde a qualidade grfica priorizada, ou quando o hardware no
suporta determinada tecnologia, tal como suporte a shaders.[20]

Motores de tiro em primeira pessoa

Um bom e conhecido subconjunto de motores de jogo so os motores de tiro em primeira
pessoa 3D. Enquanto jogos de estratgia em tempo real e simuladores de voo apostam na
qualidade grfica, jogos deste gnero apostam na ao. O motor mais conhecido deste gnero
o Doom. Motores de tiro em primeira pessoa so importantes pois marcam o incio da criao
e uso de motores de jogo na histria. O primeiro motor de jogo a ser usado em projetos de
terceiros foi o Freescape Engine, usado para criar jogos de tiro em primeira pessoa.[2]
As melhorias em GPUs como Shader Model 3 e Shader Model 4, possibilitou melhorias
em efeitos grficos. A partir de 2009, duas evolues dos principais motores existentes, foi
anunciada: id Tech 5 (que ser usado pela primeira vez com o Rage, e contar com uma nova
tecnologia chamada Virtual Texturing[21]), e o CryEngine 3, que ser usado na criao do
Crysis 2.
Poucas empresas tm discutido os planos para o futuro de seus motores, id Tech 6, o eventual
sucessor a id Tech 5 uma exceo. Informaes preliminares sobre esse motor que ainda
est em fases iniciais de desenvolvimento tendem a mostrar que a id Software est olhando
para uma direo onde Ray tracing e grficos Raster clssicos se misturam.[22] No entanto, de
acordo com John Carmack, o hardware capaz de aproveitar os recursos do id 6 Tech ainda no
existe.[23]

WIKIPEDIA (english)

A game engine is a 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 personal
computers. 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, localization support, and a scene graph. The process of game
development is often economized, in large part, by reusing/adapting the same game engine to
create different games.[1]

Purpose
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. Game engine
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 game engine suites provide
facilities that ease development, such as graphics, sound, physics and AI functions. These
game engines are sometimes called "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-marketall critical factors in the highly competitive video game
industry.[2] Gamebryo and RenderWare are such widely used middleware programs.[3]
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 engines are
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) game middleware
components such as Havok for physics, Miles Sound System for sound, or Bink for Video.
Some game engines such as RenderWare are even designed as a series of loosely connected
game 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 needs
such as marketing demos, architectural visualizations, training simulations, and modeling
environments.[4]
Some game engines only provide real-time 3D rendering capabilities instead of the wide
range of functionality needed 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." 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: Crystal Space, Genesis3D, Irrlicht, JMonkey
Engine, OGRE, RealmForge, Truevision3D, and Vision 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
application programming interface (API) such as Direct3D or OpenGL which provides a software
abstraction of the graphics processing unit (GPU) or video card. Low-level libraries such as
DirectX, Simple DirectMedia Layer (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 needs such
as shader support.
With the advent of hardware accelerated physics processing, various physics API such as
PAL and the physics extensions of COLLADA (an interchange format for 3D assets) became
available to provide a software abstraction of the physics processing unit of different middleware
providers and console platforms.
[edit] History
Before game engines, games were typically written as singular entities: a game for the Atari
2600, for example, had to be designed from the bottom up to make optimal use of the display
hardwarethis 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 needs. Even on
more accommodating platforms, very little could be reused between games. The rapid advance
of arcade hardwarewhich was the leading edge of the market at the timemeant 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 first generation of third party graphics engines or renderers (and precursor to what we
now know as engines) was dominated by three players; BRender from Argonaut Software,
Renderware from Criterion Software Limited and RenderMorphics' Reality Lab. Reality Lab was
the fastest of the three and was the first to be acquired in an aggressive move by Microsoft. The
RenderMorphics team Servan Keondjian, Kate Seekings and Doug Rabson subsequently joined
the Microsoft project which turned Reality Lab into Direct3D before Keondjian and Rabson left
to start another middleware company Qube Software. Renderware was eventually bought by EA
(Electronic Arts) but was sidelined by the games giant.
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 levelsthe "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 one license for a high-end commercial game engine can range from US$10,000 to millions
of dollars, and the number of licensees can reach several dozen companies, as seen with the
Unreal Engine. At the very least, reusable engines make developing game sequels faster and
easier, which is a valuable advantage in the competitive video game industry.
Modern game engines are some of the most complex applications written, often featuring
dozens of finely tuned systems interacting to ensure a precisely controlled user experience.
The continued evolution of game engines has created a strong separation between rendering,
scripting, artwork, and level design. It is now common, 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 The Elder Scrolls III:
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. 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 subsystems were moved, partly because
rendering and related tasks need updating at only 3060 Hz. For example, on PlayStation 3,
physics ran in Need For Speed at 100 Hz versus Forza Motorsport 2 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 Adventure Game Interpreter (AGI)
and SCI systems, LucasArts' SCUMM system and Incentive Software's Freescape engine.
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. They 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.
Android phones, iPhone) and web browsers (e.g. WebGL, Shockwave, Flash, Trinigy's
WebVision, Silverlight, Unity Web Player, O3D and pure dhtml).[7]
Additionally, more game engines are being built upon higher level languages such as Java
and C#/.NET (e.g. TorqueX, and Visual3D.NET) or Python (Panda3D). 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] These recent trends are
being propelled by companies such as Microsoft to support Indie game development. Microsoft
developed XNA as the SDK of choice for all video games released on Xbox and related
products. This includes the Xbox Live Indie Games [9] channel designed specifically for smaller
developers who don't have the extensive resources necessary to box games for sale on retail
shelves. It is becoming easier and cheaper than ever to develop game engines for platforms
that support managed frameworks.[10]
[edit] Game middleware
In the broader sense of the term, game engines themselves can be described as middleware.
In the context of video games, however, it is often used to refer to subsystems of functionality
within a game engine. Some game middleware does only one thing but does it more
convincingly or more efficiently than general purpose middleware. For example, SpeedTree was
used to render the realistic trees and vegetation in the role-playing game The Elder Scrolls IV:
Oblivion.[11]
The four most widely used middleware packages[12] that provide subsystems of functionality
include RAD Game Tools' Bink, Firelight FMOD, Havok, and Scaleform GFx. RAD Game Tools
develops Bink for basic video rendering, along with Miles audio, and Granny 3D rendering.
Firelight FMOD is a low cost robust audio library and toolset. Havok provides a robust physics
simulation system, along with a suite of animation and behavior solutions. Scaleform provides
GFx for high performance Flash UI, along with a high quality video playback solution, and an
Input Method Editor (IME) add-on for in-game Asian chat support.
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] Massively multiplayer online games
Middleware for massively multiplayer online games (MMOs, MMOGs) is far more complex
than for single-player video games. Technically every normal game engine can be used to
implement an MMO game by combining it with MMO middleware. The increasing popularity
of MMOGs is spurring development of MMO middleware packages. Some MMO middleware
software packages already include a game engine, while others provide networking only and
therefore must be combined with a game engine to create a MMO game. Some prominent MMO
middleware solutions include:
Bigworld Technology[13] (client / MMO specific server)
Exit Games Neutron[14]
HeroEngine[15]
Monumental Games
Multiverse Network
Q (client-only, but with server solution as 'Messiah')[16]
RedDwarf Server (open source)
Vision Engine[17]
[edit] First-person shooter engines
Main article: First person shooter engine
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
on these smaller 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 did not 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] Visual novel engines
Due to the less graphic-intensive nature of visual novel games, visual novel engines tend to be
very simple compared to FPS game engines. Visual novel game engines include:
KiriKiri
NScripter
Ren'Py
Digital Novel Markup Language