¡Por fin tenemos web!

Sigenos ahora en: 

http://4waystudio.es/

The king is dead – Ranking

A consecuencia de las muchas sugerencias recibidas y gracias al feedback que me estáis reportando, os presento resumidamente los nuevos cambios que tienen como objetivo acortar la duración de las partidas online.

El juego cuenta ahora con un número de turnos limitado el cual se establece en 25. Este número es provisional y puede variar según lo vayamos probando para que quede lo mas ajustado posible.

Jugados 25 turnos por jugador termina la partida, se informa de esto a los jugadores activos mediante la correspondiente notificación y ya sé consultar en el Ranking para determinar quien es el ganador.

Para ver el resultado de la partida dispones de un nuevo menú de Ranking y puntuaciones, se puede acceder desde el listado online de las partidas activas:

En este menú se listan todas las partidas finalizadas en las que hayáis sobrevivido:

Los puntos que determinan el Ranking son los siguientes:

También es posible consultar el Ranking, desde dentro de la partida a través del nuevo botón:

The king is dead es mi último juego de Android que puedes descargar completamente gratuito desde la tienda oficial: https://play.google.com/store/apps/details?id=com.luis.strategy

The King is dead - Nuevo juego para Android después de cuatro años

Estrategia por turnos, gestión de recursos, ambientación medieval y, la parte mas poderosa, posibilidad de jugar on-line. El nuevo proyecto para Android, el cual está basado en mi propio motor que he ido perfeccionado durante años, el mas complejo que he realizado a nivel individual. Ahora ya va tomado forma y pinta así.

Super PepeToni -making off- 3 Sprites

Programar para la GameBoy tiene sus pros y sus contras.

Como pros hay que destacar que al contar con tan poca resolución de pantalla (160x140 píxieles) y tener un tamaño de sprites tan pequeño (8x8 o 8x16 píxeles) es viable encargarse de la parte de programación y gráficos a la vez, sin que esto segundo suponga una carga excesiva de trabajo. Vamos que con relativamente poco tiempo se pueden dibujar algunas cosas chulis.

Como contras está todo lo demás.

Pero en esta entrada no voy a hablar sobre las grandes carencias de este hardware sino sobre los sprites, o mas concretamente, las limitaciones y particularidades que atañen a estos.

Pero primero de todo ¿Que es un sprite? O mas bien ¿Que diferencia existe entre una imagen "normal" o un sprite?

Una imagen normal no es mas que un vector (Estructura de datos ordenada e indexada) que contiene tanto los metadatos de la imagen (Tamaño, peso, colores y etc) así como la información relativa a cada uno de sus píxeles. De esta manera, cuando mas gran grande es una imagen mas grande será este vector. Esta estructura se puede contemplar con facilidad en el formato de imagen bitmap . 

Cuando se usan imágenes/bitmaps, cada "entidad" corresponde a una 

imagen o parte de ella.  

Fijaos que cada frame ocupa el tamaño que necesita libremente.

Esto es lo que se usa actualmente en la programación moderna. 

En cambio un sprite es una estructura de datos que apunta a una imagen con una serie de "condiciones". Por ejemplo, debe de estar compuesta por un numero de píxeles definido, o solamente puede incluir una cantidad de colores determinada. 

Todas estas reglas se establecen porque, a diferencia de un bitmap, hay una parte del hardware denominada memoria de vídeo que se dedica exclusivamente a procesar estos sprites, liberando al procesador principal de esta ardua tarea. 

Un sprite ocupa lo mismo que cualquier otro sprite porque sólo es información de coordenadas en la pantalla mas un dato que indica a que imagen referencia. Esta imagen que es la que tiene que cumplir con esa serie de "requisitos" y se le denomina tile.

Representación de la memoria de vídeo de la GameBoy corriendo Super PepeToni. 

Fijaros que, a diferencia de la imagen anterior, todas las celdas miden exactamente lo mismo. 

Para formar un sprite grande, se deben ir seleccionando aquellas imágenes/tiles que corresponden.

La conclusión es que una imagen de tipo bitmap es mas detallada que un sprite porque existe "libertad" a la hora de construirla, pero también es mas lenta de procesar.

GameBoy usa sprites y por lo tanto hay una parte de su "circuiteria" que está dedicada al procesamiento de estos. Como el uso de sprites va fuertemente ligado a los videojuegos,  antiguamente, los sprites eran algo casi exclusivo de las consolas y es por esto que una GameBoy, con un un procesador algo inferior al del ZX Spectrum, por ejemplo, lograba juegos con personajes mas rápidos. El truco estaba en el uso de los sprites.

