Venimos con ganas para traeros uno de esos juegos que son considerados obras atemporales y casi de culto. Flashback de Paul Cuisset por parte de Delphine Software es de esos títulos que supuso un hito en su momento (1992) y que a día de hoy sigue sorprendiendo a todo aquel que le pone las manos … Seguir leyendo »

La entrada GM Podcast #067 – Flashback aparece primero en Game Museum.

El pasado 29 de mayo, tras dos meses en coma, falleció Andrey Rodionov.

Quizá su nombre no sea conocido en el mundillo ya que firmó solo cuatro juegos a finales de los ochenta como A.R. Crazysoft en la extinta U.R.S.S.:

• Back to the Earth
• Danceroid
• Major Pistoletov
• Pistoletov at Factory

Estos juegos para mí fueron unos completos desconocidos hasta la llegada de los emuladores. Me tropecé primero con los dos protagonizados por Pistoletov, que desde el principio me llamaron mucho la atención por su calidad sonora y gráfica. No sabía nada más de A.R. Crazysoft; solo que era ruso y que tenía un gran talento como creador de juegos para MSX. Luego les perdí la pista hasta un tiempo después (no recordaba sus nombres) y fue una agradable sorpresa reencontrarme con ellos en una de mis inmersiones en discos duros y repositorios. Pero lo que más me llamó la atención es que habían otros dos juegos creados por Andrey con una calidad similar a los que ya conocía.

En 2021 retomó los juegos, a partir del código fuente que aún conservaba y se puso manos a la obra corrigiendo algunos detalles y aprovechó la ocasión para añadir la traducción al inglés. Más recientemente, sus juegos fueron presentados a la presente edición de Yandrex Retro Games Battle que publicará sus resultados el próximo 10 de junio.

Andrey nació en Moscú el 3 de junio de 1954. Trabajó como compositor musical, programador y administrador de sistemas, entre otras cosas. Aunque destacó como miembro de la Asociación Rusa para la Música Electroacústica (Russian Association for the Electroacoustic Music), dentro de la Unión de Compositores de Rusia.

Hoy cumpliría 69 años. Sirva este texto como tributo a su trabajo. En nuestra mano está recordarle como se merece: disfrutando de sus creaciones como homenaje a título póstumo. D.E.P.

Enlace relacionado: Twitter

Descarga

Descarga

Descarga

El espíritu de la época dorada de los juegos retro se reencarna en un nuevo proyecto emocionante: Doomed Castle.

En desarrollo de la mano de MA Software, programado en Blitz Basic por Miguel Ángel Jiménez y con Toni Gálvez encargado de los gráficos, este clon del icónico Castlevania es un proyecto comercial que promete llevarnos de vuelta a las emociones de nuestra infancia con el Amiga 500.

Con una jugabilidad similar a la del Castlevania original, Doomed Castle buscará capturar la esencia y la emoción del clásico juego de acción y plataformas. Los jugadores podrán sumergirse en un mundo oscuro y siniestro, lleno de criaturas aterradoras y desafíos intrigantes. ,Por A medida que avanzan, encontrarán mas secretos e items que ayudarán en el camino» enfrentándose a jefes poderosos en su camino hacia el castillo maldito.

La Posadas Party, un evento imperdible para los amantes del Amiga 500 y los juegos retro, será el escenario perfecto para que Doomed Castle haga su debut. Del 30 de junio al 2 de julio, la localidad de Posadas, Córdoba, se llenará de entusiastas de los videojuegos clásicos que tendrán la oportunidad de probar en exclusiva una demo del juego en desarrollo.

Durante la Posadas Party, los asistentes podrán sumergirse en la atmósfera oscura y misteriosa de Doomed Castle. Podrán experimentar la jugabilidad fluida y adictiva mientras exploran los niveles cuidadosamente diseñados y se enfrentan a enemigos desafiantes. La demo será un adelanto emocionante de lo que está por venir y seguramente generará gran expectación y entusiasmo entre los fanáticos del Amiga y los amantes de los juegos retro.

