Qué es un Game Engine

Introducción

Empezaremos esta guía con algunas definiciones.

1) Definición de Engine y distintos tipos de los mismos
a. Engine y para qué sirve
Engine es un motor, como lo especifica la palabra, que hace funcionar todo, como el motor de los vehículos, el corazón, etc. El término ni siquiera se aleja de lo establecido en el mundo de los gamers. Éste es el que permite que el juego tome vida.

El engine es aquél concepto abstracto al cual lo asociamos a una gran cantidad de líneas de código. No crean que el Engine es el juego en sí, si no el pilar “imaginario” donde se sostiene el juego. Sería confundir el motor de un Porche a un Porche entero. Nosotros podemos sacar ese motor y ponerlo en otro auto, y lo mismo pasa con los juegos.

b. En el mundo de los juegos
En realidad, es como un moderador entre los datos que entran y los datos que salen.

Como ven, este generalmente controla el renderizar (procesar una imagen) y otras tecnolog ías necesarias como el audio. También puede manejar otras tareas como Inteligencia Artificial (IA o AI en yanki), detección de colisiones entre objetos del juego, etc. El elemento más común de un Game Engine es proporcionar facilidades de renderizado, tanto 2D (onda Mario BROS) como 3D (Mario 64 por ejemplo).

Los Engines que sólo renderizan en 3D son a veces llamados 3D Engines. Entre algunos están Genesis3D, Irrlicht y Ogre. Muchos 3D Engines son diseñados para otros propósitos como CAD, películas, etc. pero a menudo para incorporarles a los juegos.

También existen otros tipos de Engine, como algunos que calculan las físicas de un juego, como la gravedad, aceleración, volumen, etc. Por citar alguno se encuentra , gran engine que permite manejar todo lo relacionado con físicas.

c. Cómo se hacen
Bueno, la gallina no fue primero que el huevo… queda claro… y tampoco el huevo primero que la gallina, o algo así XD. Pero todo debe nacer de algo ¿o no? Los engines son creados con herramientas tan potentes que sería de largo trabajo explicar alguno. La creación de un engine decente para un juego está al nivel de crear Windows o Linux: Es una de las más complicadas tareas que hay en el mundo de la programación.

En realidad hay diferentes caminos para hacer uno
• Grandes compañías gastan una gran cantidad de tiempo y dinero creando sus propios engines de manera robusta y multifuncional, como por ejemplo Epic Games (Creadores de Unreal), Id Software (creador de Doom y Quake) y Valve (Creador de Half-life).

• Otras compañías escriben sus propios engines pero más básicos, eso aún permite la creación de un juego decente.
• Algunas otras compañías licencian o “toman prestada” los engines como los de Valve e Id, si es que tienen dinero suficiente para pagarlo. Así se hizo Half-life 1, pagando por el motor de Quake.

• Muchos chicos con harto dinero y tiempo en sus manos compran Torque, un engine que se usó en el juego Tribes, que cuesta más o menos como $ 100 dólares y que tiene gran soporte y versatilidad. Muchos otros tambíen usarían Engines pero de código abierto (o sea gratis), que por ser así son un poco limitados.
• Prostituirse por 50 años de lunes a domingo sin vacaciones para comprarse Valve e Id. O sacarse el Kino y prostituirse la mitad de años.

d. De qué están hechos
Tengan en cuenta que cuando digo “engine” nos estamos refiriendo a un concepto abstracto o virtual. También nos estamos acercando a decir que el engine de un juego se parece en algo al de un sistema operativo como Linux o Windows. Estos engines no son nada de otro mundo, de hecho, son tan corrientes como el pan con shansho, el lomo vetao y la shoca. Estos son una línea de códigos que muy bien pueden residir en el EXE principal (onda Doom3.exe), en un archivo dll (como CryEngine.dll), o una junta de vecinos– digo, archivos, en una carpeta… Todo depende de cómo los creadores quieran hacer flexible el código del engine, o cómo les resulte más fácil hacerlo, y cuánto café tengan dispuesto para desvelarse.

e. Cómo funcionan
Es muy fácil, y es comparable con un auto.