Limitaciones.

La principal limitación de la GameBoy para usar sprites es que sólo puede usar un máximo de 40. Aunque 40 sprites parezca un número mas o menos alto, en realidad no lo es. Como he explicado antes, un tile de la GameBoy puede medir 8x8 o 8x16 píxeles, y este es un tamaño muy pequeño.

El resultado final de toda esta fiesta es que para hacer un personaje de un tamaño considerable se necesitan usar varios sprites. En el caso de Super PepeToni son 10. Vamos, que el solito ya consume 10 de los 40 disponibles. O expresado de otro modo: El personaje principal, sin ser exageradamente grande, se come el 25% del total de los sprites...

Al añadir los enemigos he llegado al tope de los sprites que puedo usar: El personaje principal  mas tres enemigos distintos (He tenido que elegirlos muy bien) Si que es cierto que en realidad se puede representar como el personaje principal mas 6 enemigos, ya que por cada enemigo "guardo" un sprite extra para poder pintarlo 2 veces simultaneas. Osea puedo mostrar los 3 enemigos por 2 veces cada uno de ellos. Y todo eso a la vez. guau.

Guardaré un minuto de silencio por todas aquellas eminencias que, por

motivos técnicos, han quedado fuera :(

En realidad, se pueden crear mas tipos de enemigos "reciclando" sprites que para ser usados en varios personajes. Es decir, puedo reservar un grupo sprites para pintar enemigos del tipo 1 y tipo 2, siempre y cuando no los pinte a la vez.

Esto ultimo ya entra dentro de las clásicas triquiñuelas que se usaban para exprimir el hardaware al máximo, una tarea que resulta ardua pero que ofrece una compensación muy gratificante.

Y bueno, de momento eso es todo por hoy. Nos vemos en la siguiente entrada.

Super PepeToni -making off- 2 ¡Combate!

Tras optimizar todo lo que he podido me alegra anunciar que ya he implementado los enemigos, tanto su diseño como su comportamiento.

He de reconocer que hasta ahora nunca había dibujado nada en rollo pixel art, (Además que hacía años que no dibujaba) y en este proyecto, menos la música, me encargo de realizar todo desde cero.
No va quedando mal pero tengo muchas ganas de verlo corriendo en mi Game Boy ladrillo genuina made in Japan del '90.

Y bueno esto es lo que hay...

Super PepeToni -making off- 1

En esta serie de entradas narraré aquellos aspectos mas interesantes bajo, mi punto de vista, de los retos técnicos que me supone desarrollar un juego completo para GameBoy

Intentaré apartarme de los tecnicismos de programación y usar un lenguaje mas sencillo para que todo el mundo, incluso la vecina de los rulos o mi bisabuela, me pudieran entender.

Y para comprender mi punto de vista es necesario explicar, a groso modo, parte de mi trayectoria como programador.

Yo me inicie como desarrollador de software con el lenguaje de programación Java. Acumulo algo mas de cinco años de experiencia con esta tecnología y actualmente sigo usándola de manera profesional. Con todo esto, puedo considerar que mi nivel de conocimientos en JAVA es relativamente alto. Toma ya.

A lo largo de mi recorrido académico y profesional he aprendido y trabajado con otros lenguajes de programación entre los que destaco C#, Javascript, SQL y C.

Hasta ahora he desarrollado proyectos para muchas plataformas, tanto móviles como de escritorio, y también WEB. Windows, Android, HTML5,  Blackberry y ñañaña...pero es en Android donde he pasado la mayor parte del tiempo trabajando y explotando este entorno. Para Android he desarrollado juegos y apps tanto de forma nativa como también usando frameworks del tipo Unity3D.  He de reconocerlo, Android me gusta, me resulta cómodo, ya le vi potencial hace 5 años y opino que su futuro sigue siendo igual de brillante.

 Este es uno de los proyectos que desarrollé completamente en Android nativo. 100% canvas "a pelo"



Hasta ahora, la tecnología mas limitada en la que había trabajado era la extinta JavaME; ¿Os acordáis de cuando los "teléfonos" no se denominaban "smarphones" sino sencillamente "móviles"? Si, aquellos "rechonchetes" Nokias, Motorolas y Alcateles que tenían unas extrañas protuberancias llamadas "botones". Pues en mi anterior empleo de programador pasé unos tres años desarrollando juegos para estos dispositivos.

¿Te gusta instanciar objetos a loco, perro? Pues este estilizado diablo te va a patear el culo.




Aunque si que había considerables limitaciones técnicas (Había un Nokia que te imponía un tamaño máximo del juego de 128KB, por ejemplo) su mayor inconveniente venia dada por la desfragmentación innerente, esto es, que un mismo juego tenia que ser compatible con unas cincuenta familias de móviles distintos, con una implementación de JAVA que variaba (Cada uno era de un padre y una madre) que por el hardaware subyacente, que también, si, pero sobre todo por la desfragmentación.

Pero GameBoy es otro mundo. Es mas, es otra Galaxia.

Aunque lo publicitaran como un artilugio super-mega-futurista, ya en su día, la Gameboy contaba con una CPU "capada" para ahorrar en batería (Y en costes de producción)



Cuando programas para GameBoy, a diferencia de la concepción actual, no puedes "hacer" lo que te de la gana. Pensad que GameBoy ya era una máquina limitada en 1990. Cualquier pequeño detalle que en una plataforma actual es sencillo de realizar, en GameBoy puede resultar toda una odisea y cada una de las tomas de decisiones que afectan al diseño del juego viene condiciona, siempre, por la imposición del hardaware.

Si pensabais que la limitación de 128KB de aquel Nokia era dura...el reto ahora está en no exceder de los 32KB. En ese espacio tiene que entrar todo; la lógica del juego, los gráficos y el sonido.

Es todo un reto para mi porque vengo de la programación de alto nivel. La programación de alto nivel no significa que uno es un ninja programando, significa que puedes codificar y diseñar un proyecto sin necesitar conocer la arquitectura interna de la máquina. En GameBoy esto es impensable, no vale que el código sea bonito, exportable o modular, no, eso no, ha de ser rápido y ocupar poco espacio.

y para finalizar esta primera entrada que he alargado mas de los deseado, cito una pequeña lista de limitaciones e imposiciones con las que voy a lidiar:

• Tamaño máximo del juego de 32KB.
• Sprites de 8x8 píxeles.
• 40 Sprites como máximo para todo el juego. Pensad que Super PepeToni se compone 2x8 sprites, es decir, el sólo ya se "chupa" 16 de los 40 disponibles.
• Increíble paleta para los gráficos de hasta...4 tonos de gris.
• Imposibilidad usar variables con precisión de coma flotante (Esta limitación ya la sufrí en la época de JavaME)
• Aunque se puede, las operaciones aritméticas de multiplicación y división son efectuadas por software, lo que significa que son muy lentas. Así que a desplazar bits toca (De nuevo).
• Todas la memoria reservada para las variables del juego deben de caber en el espacio de memoria de la frame de cada método. Punteros si, claro, pero alojarlos en el heap como que no (Ya explicaré este punto con mas detalle)
• Toda la lógica del juego debe de resolverse antes de que empiece el barrido vertical de la pantalla que accede a la memoria de vídeo para pintar los sprites. Si se lee de la memoria de vídeo mientras esto ocurre se producen efectos raros. Esto significa que el código debe de ser lo suficiente rápido para que no le coja el "toro del dibujado".

Esta sería la solución fácil para los débiles de espíritu y también para aquellos que no perderán las horas de sueño que voy a perder yo \o/

Y eso es todo de momento. Volveré con nuevas aventuras.

Saludos.

Super Pepe Toni. La historía del héroe mas grande

Cuando el planeta caminaba hacía la perdición a causa de multitud de malvados, maquiavelos en la sombra, y nada ni nadie parecía tener la receta para remediarlo, la ayuda llegó, una vez mas, del espacio exterior en forma de ser omnipoderoso; Super Pepe Toni es un increíble personaje de origen extraterrestre con una fuerza insuperable, una destreza sin paragón y una voluntad noble, cuando se lo propone.

Su único problema es que es tan holgazán que se traga el diario de Ana Rosa en Antena 3 con tal de no levantarse del sofá a cambiar de canal porque hace cuatro meses que el mando de la televisión se quedó sin pilas.

Por otro lado, El Xali, alocado villano que quiere convertir el mundo en un lugar caótico donde reine la locura, ha logrado hipnotizar a los personajes mas peligrosos e influyentes del mundo para que acaben con Super Pepe Toni, el único capaz de detener sus perturbados planes. Estos son Coco, el mas influyente escritor de todos los tiempos, Xoco, un monstruo con una descomunal fuerza, Babit un robot indestructible y Burufulot, un furioso cretino con un peligroso lobo.

Super Pepe Toni no tendrá mas remedio que levantarse del sofá, apagar la tele con el botón, e ir en busca de cada uno de estos individuos para detenerlos. Y ya de paso, para cuando regrese, pasara por la tienda del barrio a comprar pilas de oferta para el mando de la televisión.