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.
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.
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.
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.
No hay comentarios:
Publicar un comentario