Bueno, bueno... Hace bastante que no vengo por acá pero parece que hay mucha gente interesada en que reviva al blog (ok, no exactamente mucha), así que voy a hablar un rato del nuevo proyecto. Mientras hablo, ustedes pueden leer.
Un poco de background: resulta que en 6to año de mi secundario teníamos una materia llamada Microcontroladores -creo-, donde por un lado vimos la teoría de las arquitecturas CISC/RISC, y de ahí nos metimos de lleno en entender cómo andaba un microcontrolador específico, el PIC16F84 (con algunas extensiones del 16F877). Hecha la teoría y presentado el set de instrucciones de cada uno, luego de practicar resolviendo problemas y bla bla bla, había que hacer un tp final.
Yo estaba con Ariel en grupo, entonces, cuando no jugábamos al smash en clase -teníamos la única pc que parecía poder correrlo!-, nos poníamos a pensar qué se podía hacer. Fuimos de un auto a radiocontrol con parlantes y micrófonos que transmitían/recibían datos desde el control remoto hasta una especie de auto patrulla que exploraba una habitacion para saber cómo era.
El proyecto que les ganó a todos esos fue el de hacer un juego. En un principio pensamos en usar una matriz de leds, pero eso iba a hacer que el resultado final fuera muuuy grande, por lo que surgió la idea de usar un lcd. Buscando, encontré uno de 128x64 pixels, bastante bien para lo que queríamos hacer. Problemas más, problemas menos, terminé diseñando y armando la placa y programando un snake (Ariel ayudó a soldar y con la parte económica :P). Creo que fue el mejor tp que jamás hice -apenas se lo entregué, el profesor salio corriendo a mostrarle al jefe de taller lo que había hecho, jajaja-. Aparte me dieron ganas de seguir con el tema, así que hasta las primeras semanas de ese diciembre, optimicé y le agregué cosas al snake. También me compré otro pic e hice un tetris. Estaba en planes de hacer un asteroids, pero lo dejé y desde ese día no toco nada de assembler.
Hoy me leí el manual de microchip del PIC16F877A, recordando algunas cosas y descubriendo otras que hubiesen facilitado la programación y que ahora pienso usar. El martes con algo de suerte tendría el programador para volver a las andanzas con este nuevo proyecto que usaría esa placa del tp, con ese lcd y que creo que va a estar bueno para adaptar a un diseño mas compacto estilo tamagotchi :P
La idea es hacer un Dungeon Crawler, para los que no estén familiarizados en estos tecnicismos (por ejemplo, los bots y las personas que caen al blog cuando buscan cosas del Ragnarok Online), se trata de un tipo de juego donde la idea es explorar y sobrevivir. En mi Kyocera S14, mi primer celular, uno de estos venía por defecto. Básicamente recorrías un nivel generado al azar, estilo laberíntico, donde podías encontrar bichos o cofres con items. Creo que había comida y cosas como espadas y armaduras. La idea era ir bajando los niveles y sobrevivir lo máximo posible.
Mi idea del juego sería algo parecido, pero en assembler (sep, sin usar ni C ni BASIC) y enfrentándome a las limitaciones que tienen 8KB de memoria de programa (8192 caracteres, para hacer como los del discovery que tiran cifras y las comparan con otras cosas) y 384 bytes de registros de memoria RAM (en una pc hay en general algo así como 2GB, que serían mas de mil millones de veces los registros que tiene el PIC). Ahora que están asustados y aturdidos por tanta información, voy a darles el golpe final comentando cómo sería mi idea a la hora de encarar el juego.
Siendo mi pantalla de 128x64 pixels, pensaba reducirla a una de 64x64 para el tamaño tamagotchi, por lo que en primera instancia estaría dibujando la mitad de la pantalla, cosa de ver cómo queda. El juego tendría bloques de 8x8 pixels, mostrando en la pantalla un total de 8x8 bloques. Mi idea ahora es que el laberinto sea de tamaños estilo 40x40 bloques, por lo que haría falta scrollear la pantalla. Aparte, mi intención es que el mundo sea wraparound, toroidal, que se repita, es decir, que cuando pases el bloque 39 vuelvas al bloque 0 -zero based, folks!-.
La primera idea que se me ocurrió fue la de tener 5x40 registros (200), donde por cada registro habría un total de ocho bits (que es lo que tiene un byte) indicando con un 1 si hay un bloque y con un 0 si no lo hay. El primer problema visible es tener 200 de 368 registros de memoria ocupados en el tablero, limitándome en las posibles otras cosas que quisiera hacer. El segundo problema, no tan visible, está en que al generar un nivel al azar, sería complicado armar un laberinto 'creible' -o mejor dicho, que no se note tanto que es random-, donde puedas ir desde el punto de partida hasta la salida al siguiente nivel. Hay otros más, pero voy a detenerme y empezar a hablar de mi (posible?) solución final.
Habría un total de 8x8 registros (64), indicando cómo serían los 40x40 bloques del laberinto. Las ventajas son obvias, menos memoria ocupada (64 vs 200), menos llamadas al procedimiento 'random' y la posibilidad de hacer niveles de tamaño variable. O sea, podría haber algunos con 100x50 bloques, que vendrían a ocupar los 200 registros como 20x10, o bien otros con 4x4 registros que representen un nivel de 20x20 bloques, por ejemplo. Como ya estarán mareados con los números, procedo a encender una lamparita e iluminar este nuevo procedimiento.
Cada uno de esos 8x8 registros representaría un conjunto de 5x5 bloques. Siguen teniendo 8 bits, pero la diferencia es que cuatro serán indicadores de si el conjunto tiene salida al norte, sur, este u oeste, mientras que los 4 restantes podrían representar otras cosas, como 16 variedades distintas que conectan las salidas entre sí. De esta forma también se puede saber qué conjuntos se pueden conectar con otros, y la parte de generación de niveles al azar sería mucho más simple, ya que habría que armar conjuntos que se conecten con los que ya fueron generados. It's magic!
Pero bueno, por hoy ya es suficiente. Tengo que ver el tema de los bichos, los items, el hp, si hay skills, experiencia, level up, etc, etc.