Bueno, el engine no se prende solo, el motor de un auto tampoco. El motor de un auto (Engine) es ejecutado por lo que sería un la chispa del pistón (Doom3.exe). Cuando este crea la explosión (Windows ejecuta Doom3.exe), mueve la polea (Doom3.exe llama al engine) y ya tenemos nuestro Ferrari andando (el engine es ejecutado y carga sus cosas a la memoria). Si encontraron mal ejemplo del auto, no me culpen, yo tampoco tengo.

Entonces, aquí quedan a disposición los diferentes códigos y comandos, los cuales se activarán y llamarán a sus respectivos contenidos: gráficas, sonido, etc. Si me quieren preguntar cuáles son, más rato se los digo…

Deben recordar también que los engines no son estándares, vienen en diferentes formas, colores y sabores, con y sin pilas incluídas. Y para su creación, se necesita mucho conocimiento de lenguaje de programación como Visual Basic, C++, Mapudungún, etc.

f. Dato 0 aporte
Cuando un desarrollador crea un engine, en realidad está creando un “Engine de ensamblaje” (algo como el “Papá Engine”). Digamos que termina de armarlo ahora, entonces, ¿cómo diablos te lo va a ofrecer a tí, simple mortal no perteneciente al ABC1?

Ellos pueden restringir el Engine para que nadie lo modifique, así pueden vender los códigos originales (un Engine totalmente modificable) a otras empresas, o hacerlo abierto (no mal interpreten) y editable. Para hacer esto se valen de 3 puntos:

1) Reestricción total. Puedo crear un programa ejecutable para que pueda correr lo que mi engine de ensamblaje hizo: un engine versión “cliente” o “Engine Hijo”. La restricción total es aquella que no te permite cambiar ni el engine ni los “inputs” (gráficos, sonidos, etc.), contiene sólo el código justo y necesario para un juego.

2) Puedo usar el mismo engine cliente (hijo), pero limitarlo parcialmente. Cuando la restricción es parcial, tu puedes crear etapas, con nuevas texturas y sonidos, como por ejemplo Starcraft, pero no editar el Engine. También puedes editar algunas cosas del engine, como la densidad del aire, etc. y/o los inputs (texturas, sonidos, etc.). Generalmente el engine hijo dura hasta que se va de la casa y los padres quedan apenados.

Si no hubiera restricción a la modificación del engine, entonces ID no le hubiera cobrado a EA la plata para pasarle el engine de ensamblaje de Quake3 para crear Medal Of Honor, porque en el mismo Quake podemos editar el engine y los inputs… claro.

3) Pasar el “Engine de ensamblaje” entero, y usar un compilador estándar cosa que cualquier PC lo corra. Un compilador es un software que “traduce” los datos de entrada (como códigos u otros) en otro tipo de códigos entendibles para el otro software o hardware, como lo hace un emulador al leer los datos de un ROM.

Los códigos son tan abiertos, disculpen la expresión, que se pueden editar a libre desmedro, como también para optimizarlo. Tanto es así que incluso se puede aumentar la performance de un juego con algunas modificaciones en el código.

2) Historia de los Engine, su evolución

“La evolución de los Engines puede ser muy considerada la evolución de los juegos en sí, ya que cada juego, como el tan antiguo Pong, han tenido un “Engine” que los hace correr. El Pong original te dejaba jugar diferentes variaciones del mismo juego básico… variantes donde el rectángulo era más grande o más chico, o donde la bolita se movía más rápido. Esto fue posible gracias al Game Engine: algunas variables podían ser arregladas por otros valores diferentes, y la experiencia del juego cambiaría significativamente.

Sin embargo, los “engines” como los que conocemos hoy en día, son particularmente aquellos dentro del contexto de los First Person Shooters (FPS)… Bueno, supongo que esto tiene que ver mucho con la comunidad de MODs primero que nada. Los juegos han sido modificados y arreglados a lo largo del tiempo, e incluso uno de los primeros FPS, como Wolfenstein, tuvieron algunas modestas comunidades de MODs. Gráficas, sonidos, y niveles estaban contenidos en un archivo externo de extensión WAD, que una vez adoptado, podía ser modificado, cambiado y modificado para requisitos particulares para crear nuevos niveles e incluso nuevos juegos “MOD” con nuevas gráficas, sonido, e incluso jugabilidad.