El mejor emulador de Amiga se actualiza a su versión 5.0.0 con numerosas correcciones y añadidos. Algunas de ellas:

• Emulación Amiga 500 no expandida con total precisión de ciclos.
• -Overflow- del búfer de sprites, sólo en AGA, que podía causar efectos secundarios aleatorios.
• Corregida la desviación del reloj de sincronización de la CIA.
• Corregidos numerosos errores en el modo GDI.
• -Integer scaling- funciona correctamente en los modos Overscan+ y superiores.
• La opción «interlace artifacts» no era fiable y causaba corrupción de gráficos en modos precisos.
• Corrección de múltiples errores de emulación de chipset (bitplanes, sprites, blitter).

Mas correciones y los nuevos añadidos mira en https://www.winuae.net/

Saludos a tod@s los amigos del retro.

¡¡ Volvemos un nuevo mes! En este caso… ya estamos en Junio y eso nos habla de un Verano que los tenemos a las puertas y que nos promete mil aventuras en nuestras bicis Orbea !!

En esta ocasión, además de correo habitual de los oyentes y preguntas varias, hablaremos de nuestro nuevo sistema de apoyo al podcast a través de la opción “apoyar” de iVoox. Esperamos que os parezca bien y recordad que todo suma !.

En las secciones habituales, tendremos de nuevo la sección “Os traigo un juego”. En ella, nuestro joven compañero Seth Garamonde nos acercará un juego que utiliza el motor del DOOM 2 se trata de “My House” y que, según parece, tiene mucho que descubrir. Estamos deseando meterle mano ¡!!.

Como asunto especial.. tendremos en directo como público a una persona… nuestro amigo José Luis de Almería que ha sido “raptado en secreto” a acudir a REAM nada mas y nada menos que por Karo su mujer que tambien estuvo entre nosotros experimentando en primera persona lo que es grabar uno de nuestros programas, y yo digo…… ESO son regalos GUAYS ¡!!!!!!!!!!!!!!. Desde aquí nuestro cariño por haber acudido a ver en directo la falta de medios, la ausencia de guion y el nulo despliegue de efectivos¡!!

Nuestro amigo Espetero en su sección “El Reparatero”, nos va a explicar como reparar una gloriosa Videopac destruyendo al mismo tiempo la suya y el Dr.Chip nos acercara su sección “cartas en el tiempo” que en este caso serán “enciclopedias en el tiempo” pero con un asunto que sigue siendo de actualidad

Por fin nos da tiempo y traernos la sección “El tonto las gafas” donde comentaremos sobre el pequeño infierno desatado con las actualizaciones de META para sus Quest 2 y daremos un repaso a lo que es PCVR con sus luces y sus sombras.

Todo esto.. y mucho menos… regado de risas pero también de momentos
serios, de cuatro amigos en torno a una mesa bastante cuadrada en la que solo nos faltabas TÚ!!. Vente un día y cuéntalo ¡!!!!!!!!!!!!

Retrosaludos

Enlace a My House —> ENLACE

Hemos llegado al capítulo final de Ensamblador para ZX Spectrum OXO. Vamos ha realizar unos ajustes que, si bien no son del todo necesarios, creo que pueden ser de interés.

Añadiremos una opción en el menú para que puedan seleccionar los jugadores el número máximo de tablas que puede haber.

Siguiendo con las tablas, actualmente para finalizar el punto es necesario realizar todos los movimientos posibles (ocupar la totalidad de las celdas), aunque en ocasiones ya sabemos que no es posible ganar y son tablas. Implementaremos la detección de tablas para que detecte si ya no es posible ganar y finalizar el punto.

Propondré unas modificaciones que nos harán ahorrar unos cuantos bytes y ciclos de reloj. Modificaremos los movimientos del Spectrum para que ya no sea tan sencillo ganarle. Por último, vamos a añadir la pantalla de carga.

Actualmente, el número máximo de tablas lo tenemos declarado en la constante MAXTIES en Var.asm; la borramos.

Localizamos MaxPoints y debajo añadimos la nueva variable para las tablas:

Localizamos TitleEspamatica y justo encima añadimos la opción de menú para las tablas:

Para que quede más simétrico, localizamos Title3EnRaya y en la parte final de la línea sustituimos $16, $02, $0A por $16, $04, $0A.

En Main.asm vamos a añadir el tratamiento de la nueva opción del menú. Localizamos menu_Time y dos líneas más abajo sutituimos JR NZ, menu_op por:

Localizamos menu_TimeDo y tres líneas más abajo, después de JR menu_op, añadimos el tratamiento de la nueva opción de menú:

Si se ha pulsado la tecla cuatro, se añade dos al número máximo de tablas, si es mayor de nueve se pone a tres, y se carga en memoria.

Tanto este rango de valores, como la diferencia entre uno y otro valor lo podéis modificar a vuestro gusto. También lo podéis cambiar a vuestro gusto en puntos y tiempo.

Una vez que tenemos el número máximo de tablas guardado en memoria, hay que usarlo. Localizamos la etiqueta loop_reset, la línea LD B, MAXTIES y la sutituímos por las siguientes:

Ya solo nos queda pintar el valor seleccionado. En Screen.asm, localizamos PrintOptions y, justo por encima de JP PrintBCD, añadimos las líneas siguientes:

Compilamos, cargamos en el emulador y comprobamos que ya podemos definir el número de tablas, y que al alcanzarse se finaliza la partida.

Ensamblador ZX Spectrum – menú tablas

Actualmente, para que se detecten tablas tienen que estar todas las celdas ocupadas y que no haya tres en raya. En realidad, es posible saber si el punto terminará en tablas antes de que el tablero este lleno.

Vamos a Game.asm e implementamos la detección de tablas.

Para saber si hay posibilidad de algún movimiento, sólo hay que saber si queda alguna combinación en la que las celdas estén ocupadas por un solo jugador, o por ninguno.

Cargamos en B la máscara para quedarnos con las celdas que ocupa un jugador, y en C la máscara para el jugador dos.

Apuntando HL a Grid, sumamos en A el valor de las tres celdas, incrementanto HL para pasar de una celda a otra. Comprobamos si hay alguna celda ocupada por un jugador, y de no ser así salimos. Si sí las hay, comprobamos si hay celdas ocupadas por el otro jugador, y si no las hay salimos.

Las dos comprobaciones siguientes tiene la misma estructura.

Fijaos bien en como vamos recorriendo las celdas con HL, esto nos va ayuda a ahorrar unos bytes en una implementación que hicimos anteriormente.

Las siguientes comprobaciones no las podemos hacer cambiando de celda con HL, ya que no son numéricamente contiguas; usamos IX.

El resto de comprobaciones tienen la misma estructura. checkTies_check258:

Con esto ya tenemos la predicción de si va a haber tablas, sólo queda ir a Main.asm y usarla.

Localizamos loop_tie y tres líneas más abajo sustituimos:

Por:

Ya no hace falta esperar a que el tablero esté lleno para saber si hay o no tablas. Llamamos a CheckTies y si no hay tablas seguimos con el punto.

Compilamos, cargamos en el emulador y vemos los resultados.

Ensamblador ZX Spectrum – predicción de tablas

Quizá veáis un comportamiento que os hace pensar que algo no funciona. Veis la línea uno, dos, tres libre, pero sabes que el Spectrum va a ocupar una celda, luego tú otra y por eso debería marcar tablas.

El sistema precide pero no adivinia. Imaginaos que en una fila hay dos celdas libres y le toca mover al jugador que no tiene la celda ocupada. Bueno, va a ocupar una de las celdas así que ya sabemos que son tablas, pero imaginad que el jugador se duerme en los laureles y pierde el turno, el otro jugador ocupa otra celda y solo queda una libre, y sigue sin poderse predecir tablas, si el otro jugador se vuelve a dormir, pierde turno otra vez y el primer jugador consigue tres en raya.

Vamos a implementar varias modificaciones para ahorrar bytes y ciclos de reloj.

