lunes, 27 de agosto de 2007

Comienza el proyecto

Comenzó Agosto, y con él mi último proyecto de programación: Avioncitos 3D. El origen de este juego se remonta a los días, no tan lejanos, cuando con RT jugábamos Strikers 1945 en su casa después de los ECOEs. Avioncitos 3D está inspirado en los juegos de este tipo, por lo que he decidido hablar un poco de lo que tienen en común y en lo qu se diferencian..

De partida Strikers 1945 es un juego de Arcade, emulado en MAME, similar a la mayoría de los juegos de aviones en scroll vertical. Cuenta con las típicas bombas que arrasan con todo en la pantalla, los powerups, y el jefe grande al final de la etapa. Lo que le otorga cualidades especiales respecto a los demás del género, tal vez sea el Super Shot y la gráfica un tanto superior. Realmente es un juego adictivo, donde más que volar un modelo real de avión, lo que se consigue es movilizar endemoniadamente el aeroplano entre nubes de balas enormes y coloridas. Si bien el avión realiza maniobras fisicamente imposibles (retrocede fácilmente), esto le otorga la gracia al juego: Evadir millones de disparos a gran velocidad. Como todos los juegos del género, cuenta con enemigos en tierra y en aire, donde en realidad. las balas les afectan simultáneamente a ambos, de modo que el efecto de profundidad es sólo simulado. Realmente los movimientos ocurren en un solo plano.

Con Avioncitos 3D he pensado en recrear la lógica del juego, volando un avión de manejo estereotipado a través de escenarios plagados de enemigos y proyectiles. Avioncitos 3D NO ES un simulador de vuelo. Es una versión de un juego de scroll, salvo que todo ocurre en tres dimensiones. Dada la intensidad de las escenas 2D, me pareció sumamente interesante lo que podría llegar a ser volar en un campo de batalla tridimensional.

¿Por qué avioncitos?

Cuando pensé en hacer mi propio juego, decidí que fuera de aviones porque: 1) Me encantan los aviones y todo lo que tengan relacionado. 2) Por que tenía ganas de tener mi propia versión de Strikers 1945 y 3) Porque los aviones son cuerpos sólidos que requieren mucha menos animación que personajes más biológicos.

Una vez decidido a comenzar a programar, la pregunta fue ¿Cómo hago un juego en 3D?.
A los que se dieron la lata de leer mi historia, les quedará claro que he tenido bastantes acercamientos a la tarea de programar, pero que nunca me he dedicado en serio a aprender ningún lenguaje. Al momento de comenzar el juego ya tenía decidido que sería en 3D, por lo que al menos la API estaba decidida; DirectX8, por ser aquella única en que logré renderizar algo alguna vez (Super Bong, por el año 2005.. Vean mi historia en la primera entrada.)
Después de mi aproximación inicial a DirectX8 con VB, lo dejé de lado y comencé con C#, lenguaje del que algo aprendí, pero bastante poco. Al momento de decidir hacer el juego de avioncitos, pensé en aprender DirectX9 y usarlo con C#, pero claramente esto significaría invertir más tiempo del presupuestado en aprender. Finalmente, después de un fin de semana completo bajando y leyendo manuales de DirectX8, opté por comenzar con esta API en entorno Visual Basic, que era a lo que más estaba acostumbrado. A medida que el programa creciera, pensaría en migrar a una API más reciente y a un lenguaje .Net.

Recordando viejos tiempos

Desde hace siglos no escribía una línea de código, hasta que un buen fin de semana busqué en CD del Visual entre las cajas de CDs viejos y lo instalé. Lo más elaborado que había creado en geometría hasta entonces, era un paralelepipedo que servía de paleta en Super Bong (un Pong en 3D). Sabía que de ahí a dibujar aviones había una diferencia enorme, por lo que pensé en cómo solucionaría el problema de los modelos. Por lo que había leído, la solución inteligente era usar un software de modelado 3D e importar los mesh com archivos .X . De todas formas, yo soy un poco más impaciente y no quise ponerme a estudiar modelado 3D primero(Según sé, cuesta bastante dominar el 3D Studio Max)así que decidí por dos opciones: Crear modelos a mano bastante sencillos, pero entendibles; o bien, crear en Visual Basic mi propia herramienta para diseñar modelos 3D de manera sencilla. Me gustó la idea, pero antes de lanzarme a crear mi propio software, debía recordar como se hacía a la antigua, por lo que me dispuse a crear un modelo simple, especificando la geometría a mano, vértice por vértice en un array de este tipo.

...Para los que no entiendan mucho del tema, al menos en DirectX, toda la geometría está basada en triángulos, por lo que para construir una figura, se deben especificar las coordenadas de cada vértice, los que el programa luego completa y da forma en un ambiente 3D. Hay una manera fácil de hacerlo (con un programa con que uno sólo dibuja, y luego automáticamente se generan las coordenadas); y una difícil y poco clever, que es imaginar el avión, luego imaginarlo dividido en triángulos, para luego imaginar cada vértice en un sistema cartesiano de tres ejes, y finalmente meter al PC todos esos números....