Los MODs creados por usuarios continuaron escalando desde los primeros FPS hasta el gran mundo 3D, juegos basados en polígonos. El concepto de “licenciar un engine” también empezó algo temprano: el engine original del Doom fue rehusado numerosos tiempos, siendo con Hexen el más memorable. Cuando Bungie sacó al mercado “Maratón Infinity”, el último capítulo del predecesor de HALO, in 1996, fue incluido un software para modear el HUD y las físicas del game engine: este era un signo de que el modeo era una tendencia cada vez mayor, y cuando los desarrolladores realmente se animaron.

Pero el juego que cambió la escena de los motores de juego totalmente fue Half-life: no sólo Half-life usó el motor de Quake para entregar una jugabilidad bien diferente a Quake en un juego comercial, si no el mod creado para Half-life: Counter Strike, prosperó como uno de los más grandes sucesos en el juego en red de la historia. Half-life hizo evidente que los motores de los FPS tenían más potencial que sólo los juegos entregados en un inicio, y Counter Strike fue el mod que puso los MOD en lo alto.”
— Dkittels

Tengamos en cuenta que los engines también evolucionaron por su “facilidad de modificación”. Si los desarrolladores se hubieran “saltado” la creación del Engine, y crearan todos los elementos de un juego en algo sólido, como en un archivo ultra-comprimido, arreglar los datos de un nivel existente necesitaría una descompresión y comprimir de nuevo. Con un Engine, sólo necesitarías cambiar ese archivo crítico por uno nuevo: un logro técnico mucho más simple.

Por citar un ejemplo, cuando Nintendo creó “The Legend of Zelda: Majora’s Mask” ellos tomaron el engine del título anterior “The Legend of Zelda: The Ocarina of Time” (muy buen juego por cierto) y simplemente reemplazaron los datos anteriores por nuevos datos de gráficos, sonido y niveles. El Engine tomó estos nuevos datos y esencialmente creó un “nuevo” juego, ahorrándole al equipo desarrollador meses de desarrollo para desarrollarlo (valga la redundancia).

3) La pulsera de los 9 poderes

Sip, el engine sostiene 9 elementos críticos para que podamos jugar. No me refiero a que Omar Garate nos va a introducir ni menos a vender el tema, sino que el engine necesita estos 9 pilares básicamente para manejarse. Son los siguientes (en orden de creación, generalmente):

1) Render, procesamiento de gráficos
Bueno, para qué sirve. ¿Qué tal si creáramos un polígono y a la hora de ver los resultados en nuestra pantalla no los pudiéramos ver? Bueno, por esto se empieza, y dónde más duele cuando critican un juego. Verán, la calidad de un juego se basa generalmente en la capacidad y ventajas de su sistema de render, y esto tomas meses de desarrollo. Por ejemplo una ventaja sería no renderizar aquellos polígonos que están muy lejos, así los polígonos que ahorramos nos la gastamos en copete en la casa de mi suegro, o subiéndole el número de polígonos a otras cosas. Es cosa de ver Half-life 2 para asombrarse el nivel de render que tiene: BONITO y BARATO (para la GPU), incluso lo corrió mi ATI Radeon 7000 AGP BBA.

Bueno, este proceso llega a ser tedioso, así que no crean que crear un engine bien formado es cosa de días, sino de meses y noches de borrachera incontrolable.

La creación del render envuelve las empresas que proporcionan nuestra VGA, APIs, matemáticas y de paso entender como funciona el Hardware de nuestra GeForce o Radeon. Para las consolas, se necesita casi el mismo conocimiento, pero aquí es 100% seguro que nuestra tarjeta de video no va a quedar en la generación anterior porque Windows Vista no nos corre.

También es cosa de ingenio y optimizaciones, crear algo magnífico tratando de no overclockear nuestro PC con Nitrógeno líquido para que pueda dar 2~3 fps.

Dato rossa: Algunas empresas como ATI, nVidia, Intel y otras grises del rubro, pagan a los desarrolladores para optimizar el engine para su hardware, haciendo uso de de poderes “escondidos” del hardware (como códigos optimizados). Así el desarrollador gana recursos (o sea, plata) y la mejora sustancial de los gráficos, procesamiento de datos y otros (a costa de doblegar a la competencia del hardware respectivo) y la empresa que pagó vende más porque ESE JUEGO necesita ESE HARDWARE para correrlo bien. Díganme que ATI no subió sus ventas cuando lo hizo con Half-life 2 (Una ganga la Radeon 9600XT con un “Vale por 2 cervezas o Half-life 2”)

