ENGUINITY

Parte I

Hoja de Ruta para el Futuro, o Como Voy a Perder las Siguientes Semanas

Has jugado Half Life de Valve Software? Es uno de mis juegos favoritos. El gameplay en si mismo es el estándar del género ( First Person Shooter ), pero la atmósfera y el estilo del juego… las sucias e irritablemente solitarias instalaciones; las maravillosas secuencias de guioncitos ( como cuando el científico es asesinado por el monstruo de tentáculos en Blast Pit - Amo esa parte ); las veces en las que estas escondido a medias en una esquina, ocultándote de los marines y aliens, envueltos en un bombardeo masivo. Si fuera un libro, no lo podría dejar de leer; me di cuenta de ello cuando estaba persiguiendo al Gonarch a través de los túneles de Xen con mi RPG, growling.

No? Quizás te gustan juegos relacionados como, Opposing Forces o Blueshift? Guiando al marine perdido Adrian Shepherd para pasar entre monstruos asquerosos que Freeman encontró, pero con un arsenal mejorado a tu disposición para ayudarte. O encargándote de otro día en el trabajo como el guardia de seguridad Barney Calhoun, arriesgando la vida para sacar fuera a los científicos de forma segura ( aunque aquellos que *han* jugado saben que los científicos siempre se encontraban con… accidentes inexplicables, hmm? ).

Preferís multiplayer? Counter-Strike? es un fenómeno absoluto en el mundo de juegos online. Es uno de los (sino él) juegos online mas populares en el mundo. Terroristas contra Anti-Terroristas? en juegos de rescates de rehenes, sabotaje, asesinatos… o mas recientemente, oí de un juego llamado Natural Selection, el cual logra combinar elementos de juegos de Estrategia en Tiempo Real con la popular forma de juego en equipo deathmatch.

Ok, demasiada publicidad ( Solo acepto dinero, chicos ). Todos estos juegos tienen una cosa importante en común. En cada juego, alrededor del 50% del código es exactamente el mismo que el de los otros.

No, realmente. Si quitas todo el “contenido” ( no solo los mapas y modelos, sino también la IA, física y el gameplay ) te quedarás con mas o menos la misma cosa en cada caso. Un sistema para renderizar ambientes urbanos chicos, con un sistema de animación esqueletal, un grupo de efectos especiales, manejo de red, input, y sonido. Y eso, damas y caballeros, es el engine del Half-Life? de Valve.

Pensá acerca de lo que estoy diciendo acá, por un momento: Half-Life? y Counter-Strike? son, salvo los modelos y armas diferentes, esencialmente el mismo programa. Lo mismo son They Hunger y Sven Co-op, Todesangst y Day of Defeat... una gran cantidad de diversidad con raíz en un único código base, un único engine.

Ahora, aplica eso a tus propios proyectos. Si tenés un engine reusable como ese, la mayoría de los juegos solo se volverían una cuestión de crear mapas y modelos nuevos ( o lo equivalente para tus proyectos); tareas de bajo nivel como inicializar DirectX u OpenGL y leer cosas de memoria se volverán cosas del pasado, ya que solo tendrás que usar el código que escribiste previamente.

Odio comunicarte esto, pero todo el conocimiento de la API Win32 que adquiriste probablemente no será muy útil en la industria; mientras mas y mas compañías se inclinen hacia la técnica profesional de “software factory”, necesitaran que escribas la porción de Windows de un engine una vez, y luego de ello serás inútil. Muchos proyectos nunca tocan las APIs de mas bajo nivel: usan un engine que haga eso por ellos, ya sea comprado o desarrollado en casa. Valve, originalmente, compró el código fuente de Quake para convertirlo en el engine de Half-Life? y como resultado nunca tienen que tocar cosas como OpenGL ya que el código de ID’s Software lo hace todo por ellos. Solamente se pusieron a trabajar en serio e integraron su contenido específico del juego ( IA, física, etc) dentro de las interfaces del engine del Quake. ( Bueno, Ok, en realidad ellos se metieron dentro y modificaron el engine para que soporte algunas características mas avanzadas como texturas de 16-bit, pero mi punto es que ellos no *tenían* que hacerlo).

Entonces, en esta serie de artículos, voy a hacer lo mejor que pueda para enseñarles como construir un engine desde cero. No voy a presentarles código solamente y decirles “llamen a la función X para hacer cosas divertidas”; para el final de estas series, no solo tendrás un engine: también lo entenderás. Entonces, prestá atención, gusano! :P

Es importante darse cuenta de que en términos prácticos, un engine no puede hacerlo *todo*: Cuantas mas cosas el engine tenga que soportar, de mas bajo nivel se vuelve, hasta que estarás solamente escribiendo un wrapper de DirectX/OpenGL. No, cuando escribís un engine, tenés que establecer algunas reglas acerca de que juegos pueden construirse con él: No podes construir Doom 3 con el engine del Half-Life?, por ejemplo, porque Doom 3 requiere algunas cosas (como iluminación por píxel) que el engine del Half-Life? simplemente no provee. Mas obvio, no podrías usar el engine del HL si estuvieras planeando un juego para GameCube?, porque HL no soporta la plataforma.