Primer día de trabajo

Cuando tuve inicializado el motor de D3D, comencé a diseñar mi modelo de prueba. Un avión sencillo basado en un paralelepípedo central como fuselaje (hasta ahora no había hecho más que esas figuras). Tendría un par de triángulos por lado, por tanto 8 primitivas para el fuselaje. Luego cuatro triángulos cerrando el "cilindro" por delante, le darían apariencia de avión. Cuando terminé de dibujar esto, el resultado me sorprendió bastante. Se veía mucho mejor de lo que creía, para ser una primera vez. Me emocioné y agregué un par de triángulos para crear cada Ala (dos planos triangulares montados uno sobre el otro con ligera angulación). Al final me decidí y agregué los planos de cola y el estabilizador horizontal. Algunos triángulos más sirvieron para simular el escape. Cuando pulsé F5, ya tenía mi propio avión hecho a mano. Le tomé fotos por todos los ángulos y terminé de convencerme que sería la manera a la que generaría toda la geometría del juego. A pesar de ser claramente un avión extraño y muy triangular, le tomé cariño y decidí adoptarlo como el primer avión del juego. Se ganó el nombre de Sw71. (Sw viene de Sewoldt, la compañía que lo fabrica XD).






Las imágenes de arriba corresponden a las primeras tomas del primer modelo del juego. Como vi que funcionaba, decidí crear un segundo avión. Esta vez sería un jet de ala en delta. Fue así como el mismo día (o tal vez uno después) apareció la segunda nave de la bandada el SwXX Pyrage. (nunca le di mucha importancia a los nombres. Es muy probable que cambien de aquí al final del juego. Es la gracia de ser mi propio jefe en el proyecto.)
Finalmente, el 9 de Agosto de 2007, creé el último modelo. El Sw28 Shark. Decidí cambiar el color del Sw71 a rojo, para dejar el amarillo al último avión. Este modelo mostró la evolución que ocurrió durante ese par de días. Tiene un grado de teselación mayor, lo que otorga bordes rectos más alejados de la apariencia triangular del Sw71. Las alas tienen considerablemente más trabajo (6 triangulos por ala), por lo que son estéticamente mejores. El Shark toma su nombre de la forma de su cola, la que es alta y triangular, remedando la aleta de un tiburón en el agua.. .(con un poco de imaginación tal vez...).
Cuando estuvieron los 3 aviones creados, apliqué un par de transformaciones, moví unas cuantas matrices y dejé los tres aviones juntos en la pantalla. El Sw71 se encontraba al medio, mientras era escoltado por el Pyrage y el Shark a los costados, cada uno describiendo un roll contínuo hacia afuera. Había logrado crear geometría y animación simple a partir de matrices. Era un indicio de que el sueño imposible, tal vez podría hacerse realidad.

El siguiente snapshot muestra la escena recién descrita, donde aparecen los tres aviones en formación. Un logro muy bienvenido después de tanta incertidumbre. Gracias a esta escena, me di cuenta que había valido la pena lo estudiado, y que sería factible continuar. Por tanto, esta historia continuará.

jueves, 23 de agosto de 2007

Quien Soy (Parte II)

Continuando con lo anterior....

Una de las cosas que me venía llamando la atención desde hace un tiempo era DirectX. Cada vez que instalaba un juego nuevo, debía ceremonialmente instalar el componente, aunque no sabía ni qué era, ni para qué servía. Otra cosa que me sorprendió en ese tiempo fue el comienzo de los juegos en 3 dimensiones. Hasta entonces yo comprendía bien que en 2D bastaba con poner algunos sprites contra el fondo y hacerlos moverse. Las animaciones eran claramente una sucesión de frames, similares a las que yo hacía en las orillas de los cuadernos; pero en 3D era todo distinto e incomprensible. Varias veces hice animaciones pseudo3D, en realidad era solo cosa de perspectiva, pero en el 3D real, podía rotar por todo el espacio, ver cada imagen desde infinitos ángulos y nunca parecía una figura plana en perspectiva. Mi primer acercamiento a este tipo de aplicaciones fue un programa para diseñar ambientes de hogares. En mi rudimentario 286 de 10 Mhz (creo que con turbo subía a 20, era un notebook acer, cuya pantalla estaba mala y proyectaba sobre un monitor externo) tenía un software similar, permitía hacer planos de habitaciones, ingresando comandos en un consola, los que se graficaban en monocromático en una especie de plano. Del programa que hablo ahora (Win95), tenía funcionalidad parecida, salvo que todos los comandos eran del tipo Drag & Drop y finalmente uno podía convertir ese mundo en 3D y recorrerlo a su antojo. Recuerdo que el programa andaba lento y el PC se solía pegar siempre, pero estaba mostrando algo en 3D, lo que realmente me motivaba.