2) Creación de personajes y su animación
Aquí la cosa se pone peluda como una niña de 13. Después de crear a nuestros personajes ¿se van a quedar estáticos para siempre? Noooo señores, aquí interviene la animación.

Esto se basa en dos formas
• Por posición: de repente quieres hacer que tu soldado se mueva hacia un punto. Por ejemplo, está hecho de 6 polígonos con 8 vértices como un rectángulo. Si tomamos en cuenta que serán 5 fps (pantallazos por segundo XD), entonces la memoria quedará con la posición de… aver… la posición de 8 vértices por 5 fps = 40 posiciones diferentes. Ahora en vez del soldado de pocos polígonos pongamos a Max Payne… y verás porqué 1 GB de RAM no es suficiente…
• Por esqueleto: Ahora asignémosle un hueso a Max Payne, para que a la ves que se mueva tal hueso, se muevan algunos polígonos como los del brazo. Sólo tenemos
2 vértices o puntos en el plano, y son 5 fps. Así llegamos a la módica suma de 10 posiciones diferentes. Eso se llama salvar memoria y café.

Obviamente todos (o la mayoría) ocupa la animación por esqueleto, ya que este, además de ahorrar memoria y tiempo, puedes hacer que a la vez que mueva la pierna para caminar, el brazo pueda moverse para hacer un movimiento más fluido y salvar más memoria. Es lo mismo que se hizo con Star Wars: Jedi Knight 2. Katarn, el presonaje principal, movía los piés y el sable láser independientemente.

3) Level design (Creación del nivel)
Ahora quieres que Max payne vuele en la nada misma ¿De eso quieres que se trate Max Payne 3?. Aquí la cosa es fácil. Con algún programa como 3DMax, Maya u otro, crear el nivel con nuestros polígonos, texturas y efectos que queramos.

Luego de ser creado, los cabros se rajan exportándolo a un formato que el engine pueda entender, por ejemplo un archivo zip, donde hay imágenes jpeg o png, y un archivo de texto que diga la posición en el espacio de éstos (coordenadas X,Y,Z). Luego, es cosa que el engine lo lea y lo disponga.

4) Física.
Ya se creó el mundo donde vamos a poner nuestro soldadito, los efectos, las animaciones… etc. Pero ahora tenemos que hacerlo lidiar con la gravedad, inercia, puertas, murallas, balas, etc. En resumen, la colisión de los polígonos con otros polígonos y el desplazamiento de éste

Aquí es cosa de encontrar las maneras más reales o más divertidas de crear una ecuación ( y representarla en código) que permita manejar un polígono y sus colisiones. Aunque esto requiere harta explicación y tiempo… el cual yo no tengo, porque quiero irme luego a la playa, es cosa de imaginarse que gravedad, inercia, aceleración, y otros tienen un respectivo código o ecuación correspondiente, para agregárselo a los polígonos que creamos, todo por medio del engine, claro.

5) Partículas y Efectos
Yaaa. Corto y preciso. ¿Qué pasa si, cuando lancemos una granada, se creen 500 polígonos para que simulen el humo? Se nos va en collera nuestro Athlon 64 FX-60 por más núcleos pegados que tenga. ¿Qué tal si hacemos que se cree 1 polígono que sea “animado”, cosa que muestre una animación de humo transparente? 1 polígono para tal efecto, y ahorramos más memoria. Además se ve bonito .

Bueno, los efectos aparecen cuando sucede una acción o acontecimiento y crean un sub-mundo (no como el del Profesor Salomón y Tutu-tutu), independiente del juego (y a veces de las físicas), en donde unos cuantos pocos polígonos se crean, y sólo aparecen cuando ocurre una acción. Por ejemplo, una bala que choca con una pared, se crea un cubo imaginario donde en él aparece el humo creado y un marca, y desaparecerá después de un tiempo.

