Como muchos ya sabreis, Happy monty esta disponible para descarga en https://github.com/jjaranda13/8BP asi como el documento "making of", (en la carpeta de documentación). Os recomiendo que os bajeis el juego de mi URL y no de la que publica byterealms porque he retocado algún detalle tras el concurso y la versión que he publicado yo es "la buena".
uno de los 25 niveles |
pantalla de carga |
No voy a quejarme del puesto (ha quedado el 11) porque cualquier cosa que diga se puede malinterpretar y precisamente yo reconozco el valor de los 35 juegos, porque al ser programador, entiendo como están hechos y al igual que una persona en un museo puede entender mejor un cuadro del Bosco si conoce sus motivaciones y lo que representa, un programador entiende perfectamente lo que esta viendo y lo analiza técnicamente muy deprisa, haciéndose una idea muy clara del esfuerzo que supone cada aspecto del juego. Es como tener la capacidad de ver "mas allá" de tu percepción visual porque "entiendes" lo que estás viendo.
Lo que si que considero y me atrevo a decir es que una mejor posición para 8BP (= para Happy Monty) habría beneficiado a la escena CPC porque habría "democratizado" aun más la programación en 8 bits, con un mensaje claro a programadores BASIC: si sabes BASIC puedes hacer un juego como Happy Monty. A pesar de todo, algo de difusión he logrado y más de uno se animará a desarrollar sus juegos o demos gracias a Happy Monty. Desde este humilde blog os animo a probarlo!
uno de los 25 niveles |
uno de los 25 niveles |
Voy a dar algunas pinceladas en este post sobre como ha sido construido este juego y cuales son las claves que lo hacen ser una sorprendente creación. Los puntos clave son:
- El juego esta íntegramente hecho en BASIC y funciona en BASIC sin compilar. Eso si, usa los comandos extendidos que proporciona la librería 8 bits de poder (8BP).
- El juego se mide a si mismo e imprime los FPS que esta alcanzando en la parte inferior de la pantalla. Es un dato de "honestidad", para que en todo momento puedas analizar la velocidad del juego y juzgues lo que le cuesta mas y lo que le cuesta menos, sin trampa ni cartón.
- EL juego es un tributo a Mutant Monty, un juego de 1984 escrito en ensamblador y logra alcanzar su misma velocidad (a veces supera 25 FPS) y hasta posee lógicas mas complejas de enemigos que en el juego original. Esto significa que en BASIC se puede lograr el resultado de un juego programado en ensamblador haciendo uso de 8BP y la técnica de lógicas masivas. Si, has leído bien, se puede hacer.
- El juego tiene la primera pantalla idéntica a la del juego original. El motivo es muy sencillo: primero porque es un tributo o "segunda parte" (no un plagio ni un clon como ha afirmado algún despistado) y segundo porque quiero que lo compares: un juego en BASIC vs un juego en ensamblador y decidas por ti mismo si 8BP tiene la potencia de un pura sangre o no. Juega a ambos y alucina viendo lo que desde BASIC se puede lograr
EL juego Mutant monty original |
El primer nivel de Happy Monty |
EL lenguaje BASIC interpretado es extraordinariamente lento...¿entonces? ¿como se logra la vertiginosa velocidad de Happy Monty? (calificada hasta de excesiva -lo cual es un halago- por algún miembro del jurado de la cpcretrodev) ¿de donde procede su "magia"? pues de dos cosas: de la velocidad de los comandos 8BP ( capaces de mover 32 sprites a la vez a 18 FPS o más) y de la ya popular técnica de "lógicas masivas" de la que hablo ampliamente en el manual de 8BP, así como en muchas de las charlas de programación que he dado y que encontrareis en youtube y en la carpeta de documentación
Algunas claves del juego:
Niveles definidos de forma compacta:
- cada nivel se ha creado con 160 caracteres que definen tanto los muros de cada nivel como los enemigos presentes, asi como las trayectorias que deben seguir. tambien en esos 160 caracteres se indica donde se encuentran las piezas de oro, la puerta y la posicion inicial de Monty
- Para no definir cientos de rutas de sprites de diferentes longitudes, se han creado sprites inversores invisibles. Cuando un enemigo choca contra un sprite inversor , cambia de dirección. En el mapa expuesto son las letras "z" ,"x" para rutas horizontales y "q", "w" para verticales.
- los niveles se dibujan en pantalla leyendo desde Basic 160 caracteres almacenados en memoria y "traduciendo" a muros y enemigos que se van pintando. Es por ello que tarda unos segundos en pintarse cada nivel (casi nada). Podría haber hecho una rutina ASM para ello pero he preferido dejarlo así con fines didácticos. Se ha llegado a decir de monty que tiene un problema porque parece que se pinta el nivel como si estuviese hecho en BASIC....pues claro, es que esta hecho en BASIC!!!!
Lógicas masivas:
- cuando un enemigo choca con un inversor este se desactiva, por lo que ya no hay que detectar colisiones con el, hasta que el enemigo choca con el inversor opuesto. en ese momento se vuelve a activar. Esto reduce muchos calculos pues puede haber hasta 12 inversores en pantalla.
- el teclado se lee en dos etapas: en los ciclos impares de juego se le OP y en los ciclos pares se lee QA, de modo que hay menos trabajo que hacer en cada ciclo. La velocidad del juego evita que el jugador pueda apreciar esta limitación "invisible"
- las comprobaciones sobre si monty puede cambiar de dirección solo se hacen cuando monty se encuentra en X= múltiplo de 4 o Y= múltiplo de 16. Esto reduce muchos cálculos por ciclo de juego. Solo se atiende inmediatamente el cambio de dirección si se trata de ir en la dirección opuesta a la que se encuentra en ese momento. En ese caso Monty da la vuelta inmediatamente.
- los enemigos que se mueven mas despacio, tan sólo se imprimen cada dos ciclos gracias a la capacidad de cambio de estado de las rutas 8BP. Esto ahorra tiempo a la rutina de impresión
- la detección de colisión con las piezas de oro se hace cada 6 ciclos, al igual que la colisión con la puerta y la detección de pulsación de la tecla M para activar y desactivar la música. Esto ahorra operaciones por ciclo y es imposible que pases por encima de un oro y no lo cojas pues para atravesar completamente un oro hacen falta al menos 8 ciclos.
Gráficos y música
todos los gráficos, secuencias de animación, decorados, etc los he hecho con la herramienta SPEDIT que viene con 8BP. Es muy sencilla y esta escrita en BASIC, la puedes usar desde winape. En cuanto a la música la he hecho con el WYZtracker. El WYZplayer esta integrado dentro de la librería 8BP y para hacer sonar la música on-game basta con invocar el comando MUSIC de 8BP.
Hay mas cosas y detalles que podria contar pero para este post creo que es suficiente. No quiero "saturar" con demasiados detalles. He hablado algo sobre como están hechas "las tripas" del juego para que os hagáis una idea y me alegro de haber compartido este juego con todos vosotros.
Antes de despedirme, quiero también contaros dos novedades muy próximas:
- 8BP v38 con algunas mejoras y un manual con "primeros pasos" mas fácil aun.
- y un vídeo que voy a hacer de "primeros pasos" con 8BP, en el que veréis como en 10 minutos podéis hacer vuestro primer juego/demo usando 8BP, que tan solo requiere que tengáis instalado winape, nada mas.
Un abrazo y hasta pronto amigos! Os dejo con un video del juego
Un placer poder colaborar con alguien tan comprometido con la escena como José Javier, y por mucho tiempo y proyectos q salgan adelante :)
ResponderEliminarMuy bien explicado todo, la verdad que sí hubiese tenido esta librería cuando era pequeño , habría sido algo increíble, a ver si algún día logro logro hacer un juego de aliens con los 8 bits de poder, saludos José javier
ResponderEliminar