Los primeros juegos en 3D que usé, solían tener elaboradas iluminaciones y "materiales" interesantes en sus polígonos, pero pocos incorporaban texturas. Debido a esto, la sensación de realismo era bastante inferior a la lograda con los 2D y sus sprites elaborados e incluso fotorrealistas (fue increíble cuando en Mortal Kombat lograron meter personas reales al juego!!!), por lo que a pesar de la tridimensionalidad, parecían figuras plásticas y requería imaginación pensarlos como personajes.
Hubo un juego de carreras de autos que me emocionó. Era un demo de Rally, en 3D y con buena geometría. Cada auto estaba bien construído y se veían bastante naturales las curvas, respecto a lo poligonal que acostumbraba a ver. Pero lejos lo que más me sorprendió fue el uso masivo de texturas en los modelos. Comparados con juegos de ahora era realmente primitivo, pero el hecho de tener un mundo 3D, totalmente texturizado era sumamente atractivo, y lo más cercano a la realidad.

Mi pasión simpere han sido los aviones, por lo que un título infaltable en mi colección fue el MS Flight Simulator 98. Aprendí mucho de aviones con él (Creo que es el FSim con la mejor ayuda de la serie). Más de alguna vez estuve a punto de decidime por estudiar para ser piloto (aunque ahora estudio medicina) y creo que mucho influyó el simulador de Microsoft. En algún momento conseguí un editor de texturas para el Fsim, y pinté los aviones a mi gusto. Podría haber sido el primer paso en mi idea de diseñar mi propio simulador de vuelo.

El gran salto cualitativo ocurrió en esos tiempos, digamos año 1997. Un buen día llegó a mis manos un CD y un libro cuyo título prometía mucho: Aprenda Visual Basic, ¡Ya!. Con Juan estuvimos harto tiempo investigando el programa, siguiendo los ejemplos del libro y aprendiendo porfina a programar en Windows. Él sabía bastatne más que yo, pero a pesar de las farimañas y adornos, controles, eventos y cosas nuevas, el resto seguía intacto. En el corazón del lenguaje estaba el mismo Basic que yo había aprendido años atrás.
Ese libro se convirtió en mi biblia dirante mucho tiempo. Dejé de lado los módulos de clase y los enlaces con bases de datos de Access, centrándome sólo en la programación básica y en la parte gráfica, aunque a pesar de ser un lenguaje basado en Windows, las funciones gráficas del VB eran bastante limitadas.

El editor de VB que tenía en ese tiempo era una demo de la versión 4.0. Se llamaba modelo de evaluación, y sólo permitía crear un único formulario, y no posibilitaba crear archivos EXE. De todas formas, todo ese año y el que le siguió, permanecí programando en ese VB.

Con el tiempo aprendí varias cosas e hice algunos buenos programas para cosas del colegio. Cuando pasaba por genética, decidí hacer un simulador de evolución, que según el ambiente seleccionaba los fenotipos apropiados y eliminaba al resto. Funcionaba bastante bien, aunque la parte gráfica seguía muy deficiente. VB como tal solo ofrecía controles Picture e Image para cargar Bitmaps. Podía poner algunos controles de este tipo y moverlos por la pantalla, a la vez que reemplazaba cada imagen con una copia similar muy rapidamente, para lograr el efecto de animación.
Con esta técnica logré esbozar algunos "juegos", pero realmente estaba lejos de conocer una estructura correcta para elaborar un motor de juegos. En ese entonces, mis programas eran poco modulares y bien procedurales, con un nivel de abstracción muy bajo y difíciles de entender. Por otra parte, la gráfica siempre me complicaba, pues no conocía técnicas para lograr Color Key, razón por la cual, todos mis sprites estaban rodeados por un cuadrado de color. Para solucionarlo, pintaba este "fondo" del mismo color que el del fondo real sobre el que pondría el sprite. Así, el helicoptero siempre tenía un fondo color cielo, el cual no podría variar. El problema ocurria cuando se me cruzaban dos sprites, entonces se notaba claramente su naturaleza cuadrada.