6) Sonido.
Listo, ahora es cosa de crear una acción o acontecimiento que ejecute un sonido, de paso provocar que el sonido sea “masticado” y devuelto con efectos particulares dependiendo del lugar, la distancia y si otros objetos obstaculizan el camino del sonido.

Cuando el sonido es digerido por el engine, éste le pide a HAL (como DirectSound o OpenAL) para que mixeen en la tarjeta de sonido (por hardware) o lo haga la misma CPU (por software). A veces esto no significa ganancia o pérdida de fps masiva, pero la desventaja de que lo haga el hardware es que el engine no puede concordar resultados como el volumen y profundidad final, pues son los parámetros de la tarjeta en sí, por muy enamorada que esté del juego . Si lo hace la CPU, los parámetros del engine son los que influyen y por lo tanto el volumen será controlado por lo parámetros que indique el engine. Digamos que el engine es machista. ¿Hay alguna mujer leyendo esto?

7) Redes
Para que un juego pueda “jugarse en Internet”, primero que nada hay que hablar de lo que es P2P. Peer-to-peer significa “Persona a persona”, una comunicación directa con cliente-servidor. El servidor manda datos, el cliente recibe … Ahora, asumiendo que los juegos del los clientes y el servidor están bien y correctamente actualizados, el servidor se encarga de “tragar” los datos que les mandan los clientes por cada FPS. Luego, los envía de vuelta a cada cliente, pero transformados en instrucciones; le pide que haga una muralla aquí, el jugador acá, etc.

Bueno, les introdusco dos formas de comunicación por al Internet: UDP y TCP. Nosotros conocemos TCP/IP por que con este protocolo navegamos por páginas truchas.

TCP trabaja así. Todos sabemos que la Internet se basa mayoritariamente en “paquetes”. Con TCP, nosotros enviamos un paquete a nuestro IP de destino (servidor). Lo mejor del TCP es que se garantizan que los paquetes llegan intactos y no se pierden por ahí porque el chofer era de micro de las que hacen carrera en la alameda. El costo es que si el servidor no manda de vuelta un “me llegó, manda otro” a nosotros, TCP va a parar la transmisión de nuevos paquetes y va a tirar el paquete que se perdió hasta que el servidor le haga visto bueno. Esto es comparable con mandarle un mensaje a nuestro vecino con un asistente: le dictamos el mensaje y él se ocupará de ver si el mensaje llegó o no. Bueno,
esto puede “congelar” la transmisión por un par de segundos de vez en cuando, pero en los juegos, los segundos son fata1es.

EL UDP es más rápido, porque es más bien una combinación directa contigo y tu vecino, digo, servidor. Pero UDP no te va a decir si el paquete llegó o no.

La mayoría de los juegos usan UDP, pero no garantizan el orden o llegada de los paquetes…

Lo que llevan los paquetes varía dependiendo del juego… en un FPS simple sólo se lleva la información de la posición, y si disparaste o no, básicamente, en donde predomina el UDP. Cuando el juego se torna complicado como un MMORPG, como Matrix on line, World Of Warcraf, Lineage 2, etc., el servidor no se molesta en tirarte información sobre lo que no ves, así el tamaño del paquete se reduce. Aquí el TCP es mejor

8 ) Scripting, ¿películas baratas?
Bueno, hace mucho tiempo atrás, generalmente no se utilizaban los propios engines de los juegos para hacer escenas como de película en el juego. Se limitaban a crear un video en computadoras poderosas para que luego nosotros la viéramos desde el CD-ROM. Me acuerdo que cuando uno miraba el video de presentación (que era pre-rendereado en computadoras mosntruosas) y decía “CTM! ésta es la calidad del juego! wow! No creo que lo pueda correr!) Luego, vuelta a la cruel realidad virtul, uno se ponía a jugar y no sabía si la copia había salido mala o estaba miope.

El scripting, a diferencia de programar la IA, es más simple porque todo está predefinido y no hay ninguna improvisación ni cálculo fuerte de la CPU. Es tan simple como “Mueve el sujeto al punto A, hazlo hablar con el siguiente WAV, luego se mueve al punto B”. También puede darse el caso de utilizar variables, cuando por ejemplo elegimos ser un Jedi o un Sith. Aquí la cosa se empieza a poner dura como fierro, pues resulta difícil o agotador crear tantos sucesos distintos para cada variable, aunque sean 2… como Indigo Prophecy/Fahrenheit.