Las primeras de ellas van a ser en Game.asm, sobre el conjunto de rutinas CheckWinner y ZxMove, aplicando la forma en la que hemos implementado CheckTies en las líneas horizontales, las numéricamente contiguas.

Vamos a la etiqueta, ChechWinner_check, localizamos las líneas siguientes:

Y las sustituimos por:

Localizamos las líneas:

Y las sustituimos por:

Localizamos las líneas:

Y las sustituimos por:

Esta parte está lista, añadid en los comentarios de la rutina a HL como registro afectado.

Esta es la comparativa entre ambas versiones:

Como se observa, estamos ahorrando cincuenta ciclos de reloj y siete bytes. Compilamos, cargamos en el emulador y vemos como todo sigue funcionando.

Procedemos a modificar ZxMove, en concreto dos partes de este conjunto de rutinas. Localizamos zxMoveToWin_123 y sustituimos:

Por:

Localizamos zxMoveToWin_456 y sustituimos:

Por:

Localizamos zxMoveToWin_789 y sustituimos:

Por:

Ya hemos terminado con la primera parte. La diferencia principal con CheckTies y CheckWinner es que, aunque son celdas numéricamente contiguas, el paso de la celda tres a la cuatro y de la seis a la siete no es con INC HL, ya que ToMove altera el valor de HL.

Localizamos zxMoveAttack_123 y sustituimos:

Por:

Localizamos zxMoveAttack_456 y sustituimos:

Por:

Localizamos zxMoveAttack_789 y sustituimos:

Por:

Hacemos otra modificación, en zxMoveDefence_cornerBlock34 y en zxMoveDefence_cornerBlock67, que nos hace ahorrar ciclos de reloj, pero ningún byte.

Sustituimos en zxMoveDefence_cornerBlock34:

Por:

En zxMoveDefence_cornerBlock67 sustituimos:

Por:

Las modificaciones en Game.asm ya están. Como ya comenté, añadid en los comentarios de la rutina a HL como registro afectado. Ya se nos olvidó antes, pues el registro HL ya se veía afectado por la rutina zxMoveGeneric.

Esta es la comparativa entre las dos versiones de ZxMove:

La versión dos ocupa seis bytes menos y tarda cien ciclos menos que la uno, lo que parece poco si lo comparamos con el ahorro en bytes de CheckWinner, con menos modificaciones. Recordad que allí el paso de la celda tres a la celda cuatro y de la seis a la siete lo hacemos con  INC HL y aquí no podemos.

La diferencia de INC HL con LD HL, Grid es de cuatro ciclos y dos bytes, y eso nos limita el ahorro.

Si tuviéramos problemas de capacidad, que no es así, podemos ahorrar otro buen puñado de bytes pintando la misma ficha, con distinto color, para ambos jugadores.

Vamos a Sprite.asm y comentamos la definición Sprite_P2. Por otro lado, las definiciones de Sprite_CROSS, Sprite_SLASH y Sprite_MINUS las ponemos al inicio del archivo, quedando así:

Comentar el sprite del jugador dos no sólo obliga a modificar la rutina que pinta las fichas, también obliga a modificar la rutina que pinta el tablero, ya que cambian los UDG. Hemos subido a la parte de arriba los sprites del tablero para sólo modificar una vez la rutina que lo pinta, y para que si más adelante decidimos volver a pintar las dos fichas, no se vea afectada.

Al comentar Sprite_P2 ahorramos treinta y dos bytes. No parece mucho, pero en ciertas situaciones nos puede salvar.

Vamos a Var.asm y modificamos la definición de Board_1 y _2 y la dejamos así:

Compilamos, cargamos en el emulador y vemos los resultados, concretamente el desastre que hemos organizado.

Ensamblador ZX Spectrum – el caos

Que la ficha del  jugador dos se pinte mal lo esperábamos, pero ¿qué pasa con el tablero? Hemos cambiado la posición de la definición de los sprites, pero UDG sigue apuntando a Sprite_P1.

Vamos a Main.asm, y debajo de la etiqueta Main sustituimos:

Por:

Cambiad también el comentario de la línea de abajo.

Compilamos, cargamos en el emulador y vemos que el tablero se pinta bien, pero las fichas no. Tranquilos, era lo esperado.

Ensamblador ZX Spectrum – tres en raya malditas

Vamos a modificar la rutina que pinta las fichas para que lo haga bien, o no, lo podéis dejar así; tres en raya malditas.

Localizamos printOXO_X y las líneas en las que se carga el UDG en A. Le sumamos tres al valor que carga:

Localizamos printOXO_Y y las líneas en las que se carga el UDG en A. Le sumamos tres al valor que carga:

Con esto, si decidimos pintar dos fichas distintas, se pintaría el círculo.

Como ahora estamos en la situación de pintar una sola ficha, comentamos las líneas:

Y debajo de las mismas añadimos la línea:

Comentamos las líneas:

Y debajo de las mismas añadimos la línea:

Un poco de lío, ¿verdad? El aspecto final es este:

De esta manera, si queremos volver a dibujar las dos fichas, en Sprite.asm descomentamos Sprite_P2, y en printOXO_Y alternamos los comentarios en las líneas LD A, ….

Con esto ya se pintan bien las fichas en el tablero, pero no en la parte de información de la partida.

Volvemos a Var.asm y modificamos player1_figure que ahora es así:

Y la dejamos así:

Modificamos player2_figure que ahora es así:

Y la dejamos así:

Por último, añadimos, comentada, la definición para pintar fichas distintas.

Compilamos, cargamos en el emulador y vemos los resultados.

Ensamblador ZX Spectrum – una ficha

Es decisión vuestra pintar la misma ficha en distinto color para los dos jugadores, o pintar distintas para cada jugador. Si utilizáramos una televisión en blanco y negro no habría ninguna duda.

Si mantenéis todas las modificaciones, hemos ahorrado cuarenta y cinco bytes y ciento cincuenta ciclos de reloj. Si decidís pintar distintas fichas para cada jugador, el ahorro de bytes se queda en trece.

Si ya habéis jugado varias partidas contra el Spectrum, habréis averiguado la forma de ganarle, siempre, al iniciar vosotros la partida, y es que hay al menos un movimiento que el Spectrum no sabe defender, no se lo hemos programado.

El movimiento en concreto es ocupar dos celdas de la esquina: la dos y la seis o la seis y la ocho. Si ocupamos la celda dos, el Spectrum ocupa la cinco, movemos a la celda seis y el Spectrum mueve a la siete, movemos a la tres y ya tenemos dos jugadas de tres en raya: celdas uno, dos y tres y celdas tres, seis y nueve.

En Game.asm, localizamos zxMoveAttack_123 y por encima de ella implementamos las líneas que hacen que ya no se pueda ganar al Spectrum realizando ese movimiento.

Comprobamos si el jugador uno tiene ocupadas las casillas dos y cuatro, en cuyo caso movemos a la casilla uno si es posible.

El resto de comprobaciones tienen la misma estructura.

Aunque la jugada se da en dos esquinas, cubrimos las cuatro.

Justo encima de zxMoveDefence_cornerBlock2938Cont está la línea JR NZ, zxMoveAttack_123, la modificamos y la dejamos así:

Si compiláis y jugáis algunas partidas contra el Spectrum veréis que ahora no es posible ganarle con esa jugada, no obstante sigue siendo posible ganarle, sigue habiendo jugadas que no sabe defender.

Ensamblador ZX Spectrum – más difícil ganar

Ahora es más difícil ganar al Spectrum, debemos esperar a que sea él el que empiece la partida y, dependiendo del movimiento que haga, podremos ganarle.

Vamos a añadir otra opción en el menú para poder seleccionar el nivel de dificultad: uno para que no cubra la jugada en la esquina, y dos para que si lo haga.

En Var.asm, después de MaxTies, añadimos la variable para el nivel de dificultad:

Al añadir una nueva opción de menú, está última queda pegada a la línea Espamática. Subimos todas las opciones del menú una línea, quedando así:

Tras la definición de TitleOptionTies añadimos la de la dificultad:

En Screen.Asm localizamos PrintOptions y restamos una a todas las asignaciones de la coordenada Y:

Por encima de JP PrintBCD añadimos las líneas siguientes:

Siendo el aspecto final de la rutina el siguiente:

En Main.asm, localizamos menu_Ties y debajo la línea CP KEY4. Tras esta línea sustituimos JR NZ, menu_op por:

Después de menu_TiesDo, tras la línea JR menu_op, añadimos las líneas de tratamiento de la nueva opción de menú:

Por último, en Game.asm localizamos zxMoveDefence_corner24, y justo debajo de ella añadimos:

Con estas líneas, si el nivel de dificultad es uno no se comprueba la jugada de esquina, compilad y probad.

Por último, vamos a añadir la pantalla de carga. ¿Y que aporta si ya hemos visto como se hace en ZX-Pong y Batalla espacial? Pues esta vez lo vamos a hacer distinto, ya que no vamos a cargar la pantalla en la VideoRAM, la cargaremos en otra dirección de memoria y luego haremos que aparezca de golpe.

Esta es la pantalla de carga, que podéis descargar desde aquí.

Ensamblador ZX Spectrum – Tres en raya

Por favor, sed benévolos, el arte nunca ha sido lo mío. Veré con buenos ojos que diseñéis vuestra propia pantalla de carga, que seguro que es mejor que ésta; difícil no debe ser.

Para poder cargar la pantalla de carga en un área de memoria y después volcarla de golpe en la VideoRAM, necesitamos implementar la rutina que lo haga en un archivo aparte, y compilarlo por separado.

El proceso de carga hará lo siguiente:

• Carga el cargador.
• Carga la rutina que vuelca la pantalla de carga en la dirección de memoria 24200.
• Carga la pantalla de carga en la dirección 24250.
• Ejecuta la rutina que vuelca la pantalla de carga a la VideoRAM.
• Carga el programa de tres en raya en la dirección 24200.
• Carga la rutina de interrupciones en la dirección 32348.
• Ejecuta el programa de tres en raya.

Lo primero que vamos a ver es el cargador que desarrollamos en Basic para hacer todo lo expuesto arriba.

No olvidéis guardarlo con SAVE”TresEnRaya” LINE 10.

El siguiente paso es implemetar la rutina que vuelca la pantalla de carga a la VideoRAM. Creamos el archivo LoadScr.asm y agregamos las siguientes líneas:

La pantalla de carga la cargamos en $5eba. Esta rutina copia a la VideoRAM desde esa dirección $1B00 posiciones (6912 bytes), todo el área de píxeles y atributos.

Una vez copiado, limpia el área de memoria en la que se cargó la pantalla; no es necesario, pero si tenemos que depurar evitamos que quede código residual que nos pueda confundir.

Ya solo nos queda modificar el script que tenemos para compilar y generar el .tap final. La versión para Windows queda así:

El aspecto de la versión para Linux sería éste:

Y con esto hemos terminado. Compilad, cargad en el emulador y a jugar.

En este capítulo hemos añadido dos opciones al menú de inicio, somos capaces de predecir si va a haber tablas antes de que el tablero esté lleno, hemos ahorrado bytes y ciclos de reloj, modificado los movimientos del Spectrum para que sea más difícil ganarle y añadido un pantalla de carga que no se muestra poco a poco, se muestra de golpe.

En este tutorial hemos ido mucho más rápido que en los anteriores, ya tenemos los conocimientos suficientes como para que no sea necesario explicar las instrucciones una a una.

Todo el código que hemos generado lo podéis descargar desde aquí.

Ensamblador para ZX Spectrum OXO por Juan Antonio Rubio García.
Esta obra está bajo licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional License.

Hugo Tomás Benedet ha localizado nuevos diskettes para el sistema Magnet de EFO, entre los que se encuentran versiones que no estaban documentadas, además de localizar lo que parecen distintas revisiones de algunos de estos títulos, tal como se indican en las pegatinas de los diskettes.