Recuerdo una vez, por ahí en el año 2000 o 2001, cuando volví a programar después de bastante tiempo. Estuve enfermo y alejado del colegio casi una semana, por lo que debía hacer algo con mi tiempo libre. Recordé haber leído en una revista sobre un programa que generaba un mundo a partir de datos al azar. Tenía algoritmos para hacer árboles, casas.. Una cosa como un mundo procedural. Cuando estuve enfermo, decidí aplicar la idea para hacer un juego sobre avión que navegara por un mundo que se autogenerara azarozamente. Dado el eterno problema de los sprites cuadrados, decidí enfrentar el problema con lo que tenía: Shapes. Resulta que VB tiene un control Shape que permite crear cuadrados y óvalos y modificarles algunos parámetros. A pesar de su poca flexibilidad, no estaban inmersos en un cuadrado, por lo que me resultaban ideales para crear imágenes que se superpusieran sin interferirse fuera de sus límites reales.
El problema de la superposición se solucionó en parte. El asunto se volvió que un avión hecho de óvalos y cuadrados no sería visualmente muy elegante. Como solución decidí usar un Dirigible como personaje.
Recuerdo que todo funcionó parcialmente bien. Las nubes, árboles y demases se ubicaban en posiciones al azar, con colores aleatorios en paisajes autogenerados. No recuerdo si tuve suerte en volverlo un juego, ya que siempre me complicaron las colisiones y el scroll. Después de eso dejé VB por largo tiempo.

Creo que fue al final de mi último año de colegio (2003) cuando comencé a buscar ayuda en internet. Descubrí cientos de páginas con cursos de todo, todo gratis, todo bien explicado. Encontré por ahí una página que hablaba de juegos con VB. Comentaban que no era un lenguaje ideal para esos propósitos, pero que si de todas maneras se quería hacer algo, entonces BitBlt era indispensable.

Yo no tenía idea a qué se referían con BitBlt. Entre todas las funciones del Visual que conocía, niguna se le llegaba a parecer. Dado que convertí a internet en el maestro que busqué por años, lo utilicé para investigar más sobre esta función que parecía ser alabada por los verdaderos desarrolladores en VB. Recuerdo la primera descripción que leí: "BitBlt es probablemente la función más feliz de la API de Windows". Eso me mostró dos cosas: Estaba ante algo potente, y ese algo requería estudiarse para poderse entender.
Cuando aprendí a usar BitBlt, gané el poder para transferir bloques de bits (de ahí el nombre simpático: BitBlt = Bit Block Transfer) a cualquier device context (DC) de Windows. Cuando creaba controles en VB, automáticamente se creaba un nuevo DC, por lo que tenía el poder de poner imágenes donde nunca antes pude. Gracias a las varias ROPS (raster operations) que conocí, logre al final crear sprites a partir de dibujos de Paint, con un fondo transparente que dejaba ver lo que había más atrás. Desde ese momento dejé de usar controles Picture para mostrar imágenes. Bliteaba todo al DC del Form, con lo que logré componer escenas bastante atractivas. Entre tanta página que visitaba, terminé incluyéndome en un proyecto para crear un juego en comunidad, aportando ideas y código a través de un foro. Ahí aprendí a usar otros trucos de la API de Windows, pero además conocí y por fin entendí una API mucho más poderosa que venía intrigándome desde años atrás: DirectX.

DirectX7 simepre me costó bastante. Recuerdo que la referenciaba sólo para obtener la única función que manejaba bien: TickCount. En mis primeros juegos en BASIC, los intervalos de tiempo los calculaba mediante "For...Next", sumamente impredecible. Con VB hasta ese momento manejaba los tiempos con el Timer, el que lamentablemente perdía precisión manejando intervalos cortos. Una vez, estudiando el código de una animación del proyecto en que estaba trabajando (Se llamaba proyecto Alpha, programaba gente de todo el mundo) encontré que el manejo de los tiempos se realizaba mediante el TickCount, y que nadie usaba el Timer. Me di cuenta que el TickCount era sumamente preciso y confiable, y menos engorroso de implementar que un control Timer (Recuerdo mis formularios con 20 o 30 de estos controles, cada uno con su propio código autónomo interrumpiéndose mutuamente. Era un desastre, pero era lo único que tenía.) Cuando aprendí a usar el TickCount, mi primer programa fue un simulador de helicóptero. Ahora que tenía un control del tiempo con precisión de un milisegundo, no costaría demasiado crear una simulación semirrealista del vuelo idealizado de un helicoptero. todavía recordaba bastante bien varias fórmulas de cinemática y dinámica que servirían, por lo que un día desperté feliz y me dediqué a programar el motor de física.
Otra novedad importante en este juego fue la manera de estructurarlo. El haber colaborado en un proyecto mundial (aunque se canceló y ninguna línea de código fue mia) me permitió aprender a trabajar de modo modular. Con proyecto Alpha un tipo en USA creaba la física, otro en Europa el sonido, mientras yo estudiaba en Chile la manera de crear un Render decente para el proyecto. Con la estructura de mis programas era imposible que alguien colaborara conmigo. Cada función se mezclaba con otra en procedimientos enredadísimos, que a veces me impedían continuar cuando ni yo mismo me entendía. En cambio en proyecto Alpha todo iba en su módulo bien organizado. Cada programador debía sólo conocer la documentación de las funciones que realizaban los demás, sin entender su funcionamiento. A veces el tipo de Inteligencia Artificial le pedía al de física que creara una función de tal forma, a los pocos días el de física devolvía un ZIP en el foro con la función, el de AI la agregaba y trabajaba sobre ella sin involucrarse en su construcción. Este tipo de trabajo yo nunca lo había visto, y si bien, mi proyecto de Helicópteros era a nivel personal, también se beneficiaría del trabajo modular. Por primera vez cree subprocedimientos para cada acción, evitando esos listados interminables de código en una sola función. Si algo no gustaba, se cambiaba sin modificar al resto. Realmente fue un aporte el haber aprendido a trabajar así.