n=”left”>9) Inteligencia Artificial
Bien, nadie dijo que crear un al legendario Doctor Abuse fue cosa de un par de cervezas y parranda sin que lo sepa la señora.

Imaginemos que tenemos un guardia, cuyo objetivo matar a todo aquél que se acerque a la puerta de tu casa. Primero debemos darle un tarea… entonces le pedimos que patrulle una puerta de izquierda a derecha.

Ahora, tenemos que asignarle el “alcance de conocimiento”, que son los límites que tendrá nuestro personaje y cómo verá el mundo del juego. Como verás, la computadora sabe todo lo que pasa, por lo tanto si no le asignamos a nuestro personaje límites, oirá y verá cosas que tú no podrás, y el juego se hace un poco difícil. También podemos asignarle un alcance de vista, para que reaccione a sólo lo que puede ver dentro de sus límites (como los guardias de Metal Gear Solid). También asignémosle que en un radio de 5 metros, no logre escuchar nada.

Para finalizar, tenemos que asignarle lo que hará si ocurre algo anormal en su “alcance de conocimiento”. Por ejemplo ignorar sonidos muy bajos, e inmediatamente investigar los altos. También que se alarme si ve algo que se mueve, cosas así.

Aquí generalmente es mejor optar por un sistema que no sea específico, sino que por cada NPC (Non Person Character) que exista tenga los mismos atributos. Así en vez de cambiarle a todos los códigos uno por uno, sólo cambiamos el código central y listo. Si necesitamos que un sniper sea capaz de sacar Headshot (ya me puse Counter Strike), sólo tenemos que crear una excepción para un personaje o crear un código específico para él.

Luego sólo resta crear cómo llega nuestro amigo del punto A o B, sin caminar a través de las paredes u otros. Es fácil decir pero muy muy difícil de hacer, y sólo se trata de ser imaginativo para arreglar el asunto aquí. Todo esto se basa en acción-decisión-reacción, y tener mucho cuidado con la reacción por que a veces nos encontraremos que no se pueden realizar por simple hecho de que es imposible en la vida real, ¿O es natural atravesar paredes?

4) El HAL : OpenGL, DirectX, etc.

Metámonos al campo de la antigüedad

¿Qué pasa si programas un balón en su época?

—Antes de DOS—

Tendrías que programar el código para cada tarjeta de video existente en el mercado, pasando por nVidia y ATI, para que se pudiera ver bien. Todo esto era muy cansador, y es por eso que algunos juegos o aplicaciones sólo funcionaban en un conjunto de hardware limitado.

—Después de DOS—

Ahora con DOS, sabrías que hay aspectos comunes al hardware, como el soporte para luces, sombras, etc.… pero igualmente tendrías que programar para las diferentes tarjetas gráficas, tarjetas de sonido, cdroms, y qué no…

—Después de Windows (Apocalipsis )—

Windows abrió las aguas del nilo creó estándares, parte de su fama se debe a eso, y el hardware de las empresas siguió los estándares. Así que estaba “casi” garantizado que la mayoría de las cosas que programaras estarían presentes en el hardware y software “estándar”. Aquí entra el HAL o Hardware Abstraction Layer: un intermediario, como los son los API (Application Program Interface como VisualBasic, C++, etc.). Esto permitió que programaras para Windows en vez de hacerlo directamente al Hardware. Windows se contactaría con los drivers, como los FroceWare o Catalyst, para que transformaran el código y se lo enviaran al componente físico involucrado.

—Después DirectX y OpenGL—
DirectX y OpenGL fueron, y siguen siendo, HAL de alto nivel que permiten que el programador haga cosas básicas y rápidas.

Un ejemplo, usando Visual Basic y no DirectX (aunque igual DirectX puede ser llamador desde cualquier lenguaje programación), es creando una forma. Yo escribo una línea del código para crear una nueva forma, como una pelota, y Windows creará una ventana con un tamaño específico, con una barra de menús, una barra de título, y algunas funciones. Y eso si que yo no escribí nada de eso en la línea, sólo tuve que ejecutar ese código para que me diera todo ese resultado.

Con DirectX necesitas escribir 1 set de códigos, porque correrá en cualquier tarjeta de video, incluso en tarjetas de video que tienen diferentes maneras de poner sus características en ejecución. DirectX llamará a los drivers respectivos de la tarjeta de video, y éstos convertirán ese código a otro microcódigo para esa tarjeta de video. O idealmente así debería trajajar . Tengamos en cuenta que no todas las tarjetas de video soportan todas las características de una versión de DirectX, es el caso de la GeForce 4 MX que no soporta ni con magia DirectX 9.0c. Cada nueva versión de DirectX posee cosas que la versión anterior no puede hacer, y soporte de característas que la anterior no tiene.

Por ejemplo, DirectX 8 Tiene soporte hasta Shader Model 2.0, pero DirectX 9 lo tiene hasta la versión 3.0.

Actualmente DirectX se extiende más allá de las tarjeta de video: también cubre el sonido, input, y otras cosas en el PC. Está Direct3D, DirectInput, DirectSound, DirectMusic, DirectDraw (gráficas 2D), DirectPlay (red), y probablemente algunas más.

OpenGL (Open Graphics Library) es similar a DirectX, pero sólo cubre las gráficas. También permite que los desarrolladores vayan a un código más simple, además de programar para tarjetas específicas como opción. Imaginen que si yo programara en OpenGL, pudiera agregar un código hecho específicamente para las tarjetas Nvidia. Por ejemplo: Wolfenstein corre bajo OpenGL, y en las opciones del juego hay como una opción de niebla que está sólo disponible para las tarjetas Nvidia que lo soporten. ATI y Nvidia proveen gran cantidad de códigos personalizados para OpenGL y DirectX, pero Nvidia más con OpenGL y ATI con DirectX. Es cosa de preguntarse porqué Half-life 2 tira más fps con tarjetas Radeon que con Geforce. También se involucran los drivers, en donde éstos son prueba de la eficiencia de un HAL como OpenGL o DirectX.

También hay otras API (application program interface = Programa de interfaz de aplicación, casi lo mismo que el HAL pero para programas) de alto nivel como OpenAL que es usado para el sonido.

3) Resumiendo…

Game Engine es un concepto abstracto: nos referimos a un conjunto de códigos de gran, gran extensión y dificultad. Nos referimos al tronco de un árbol. La utilidad que tiene es muy simple, pues si queremos cambiar la jugabilidad, sólo debemos cambiar el color de las hojas del árbol y reposicionar las ramas. Cuando el engine tiene datos, debe mandarlos a las respectivas zonas como la pantalla, los parlantes, etc. Entonces, se comunica directamente con los HAL como DirectX, este a la vez con los drivers de los componentes del PC, y por último los drivers con el hardware asociado.

Estos manejan los gráficos, el sonido, la comunicación de redes, las animaciones, etc. Además, es quien le pide a la CPU que realice cálculos para que pueda mostrar la información ya sea en la pantalla u otro periférico.

Realmente, todos los juegos han tenido engines, como el Pong. Pero se debe su brusca evolución a los usuarios que crearon modificaciones a los engines. Especialmente con Half-life y el mod Counter-Strike, ya que permitieron demostrar que los engines eran totalmente flexibles, y esto permitió mayor interés en su mejora.

Gracias por darse el trabajo de leerlo entero

Agradeciemientos:
Gamespot forum: ResidentBio, teh_destroyer, Dkittels, Byshop, ah
ren, Aussie_kid_2, ChronoGearSolid, Shoota_McG, chicotec, HurricaneHugo, Teufelhuhn, jessecarmack.
IGN forum: Fox451, wazzledoozle, Eric998765, Chuken
DevMaster Forum: EDMack, Anubis, Hottie, Blazer, Nautilus.
Agradecimientos especiales:
Bladder por tremenda explicación, Nautilus por aclaraciones, Fox451 por más aclaraciones, Dkittels por el “para qué sirve” y “evolución del engine”, Amenadiel por el jugo, Snidel por unas aclaraciones.

Fuentes
Extreme Tech Game Engine Anatomy 101
DevMaster.net Forum
Wikipedia.com
IGN Forum
Gamespot Forum