Sueños de grafito azul

Comentarios abiertos

Posteado a las 4:44 pm de noviembre 16th, 2011

¡Esperando que la época de spam haya pasado (en versiones anteriores de este ‘site había un montón de bots dificultando la moderación de comentarios) vuelvo a abrir la discusión en los temas, para cualquier comentario que se quierda dejar!

Posteado en Trivial

Documento de diseño de “El Último Vuelo del Halcón”

Posteado a las 9:55 pm de noviembre 14th, 2011

Adjunto en esta entrada, para todos aquellos curiosos, los documentos de diseño para “El Último Vuelo del Halcón” (v0,1).

Próximamente iré mostrando la segunda versión del juego, usando un motor de juego mejorado, modelos con texturas que merezcan tal nombre, imponentes escenarios espaciales, y aterradores enemigos.

Leer el resto

¡Reto completado!

Posteado a las 11:59 pm de noviembre 13th, 2011

¡Ya está hecho! Han sido los cinco días más atareados que recuerdo en… mucho tiempo.

Ha sido una experiencia interesante como mínimo, además de permitirme descubrir los límites a los que puedo llegar cuando realmente tengo un objetivo en mente. A pesar del agotamiento que ha conllevado (al fin y al cabo este proyecto ha avanzado fuera de horas de trabajo, con lo que he tenido jornadas laborales de 14 horas) puedo decir que he disfrutado mucho de este proyecto.

Adicionalmente… ¡Un proyecto personal que termino! Aún no me lo creo. “I never finish anyth~“.

Bueno, ahora me toca descansar, que creo que me lo merezco. Mañana empezaré a publicar los documentos de diseño, explicando la jerarquia de clases, modelado del juego desde cero, y la división de tareas y tiempos.

¡Un saludo a todos los lectores!

El reto de las 24 horas

Posteado a las 8:07 pm de noviembre 10th, 2011

Cuando vi la oferta de posición en Wake Studios me pasaron por la cabeza unas cuantas cosas…

Entre ellas, que doy el perfil que buscan – o casi -.

Entre otras, que mi portafolio es… Muy limitado. Mi experiencia en el sector de los videojuegos se limita a demos y pruebas que hago para mi disfrute personal, como pasatiempo. ¿Cómo demostrar que todas esas horas, juntas, hacen de mi un experto en el campo, en lugar de un simple aspirante? Leer el resto

Rehash

Posteado a las 10:36 am de junio 8th, 2011

Algo que suelo hacer de tanto en tanto es resetear el contenido de este blog. Generalmente porque se me acumula demasiada miscelánea, porque quiero cambiar la dirección del blog, o porque, simplemente, quiero forzarme a escribir.

En esta ocasión, por las dos útlimas razones. He dejado únicamente el tutorial sobre 2D (y espero ampliar el blog próximamente con otros tutoriales relacionados), pero he despublicado las entradas sobre miscelánea, despotricaciones variadas, y cualquier contenido no relacionado directamente con desarrollo, análisis y diseño de mis proyectos.

En estos momentos soy escéptico sobre mi propia dedicación. Veamos qué sucede.

Posteado en Sin Categoría

Introducción a las 2D

Posteado a las 12:14 pm de octubre 9th, 2010

Debería tener por costumbre terminar un boceto (y convertirlo en un post completo) antes de lanzarme a escribir sobre una nueva idea… Como resultado tenemos varios meses (desde Abril, nada menos) carentes de contenido en el blog.

Lo cual es mi línea habitual de publicación… En fin, lo bueno se hace esperar, dicen.

Recientemente he tenido la ocasión de conocer a un joven entusiasta en el trabajo, que quiere hacer sus pinitos con SDL. En más de una conversación hemos acabado teniendo conversaciones teóricas sobre la base de programación de videojuegos, especialmente sobre fundamentos. Reconozco que estas conversaciones me han inspirado últimamente, y finalmente me he decidido a terminar un conjunto de artículos sobre las bases de programación de videojuegos, desde un punto de vista abstracto y matemático.

Así que recupero aquí uno de tantos esbozos de post a medio hacer, y termino de darle forma por fin. Empezaré hablando de un primer acercamiento a la programación visual de un juego en 2D.

Fundamentos

Empezaremos hablando del concepto de las 2D, y concretamente por algo obvio, su propia definición. Nos referiremos a aquellos juegos cuyo desarrollo tiene lugar en dos direcciones o dimensiones. Podría ampliar esta definición, pero me gustaría que este primer post sobre desarrollo sea algo simple e introductorio, un recurso que alguien que acaba de entrar en este mundillo pueda entender con facilidad. Así pues, no hablaré de los hijos bastardos del 2D original, como pueden ser el Modo 7, el 3D de avance bidimensional, y demás subversiones.

Bien, expando el concepto. Dos dimensiones. Supongamos un camino recto entre dos puntos. Podemos avanzar y retroceder sobre este camino. Y quizá podamos hacer algún movimiento sobre la línea perpendicular que trazan estos dos puntos. En cambio, no podemos apartarnos de este camino en ningún momento. Esto simplifica enormemente la programación de cualquier escenario, como veremos más adelante.

Sprites

Este vocablo inglés se refiere a pequeñas imágenes que usamos para crear los elementos de nuestro mundo. Diferenciamos aquí dos clases:

  • Tiles: normalmente referidos en castellano como “ladrillos” (a pesar de no ser su traducción literal). Los tiles son imágenes de tamaño fijo de carácter intercambiable, que en conjunto forman elementos de una escena. Veamos a continuación unos ejemplos del famoso “Final Fantasy“.Introducción a las 2D - Figura 1

    Tenemos aquí cuatro imágenes (de 16×16 píxeles cada una, mostradas con zoom 2x). Estas imágenes, por si solas, representan más bien poco. No son más que píxeles de colores dispares. Sin embargo, con suficientes Tiles, y ordenados de la manera adecuada…

    Final Fantasy - Mapa de ejemplo

    … obtenemos un paisaje muy adecuado y correcto para nuestro juego.

    Superpongamos ahora una rejilla de 16×16 para ver claramente los Tiles.

    Introducción a las 2D 3

    Podéis ver que hay resaltados algunos elementos. Cada una de las casillas marcadas es un ladrillo diferenciado que se repite varias veces para formar el escenario. Trataremos el tema de mapas con más detalle en la próxima sección.

  • Blits: también llamados “doodads“, “Blitter Objects” o “BOBs“, se refieren a sprites que se copian directamente sobre la pantalla de video tras realizar el render, utilizando una tono de transparencia y una máscara para superponer el elemento, y dar la impresión de “estar sobre el escenario”.Veamos un ejemplo simple de blit, usando el personaje “Black Mage” de “Final Fantasy“:

    La línea roja separa las dos imágenes. La imagen de la izquierda es nuestro objeto “Blit“, y la imagen de la derecha es una representación de la misma imagen usando una máscara de transparencia. En este caso, aquellos píxeles que vemos de color negro son aquellos que no se copiaran a la imagen final. Si superponemos el blit a nuestro mapa…

    Usando esta técnica podemos poblar nuestros mapas de heroicos héroes y villanosos villanos. Así como de casas, árboles, o cualquier elemento que podamos imaginar.

Mapas

Ahora que tenemos claro el concepto de los tipos de objetos de imagen con los que trabajaremos, planteemos la estructura básica de un mundo 2D. Existen muchas formas distintas de representarlo en memoria (que vendrá dado por el lenguaje de programación que usemos, nuestro entorno de trabajo, y los datos complejos y estructuras de datos avanzados que diseñemos). En cualquier caso, la imagen básica que tenemos que tener de nuestro mundo 2D es un elemento matemático 2D: la matriz.

Así como mostrábamos anteriormente en la rejilla, cada imagen es un “trozo” de mapa, un puzzle que por si mismo no representa gran cosa, pero que junto crea una imagen compleja.

Podemos ver aquí los diferentes “Tiles” que forman el mapa mostrado en la primera imagen, en donde hemos asignado a cada imagen un número único. Escojamos ahora un fragmento del primer mapa:

Podemos representar esta imagen mediante una matriz de 3×3 con el siguiente contenido:

De esta forma no consumimos recursos innecesarios manteniendo estructuras de memoria muy grandes. Los ejemplos aquí usados son acordes a la antigua arquitectura de la nintendo NES (8 bits de colores, 2KB de RAM), y por ello visualmente muy limitados. Con las paletas de memoria hoy en día, y el tamaño de RAM disponible en un PC o Consola medio, trabajar con estructuras 2D permite dar muchísimo detalle (por mencionar un par, Odin Sphere de PS2, del estudio Atlus, o el último capítulo de la saga King of Fighters para PS3).

Cámaras

El último fundamento que tocaremos hoy es el de la cámara o “viewport“. Siguiendo con los ejemplos anteriores, supongamos una pantalla de 320×240 píxeles. Si nuestros “Tiles” son de 16×16, esto significa que podemos mostrar una pantalla de 20×15 baldosas. Sin embargo, si deseamos mostrar un “mundo” más grande que el que cabe en la pantalla, ¿qué podemos hacer?

A medida que el personaje recorra la pantalla, nosotros actualizaremos la imagen a mostrar. Supongamos que queremos centrar la imagen del protagonista en la pantalla. Esto hará una media de 10 “Tiles” a cada lado, y de 7 arriba y abajo.

En función de cómo programemos la arquitectura de nuestro juego podemos generar todo el mundo, y luego recortar la imagen que se mostrará en pantalla (algo que consume muchos recursos, aunque es un acercamiento sencillo al problema), o bien actualizar únicamente aquello que está en nuestro campo de visión (lo cual se considera una solución elegante).

Sigamos con las matemáticas para la cámara que hemos planteado en el primer párrafo de esta sección. Si tenemos el personaje en unas coordenadas (X, Y) de nuestro mapa, mostraremos desde (X-10, Y-7) hasta (X+10, Y+7). Visualmente:

Esencialmente, mostraremos las imágenes correspondientes a las Tiles de la estructura en memoria que estamos viendo en este momento, y luego añadiremos los objetos Blits a la imagen.

Hay, sin embargo, una complicación: el movimiento. Nuestro personaje se moverá por el escenario, y entonces puede darse el siguiente caso:

A medida que nos desplazamos se va mostrando parte del mapa que está fuera del rango teórico que hemos definido en nuestra cámara. Afortunadamente, esta complicación se soluciona de forma sencilla: dada una cámara que recorra un movimiento de (M x N) casillas, si tenemos en memoria el render de una imagen de (M+1 x N+1) casillas, a medida que nos desplacemos podremos mostrar la parte visible de las casillas en cuestión. La posición de la cámara se debe calcular en tiempo real, a partir de la posición del personaje, junto con el desplazamiento adecuado del mapa (¡encontrar la forma de convertir esto a código es, sin embargo, tarea tuya, querido lector! Es mucho más sencillo de lo que pueda parecer).

Bien, con esto doy fin a este primer artículo de programación de videojuegos. Espero de forma sincera poder ofreceros más en breve. Hasta entonces… ¡A trabajar!

Posteado en Desarrollo, Programación