Lo del Helicóptero me tomó un par de días antes que me aburriera. La física funcionaba bien. leía perfecto las entradas del teclado y el Render, aunque sencillo, funcionaba perfectamente hasta entonces. Por primera vez incorporé la lógica de mi juego en un Loop, volviéndose muy similar a los motores de juegos "reales". Hasta entonces el programa corría bien como simulador, pero le bastaba bastante para ser jugable. Decidí mejorar los escenarios. Agregué edificios que hacían scrolling por la pantalla. Todos colisionables y wur permitían posarse en ellos (con el cuidado necesario para no destruir el helicoptero en el intento). Lo agradable era que todo estaba hecho en Paint, por lo que bastaba con modificar el bmp de origen para darle un look nuevo al juego, sin cambiar nada de código. Todo además era bastante paramétrico. Si quería agrandar un edificio, cambiaba sólo un número y el motor de juego se encargaba automáticamente de detectar las colisiones en otro nivel, etc. Cambié el Render varias veces sin tener que tocar una sola línea de código en el resto del programa. El problema apareció cuando la complejidad se hizo tal, que era incapaz de blitear un frame tras otro sin que se notara el corte.
BitBlt se estaba quedando corto para mis propósitos. Debía buscar una solución o mi juego se estancaría. Cuando estuve leyendo sobre DirectX, había aprendido bastante teoría, y sabía que los BackBuffers eran precisamente lo que necesitaba. El problema es que ni Visual, ni la API de Windows, ni nada que conociera soportaba backbuffers, excepto DirectX. Durante un buen tiempo traté de hacerle el quite a esta API. Me parecía poco práctico aprender de cero en la mitad de un proyecto. Además, no se veía fácil por lo que había investigado, por lo que decidí hacer un híbrido entre lo que sabía de VB, BitBlt y lo que pudiera aprender de DX7 en esos días. Recuerdo haber inicializado DirectDraw (La parte de dibujo de DirectX7) como había visto hacerlo a los tipos de proyecto Alpha. Luego creé unas cuantas Surfaces, y un set de BackBuffer y FrontBuffer. Hasta ahí con DirectX. Conservé la lógica de juego y la física original del juego en VB, y sólo pretendí modificar el Render. Como de cargar imágenes en surfaces no sabía mucho, decidí usar el BitBlt de Windows en vez del equivalente de DirectDraw. Al final nada resultó. BitBlt no era capaz de copiar en las surfaces de DirectDraw, a pesar de todos mis esfuerzos. Traté de crearles un DC compatible con funciones de la API, estuve mucho tiempo en eso y no funcionó. Me frustré y abandoné la idea de aprender DirectDraw. Terminaría mi juego como pudiera.
Hubo un momento en que comprendí que BitBlt había tenido su momento, pero que ahora necesitaba cosas mejores. No tenía sentido aferrarse a una función que me siguiera limitando. Después de todo, estaba haciendo todo eso por aprender. Hay un post por ahí en un foro (que todavía aparece si se busca en google) donde pido ayuda con mi problema con BitBlt y su poca velocidad. La respuesta fue categórica: "Aprende DirectX".

A partir de entonces, me dediqué a leer lo que encontrara de DirectX7 para aprenderlo cuanto antes, después de todo, por no saber Dx no había podido colaborar más con Proyect Alpha. en una de esas tantas búsquedas, encontré algo que me interesó aún más. Era un tutorial muy bien hecho donde enseñaban DirectX8. Ya no existía DirectDraw, desde Dx8 todo era 3D. Obviamente lo bajé y ese mismo día terminé de leerlo y hacer todos los ejemplos.

No ha pasado tanto tiempo desde que hice mi primer cubo coloreado que giraba y giraba infinitamente. La lógica de programar en 3D me fascinó, y abandoné el helicóptero. En vez de eso, hice un juego de Pong en 2D usando los Shapes de VB, con la salvedad que todo corría en un Loop que finalizaba en dos Render alternativos. El primero simplemente organizaba los shapes para que simularan la situación actual de la escena. El segundo hacía exactametne lo mismo, pero en un entorno 3D. La pelota era un cubo rojo que corría en una cancha azul, sólo delimitada por 4 líneas en el espacio. La cámara se podía mover libremente y hacía un efecto de "Super Switch", alternando repetitivametne entre la perspectiva del jugador y su oponente. Agregué un efecto Stealth, donde la pelota desaparecía en la mitad de la cancha, para luego aparecer sorpresivametne en los últimos segundos. Todo esto lo volvió un juego bastante interesante, del que compilé una demo que envié a un amigo para probar. Le intenté agregar soporte para juego en línea, pero nunca resultó, en parte porque no tenía dos PCs para ir probando. El juego se llamó Super Bong y aún lo conservo. Ha sido mi único juego en 3D, hasta ahora......

Terminó ese verano, y con él las posibilidades de seguir programando. Cuando volví a Santiago, tomé un curso de programación en la escuela de Ingeniería de mi universidad. Era el ramo terror de los ingenieros novatos, quienes debían aprobarlo en su primer año. Esto me hizo creer que ofrecía mucho y decidí tomarlo como electivo. Son 10 créditos de los que no me arrepiento, a pesar de las advertencias de mis amigos acerca de no tomarlo.
En ese curso aprendí bastante, de hecho, aprendí un lenguaje distinto y una filosofía totalmente nueva. Me enseñaron C# (C sharp), un lenguaje de Microsoft para su Framework.Net. Hace tiempo que venía leyendo sobre esta "cosa nueva" .Net; ya sabía de un Visual Basic.Net al que nunca me atreví a conocer más a fondo. Ahora, aprendiendo C#, conocí la filosofía .Net y la verdadera orientación a objetos. De principio me chocó un poco el cambiar toda mi forma de pensar un programa. Al comienzo intentaba aprender creando analogías con lo que ya sabía, pero al poco timepo comprendí que era necesario desprenderse del legado del BASIC y comenzar de cero con mentalidad nueva. El C# era un lenguaje basado en el C, esa cosa que tanto anduve buscando en mi niñez, potenciado para Windows y el FrameWork.Net. El hecho de vincular todo con internet me motivó bastante, puesto que había comenzado a esbozarse un proyecto de empresa de diseño Web con un amigo. Al final aprendí bastante en ese semestre y la orientación a objetos me gustó tanto que me costó imaginar cómo hubiese hecho las mismas cosas con Visual Basic años atrás. En mi proyecto final, junto a tres compañeros creamos un juego de futbol en tablero, cuya Clase de gráficos estuvo a mi cargo, y donde debí aprender bastante de aquello. Para lograr trabajar con algo más familiar, encapsulé las funciones graficas del C# en algo a lo que estaba más acostumbrado: Le agregué un BitBlt. En resumen, aprobé el curso y me quedé con el conocimiento de algo nuevo. No soy muy persistente, así que no seguí practicando. Al final dejé la programación un poco de lado para dedicarme a la música y la literatura, y obviamente a la medicina que se volvió muy demandante.

Después de todo esto, pasó un buen tiempo y ahora estoy en 4to año, con las esperanzas de ser un gran Doctor (Soy medio Médico, en la mitad de la carrera). Este semestre he tenido un poco más de timepo libre, lo que provocó que comenzara a retomar mis pasatiempos pasados. Me decidí a comenzar un nuevo proyecto en programación, para seguir con el aprendizaje y lograr plasmar en algo concreto todos los años de trabajo. Después de tanta presentación (y un poco de nostalgia mientras escribía) aquí comienza el texto sobre lo medular de este Blog: El proyecto Avioncitos 3D.

Quien soy (parte I)

Este es el Blog oficial del proyecto Avioncitos 3D.
Me presento, Soy Sebastian Ewoldt (Sewoldt) y este es mi primer proyecto de un juego en 3 dimensiones...



Hace muchos muchos años, debo haber tenido unos 9 o 10, llegó a mis manos mi primer PC (era eso??) un ATARI 800XL. Recuerdo haber estado horas frente al televisor, con el fondo azul y un cursor blanco, tratando de entender qué podía hacer con el juguete nuevo. Hace tiempo que venía sabiendo que los computadores se programaban, que era cosa de aprender, para tenerlos haciendo lo que uno quisiera. Siempre me intrigó el poder entenderme con una máquina, tenía nociones básicas de cómo funcionaba, solía "programar" toda cosa que pestañara en "12:00", videograbadores, radiorelojes y cosas de ese estilo. Recuerdo que años atrás, me había llenado de alegría el poder programar el VHS para grabar a determinada hora; en fin, era agradable la sensación de poder sobre una máquina, pero ahora, a mis 10 años, tenía una pantalla azul esperando mis instrucciones, y no tenía la menor idea de cómo hablarle.
Con la ayuda de mi padre, aprendí las primeras nociones de la lógica de programar. Me presentó algunas funciones básicas, los primeros controles de flujo.. Creo que al final del día terminé logrando una sencilla calculadora.

Gracias que en esos tiempos no había mucho en qué distraerse, ni TV buena, ni juegos de PC; mi pasatiempo se volvió el leer un libro que venía adjunto con el ATARI: Un manual de referencia de lenguaje BASIC. Conforme pasaron los días, los programas se hicieron cada vez más sofisticados, y comencé a conocer las bondades de programar con sólo texto. Pero a mí me movía algo superior: Siempre quise hacer un juego, y para eso necesitaba potencia gráfica.
Recuerdo un día glorioso que marcó esta etapa. Buscando entre los ejemplos del libro, encontré un programa que utilizaba las funciones gráficas del BASIC para mostrar el logo de ATARI. Después de haber copiado el ejemplo, encontré en éste la información que quería. Conocí el PLOT y el DRAWTO, Graphics 3, SetColor (0,2,8), (no sé porqué esos parámetros se quedaron hasta hoy en mi memoria). Sin saber completamente lo que estaba haciendo, empecé a echar mano del programa y a manipularlo a mi antojo. Comprendí el sistema de dibujo con coordenadas. El hecho de que cada imagen estuviera formada por una colección de puntos coloreados era bastante evidente en el logo Atari que mostraba el programa.

El paso siguiente fue dibujar a voluntad. Tomé un papel cuadriculado y comencé a dibujar pensando en pixeles. Cuando terminé todo, tenía una lista enorme de coordenadas, entonces se las pasé a una función PLOT, puse RUN y fue increíble: Había hecho un dibujo en mi televisor, sólo escribiendo números.... De ahí no paré más....

El manual del ATARI me enseñó a usar DrawTo en vez de PLOT para crear líneas. Gracias esto, los dibujos se volvieron más complejos y ya me estaba quedando corto en resolución.

Recuerdo que mi último gran logro fue un pseudoJuego de "Dos Perros Tontos" (era mi programa favorito en esos años). El televisor se ponía negro, a la vez que se dibujaban las siluetas de los dos personajes... Sonaba una música monofónica (el BASIC permitía tocar las notas que uno quisiera, a intervalos que nunca pude definir bien, más que poniendo ciclos for next vacíos entre ellos. Yo tocaba flauta dulce y sabía muchas canciones y sus partituras, siempre consideré agradable que mi televisor las tocara por mí). Al tiempo, despues de un retardo con un buclé vacío, el fondo se llenaba de estrellas (dibujé puntos toda la tarde) y el programa acababa.. Se lo mostré a toda mi familia... No sé si comprendieron lo importante que era para mí, pero yo estaba feliz... En ese televisor estaban pasando las cosas que yo quería.... Ya no era más la caja tonta... Ahora yo tenía el control..

Con los años fui creciendo y nunca más pesqué mi ATARI. Me había leido el libro muchas veces y no tenía nada nuevo de donde aprender. No existía internet como ahora, y la biblioteca de mi casa nada tenía de computación. Mi papá no sabía mucho más que yo. Durante la universidad había aprendido BASIC para usar su calculadora programable, pero de gráficos no tenía idea. Creo que jamás conoció el poder de PLOT. Pasaban los días y yo seguía con la misma grilla de ¿serán 50 x 50? pixeles, que ya no me satisfacía. Sentía que para lograr un dibujo creíble, necesitaba achicar los pixeles hasta hacerlos indistinguibles, estaba dispuesto a plotear 1000 coordenadas si era necesario, pero me faltó un buen maestro y me estanqué.

Conocía a una amiga de la familia, que ahora trabajaba de secretaria, y hablaba simepre de computación. Como gran novedad escribía sus cartas en computadores, y hacía todos sus cálculos de esta forma. Pensé que encontraría en ella la ayuda que andaba buscando, pero no fue así. Con el tiempo comprendí que no era más que una usuaria de programas, pero que jamás supo algo de programación. La gente que creaba todo aquello con que ella trabajaba estaba muy lejos, jamás en Chile, infinitamente fuera del alcance de un niño Chileno de 10 años, en ese entonces.

A medida que pasaban los años, me volví usuario. Aprendí MS-DOS con mi papá y le saqué provecho a varias noches hablando de PCs. Hasta entonces estaba acostumbrado al entorno de texto, lo que se revolucionó completamente de un día a otro cuando me mostró un nuevo "programa".. Tipeó WIN en el prompt del C: y mágicamente el monitor se limpió, mostrando el inquietante mensaje: "Iniciando Windows 3.1"

Me costó acostumbrarme a ver todo en entorno gráfico. Todo lo que alguna vez había imaginado al usar aplicaciones de consola, ahora estaba disponible y listo en la pantalla, sólo había que verlo. Nunca más imaginé una carpeta con su árbol de subdirectorios.. Ahora era cosa de mirarla. Fue como pasar de leer un libro a ver la película, tal vez un poco restrictivo a la imaginación, pero sencillo, y muy muy rápido.
Me sorprendió la facilidad con que se podían hacer dibujos en PaintBrush. Algunos años atrás, debía pasar horas calculando coordenadas para esbozar siluetas de un décimo de complejidad. Con el tiempo llegó el mouse, y desde entonces, el TAB, Alt-TAB, y todos sus derivados, desaparecieron de mi mente y se escondieron en algún recoveco de mi hipocampo.

Recuerdo que en mi colegio se comenzó a enseñar computación. Me aburrí... Sólo jugábamos y dibujábamos. Pero yo esperaba encontrar ahí a mi maestro. Ahora tenía todo el poder gráfico de un sistema operativo revolucionario. Si con apenas 10 años y un ATARI había logrado los "Dos perros tontos", era esperable que con un PC de verdad, con Windows, mouse y una bunea profesora, surgieran cosas mil veces superiores, pero no fue así.... Cada vez tenía menos control de la máquina.

A medida que la computación fue avanzando, la interacción usuario-máquina había subido de nivel, lo que hizo alcanzable la computación para muchos usuarios; Aunque en cuanto a mí, sólo me traía problemas. Me estaba alejando de la madre de todas las madres. Desde allí arriba ya ni se podía ver el código de máquina. Me desilusioné un poco y me volví "leecher", comencé a jugar, a usar el PC para escribir cuentos, hacer dibujos aburridos en Paintbrush y mirar el cursor moverse de un lado a otro siguiendo al mouse, sin saber qué clase de cosas interesantes lo estaban posibilitando.

Por mi padre sabía de la existencia del lenguaje C, que el BASIC ya no se usaba, y que mi única posibilidad de hacer algo realmente novedoso era usando un lenguaje de alto nivel. El problema es que nadie sabía nada. Ni mi profesora de computación, ni nadie conocido tenía un compilador de C instalado. Nadie quería mirar más allá. Me sentí solo en mi búsqueda, hasta que conocí Windows 95.

Cuando conocí el primer PC con Win95, era el año 1997, mi mamá se había casado por segunda vez y fue una revolución en mi vida. Fue en el verano del 97 cuando Juan, mi padrastro, me presentó algo como un 586 de 120 Mhz, con 8 Mb de RAM, que corría Win95. Yo había sólo leído de este sistema en alguna revista que lisonjeaba sus bondades, pero tenerlo en mi PC era para mí como alojar en mi casa a un RockStar. De Windows me sorprendió la capacidad de tocar midis con su reproductor. Habían días en que me quedaba escuchando decenas de tracks, sólo por oir música en el computador. Me acuerdo de algunos programas notables como SkyMap, o el mismo PowerPoint, en el que ví la posibilidad de hacer mis propias animaciones. Recuerdo un día que desperté emocionado tratando de programar algo en PPT. La posibilidad de hacer animaciones y determinar eventos me hizo creer erronamente que lo lograría. Con el timepo me di cuenta que seguía sin programar. En algún momento de la evolución el "If..Then" se había perdido, de alguna forma me estaba quedando restringido a usar los numerosos programas nuevos que iban apareciendo, creados por aquellos afortunados que tenían el don y derecho a programar. Decidí tomarme la vida fácil. Comencé a Jugar.

Junto con el PC nuevo, el otro artículo importantísimo del que se pobló la casa fueron las revistas de computación. Leí todo lo que caía en mis manos, desde Windows, pasando por JavaScript y las nuevas tecnologías de las que se poblaba la incipiente internet. Aprendí bastante de arquitectura de computadores, y de las cosas ignotas que ocurrían mientras uno simplmente pulsaba sobre un botón. Me informé de las nuevas tecnologías que aparecían, de como el DMA venía a revolucionar la forma de gestionar memoria, de los fundamentos de la multitarea y de la manera en que se se formaban imágenes en los PCs. En esencia todo seguía igual a cuando comenzó. Windows y sus farimañas no eran más que una manera amigable de encapsular a lo que realmente estaba pasando. El viejo DOS seguía corriendo de fondo, llamando a funciones de la BIOS, que a su vez pasaban las mismas instrucciones al procesador. Mi 286 de 10 Mhz estuvo haciendo lo mismo durante años, Windows sólo venía a ser una capa ocultando la exquisita complejidad de lo que más abajo ocurría. Necesitaba encontrar la manera de volver a vincularme lo más cercanamente al hardware. Estaba dispuesto a abndonar la comodidad de presionar botones... ¿pero dónde estaba C?.. ¿Por qué entre los miles de accesorios inútiles de Windows no venía algo como un editor de C o assembler?.. Algo grande estaba pasando allá abajo y lo quería conocer. Por suerte, cuando volví a programar no abandoné la comodidad del entorno Windows y comencé con un lenguaje visual de alto nivel, pero eso es historia para otra ocasión......