Un kilo de robots, por favor

Ayer fué la última reunion de G.DevClub y a pesar de que no asistieron todos (si! estamos de vacaciones) estuvo muy interesante. Karen y Kau nos mostraron avances de su juego en red Monolitika, el cual me gusta mucho. MrBig les dió algunas sugerencias sobre programación en red para su juego, y aún cuando no entendí muy bien del todo, es muy interesante; y Paulo llevó su juego el cual también es de naves, como el mio, y bastante impresionante, aunque no pudimos jugarlo bien porque aún tenia unos problemas, los famosos BUGS! Aquí públicamente agradezco a la mamá de Karu por aguantarnos y alimentarnos XD. Muy tranquila la reunion y después nos fuimos de fiesta para cerrar con broche de oro. Razón por la cual hoy me levante tarde, pero aún así me fuí un rato al gym y al regresar mi familia ya se habia marchado al rancho. Claro, les dije que yo no iba esta vez (sabia que no me iban a esperar).

G.DevClub queda inactivo hasta que todos regresemos de vacaciones, pero eso me da tiempo para dedicarme mas a mi proyecto. Hoy estuve todo el dia solita en casa y parece ser que así estare todo el fin de semana... tengo ganas de ir al cine pero no tengo con quien. A ver! Los que se quedaron! llevenme al cine!!

A pesar del corto dia luz que tuve hoy, fué muy productivo. Aparte de lavar mi ropita jiji, pude terminar lo que me faltaba de la arquitectura del juego. Terminé un sistema administrador de "assets". No conocia el término, pero MrBig nos explicó que son la información relacionada con, por ejemplo, modelos 3D entre otras cosas. Claro, en mi caso son las imágenes donde estan mis sprites, ya que es un juego 2D. La ventaja de un administrador (que es mas bien como una necesidad) es que ayuda en cargar en memoria la información a utilizar digamos, en un solo nivel del juego, sin agregar extras. Además, se encarga de evitar datos redundantes. Funciona de la siguiente manera: al inicio del nivel se le pasa una lista con los objetos a cargar para ese nivel en específico; como ejemplo un Robot Enemigo. La información base del Robot es cargada, datos como Nivel de Resistencia, Nivel de Ataque, Imagen de Sprite, etc. Toda la información "constante" de ese tipo de robot. Después, cuando se requiera que un robot entre en acción, se carga la información relacionada a ése robot como identidad única en el nivel; como su Posición, Dirección, etc. Así, la próxima vez que necesitemos a otro robot en acción, no tenemos que duplicar su información base, ya que es constante para todos los robots de su tipo. Asi que únicamente puede leer esa información en memoria (o memoria de video si es una imagen) y después, de igual forma carga la información individual (como deciamos, Posición, etc.) Ah! que bonito, ¿no creen?

Además de eso, al "pedir" un robot, no tenemos que pedir adicionalmente informacion del objeto Misil (suponiendo que dispara misiles) ya que internamente, los objetos estan enlazados entre si, por lo que al cargar la información base del robot, también se cargan todos los assets de los objetos enlazados al robot automáticamente. Para ello, programé un pequeño editor de Objetos del juego donde le doy sus propiedades o información base a cada uno y realizo los enlaces entre ellos. La herramienta compila la información y me genera un directorio de objetos con toda ello. Y finalmente, tiene la opción de hacer los enlaces en tiempo de ejecución, por si se requiere.

Este administrador ya es parte íntegra del pequeño motor de juego que poco a poco e ido creando. Ya lo probe y funciona muy bien, y claro, funciona como un Garbage Collector ya que él sabe que carga y que no. Desde el punto de vista del codigo cliente, no hay 'new's ni 'delete's, solo peticiones de objetos. Así que por fin todos las piezas y pequeños demos que llevaba hasta ahora empiezan a tomar forma de... un video juego? ;)