Sin embargo, es mi creencia que, ese proceso de “especialización” sucede paso a paso: un engine comienza, en su mas bajo nivel, soportando cada juego posible, y luego a medida que se le agregas mas, “converge” hacia una serie de limitaciones. Podes imaginarlo como una pirámide: la base es amplia y soporta el resto, mientras que la parte mas alta es un punto centrado con precisión, permitiendo que solo un pequeño set de juegos puedan ser construidos encima. Si removemos la mitad superior de la pirámide, nos quedaremos con una base mucho mas ancha sobre la cual podremos construir un set mas grande de juegos ( esos juegos sin embargo, necesitarán hacer ellos mismos mas trabajo de construcción ). Así un engine puede ser construido progresivamente de esa manera, agregando capa por capa.

Desarrollar requiere un cierto nivel de Enguinity (NT: juego de palabras entre Ingenuidad y Engine)

Estas series mías van a, capa por capa, llevarte a través de la construcción de un engine: como habrás imaginado, lo estoy bautizando “Enguinity” ( dispárenme cuando haya acabado de escribir ).

Aquí están los “requisitos” para el engine:

• Tiene que ser tan multi-plataforma como sea posible ( Eso es, plataformas de “escritorio” no de consola: Windows, Linux, y Mac OS X ).
• Debe ser reutilizable.
• Debe soportar comunicación entre múltiples plataformas ( Eso es, juegos en Linux pueden conectarse en red con juegos en Windows, y así sucesivamente).
• Debe estar diseñado en forma tal que sea simple agregar nuevos componentes o reemplazar los existentes, proyecto a proyecto.
• Debe andar a velocidades adecuadas en una maquina Pentium 3 1.1GHz con placa de video GeForce? 2 32Mb ( Estas son nuestras “expectativas mínimas”, o “requisitos técnicos mínimos”, mas o menos ). Mucha de la velocidad dependerá del juego que corra con el engine. Pensá: Un shooter 3D obviamente andará mas lento que un Tetris, aunque ambos sean construidos con el mismo engine.
• Debe ser diseñado de forma tal que sea bastante simple de entender y enseñar ( de otra forma podría estar hablándome a mi mismo solamente :)

Será escrito en C++, y no vamos a trabajar desde cero: usaremos SDL para gráficos ( y, así, OpenGL ), input y timers; SDLNet para manejo de red; FMOD para sonido ( por lo tanto si querés ver a alguien inicializar DirectX/OpenGL por enésima vez, andáte a algún otro lado: no se gana nada reinventando la rueda). Esto debería solucionar bastante lo relacionado con múltiples plataformas, manejos de redes, y requerimientos mínimos técnicos que son parte de las especificaciones; el resto recae en nosotros.

Sentite feliz: Podes decirle a la gente que vas a “lograr reusabilidad a través de modularización en un diseño orientado a objetos”. ( No es que no pudieras decirle a la gente eso antes, por supuesto. A menos que tuvieras la boca llena o algo. Mi punto es… en realidad, no importa).

Ninguna serie de artículos estará completa nunca sin código fuente, y les aseguro que será provisto en amplias cantidades. De hecho, los fuentes pueden cubrir más que lo que yo hablo. Podes encontrarte con cosas con las que he jugado antes de decidir no discutir sobre ellas: como las sobras de mis intentos de construir el engine como una DLL bajo Windows, y otras ( usualmente bastante irrelevantes) cosas que podrían servir para confirmar tus temores de que no se de que demonios estoy hablando.

No puedo hacer hincapié lo suficiente en el hecho de que un engine es un tema enorme y bastante complicado, y los principiantes no beberían siquiera pensar en afrontarlo hasta que no sean completamente competentes con el lenguaje (C++). Ponelo de esta forma: Si podes entender que es “una clase template que hereda de múltiples clases bases virtuales y sobrecarga el operador puntero-a-miembro”, entonces estas listo. Si no, entonces lo siento, pero simplemente no entenderás algo del código y técnicas de diseño que voy a usar en las series. Sos bienvenido a echarle un vistazo a lo que puedas, pero no voy a descender al más bajo nivel acá; si gasto todo mi tiempo explicando conceptos del lenguaje, no tendremos nada terminado.

Cual es el propósito último de esto, entonces? Pienso que construir un game engine no es ni de cerca divertido, a menos que construyas un juego sobre él también ( porque, pongámoslo en claro, game engines de propósito general es lo que hacés cuando no tenés ideas para juegos). Por lo tanto, lo que trataré de hacer es, en momentos oportunos, construir juegos simples ( estamos hablando de *realmente* simples) con el engine en el estado en que esté en ese momento. Podes pensar en ellos casi como hitos en el proceso de desarrollo.

Eso es todo lo que tengo que decir para este artículo. La semana que viene, les daré un repaso de los “cimientos” de un engine, y cubriré algunos de los temas fundamentales, como logueo de errores y manejo de memoria. Mientras tanto, querrás ir estudiando y bajando SDKs de los siguientes lugares:


http://www.libsdl.org/ - SDL y SDLNet ( SDLNet en la sección de librerías ).
http://www.fmod.org/ - La pagina de FMOD.
http://nehe.gamedev.net/ - Los famosos tutoriales de OpenGL de NeHe? ( de novato a pro en 60 minutos o algo parecido).

Richard Fine ( rfine en turf dot net )

Este artículo fue posteado en Gamedev.net el 5/28/2003. Fecha que no necesariamente corresponde con la fecha en la que el artículo fue escrito.