Leer más en: https://www.recreativas.org/noticias/2023/06/02/documentadas-nuevas-versiones-de-juegos-para-magnet-system-gracias-a-hugo-tomas-benedet-582
Recreativas.org - Base de datos de máquinas recreativas españolas.
Web: www.recreativas.org

Cuando hablamos de videojuegos basados en las peliculas de animación de Disney, enseguida nos vienen a la cabeza infinidad de títulos de plataformas de la era de los 16 bits como Aladdin, The Jungle Book o The Lion King. Videojuegos muy cuidados a nivel técnico y artístico, fieles al producto original y con una gran jugabilidad que terminó prácticamente convirtiendo a estos títulos en un subgénero en sí mismos, y que representan muchos de los mejores videojuegos de plataformas de la década de los 90.

No obstante, a finales de dicha época el salto de los 16 a los 32 bits y, consecuentemente, del 2D a entornos tridimensionales iba a afectar directamente a este tipo de lanzamientos y a la estrategia de Disney en lo que a lanzamientos de videojuegos se refiere. Paralelamente, las películas de animación clásica de Disney empezaban a perder adeptos frente a las nuevas producciones tridimensionales lideradas por Pixar (que terminó siendo propiedad de la propia Disney), por lo que el atractivo de los personajes de las películas cada vez era menor para basar un videojuego en los mismos.

Es por todo esto que mucha gente considera a Disney’s Hercules como el último gran juego de plataformas bidimensional con el sello de Disney. Un título que aunque fue lanzado en plena era de los 32 bits conservaba el espíritu dejado por los juegos anteriores.

Con cambios nimios, el juego sigue la sinopsis de la película de 1997. El hijo de Zeus, Hércules, ha sido despojado de su divinidad y es enviado a la Tierra para demostrar que es un verdadero héroe y, por tanto, volver a recuperarla. La aventura se desarrollará a través de una serie de pruebas hasta el enfrentamiento final con Hades.

El juego se nos presenta con tres niveles de dificultad, fácil (con dos niveles menos), media y hercúlea, siendo principalmente un plataformas bidimensional de desplazamiento lateral. No obstante, el juego hace uso de la potencia superior de las máquinas en las que fue lanzado (PlayStation y PC) y en ocasiones mete elementos tridimensionales con cambios de plano y perspectiva, lo que ayuda a mejorar la variedad del juego.

El arma principal de Hércules es una espada que, además de un uso normal, permite utilizar el «Don de los Dioses» para realizar ataques especiales: bolas de fuego, bombas de sonido y rayos, siempre y cuando encontremos los power ups correspondientes. De igual manera, podemos encontrar figuras de Hércules que le permitirán recuperar su barra de vida y cascos que le concederán invencibilidad durante unos segundos. Otros elementos a encontrar son las letras que componen el nombre de Hércules y que, de hacerlo, permiten pasar directamente al siguiente nivel y unos jarrones que esconden el password para ir directamente al nivel actual desde el menú principal en futuras partidas. Al final de cada nivel nos encontraremos con un jefe final que tendrá un patrón especial para ser derrotado.

Gráficamente, el juego mezcla los sprites 2D con elementos 3D construidos a base de polígonos, lo que permitía aumentar las posibilidades sin perder el espíritu de los plataformas clásicos de Disney. Esto le da un estilo visual muy particular a este juego que sorprendió mucho en su época pero que a día de hoy envejece peor que un juego realizado íntegramente de forma bidimensional.

Esta dualidad fue la que más polémica generó en su momento en la prensa especializada. Si bien muchos críticos aplaudieron la conservación del espíritu de los videojuegos de Disney precedentes, no fueron pocos los que consideraban que el cambio de generación requería de una renovación dentro del género y un mayor aprovechamiento de las posibilidades 3D de las máquinas. No obstante, la recepción del público fue positiva de forma general y en 1998 llevaba 15 millones de copias vendidas en la Unión Europea.

En este vídeo podéis ver cómo es el juego: