Continuacion de las impresiones de Titan Quest

listen to ‘Continuacion de las impresiones de Titan Quest’ on Audioboo

Primeras impresiones de Titan Quest Inmortal Throne

listen to ‘Primeras impresiones de Titan Quest Inmortal Throne’ on Audioboo

Impresiones que hice de este juego cuando llevaba de 12 horas de juego mas o menos. Ahora llevo 30 horas, así que pronto grabare la continuación.

Mis impresiones de las conferencias del E3 2014

Lo que espero del E3 2014

listen to ‘Lo que espero del E3 2014’ on Audioboo

Lo que espero encontrarme en este E3 que esta a punto de comenzar.

Primeras impresiones del Super Robot Taisen Z 3 para PS Vita

listen to ‘Primeras impresiones del Super Robot Taisen Z 3 para PS Vita’ on Audioboo

Continuando el micro-podcast anterior, aquí tenéis las impresiones de la ultima entrega de esta saga de estrategia de robots.

Sobre los Super Robot Taisen y el nuevo SRTZ3 en particular

listen to ‘Sobre los Super Robot Taisen y SRTZ3 en particular’ on Audioboo

Iba a hablar sobre el nuevo SRTZ3, pero para variar me he enrollado hablando sobre la saga en general, así que tendréis las primeras impresiones en un próximo audioboo.

Por cierto, a partir de ahora subiré los audioboos también a Ivoox los tendréis aquí.

Como hacer un juego top-down 2D a lo Zelda en Unity

Si el año pasado durante la Golden Week (como las vacaciones de Semana Santa en Japón, pero sin procesiones) hizo ese micro-clon de Diablo + Gauntlet llamado Dungeons of Diablet en Unity, esta año me había decidido a hacer un juego un poco mas retro. Siempre había querido hacer un juego a lo Zelda, pero no como el de NES. Como muchos yo nunca pude jugar al de NES en su tiempo, si no que guardo mejor recuerdo del de Game Boy, junto con otros muchos juegos de la portátil de Nintendo.

El problema es que esta vez, por varias razones, he estado muy ocupado durante la Golden Week. Pero durante un descanso probé a montar el esqueleto de un juego 2D y los resultados de unos 15 minutos con Unity me encantaron, así que decidí continuar con unas pocas horas de desarrollo al día siguiente. Por supuesto ese tiempo no es suficiente para terminar el juego, pero mas o menos se puede ver el resultado en el vídeo de mas arriba.

Con calma (ya que también tengo a The Curse of The Red Forest en marcha) espero completarlo y hacerlo un juego completo.

Aah, y podéis probar este esqueleto de juego aquí.

Mis impresiones de Metal Gear Solid V Ground Zeroes

listen to ‘Mis impresiones de Metal Gear Solid V Ground Zeroes’ on Audioboo

Mis impresiones de la ultima obra de Kojima.

Mis experiencias con la Game Boy

listen to ‘Mis experiencias con la Game Boy’ on Audioboo

Aprovechando el reciente aniversario del lanzamiento de la primera Game Boy, hago un repaso de lo que supuso esta consola para mi.

Ultimas compras octubre-mediados de abril

listen to ‘Ultimas compras octubre-mediados de abril’ on Audioboo

Hacia tiempo que no hablaba de mis compras, así que aquí tenéis un repaso a mis adquisiciones de los últimos meses.

Impresiones Metal Gear Solid Peace Walker

Para encajar la historia de Ground Zeroes me decidí a retomar Peace Walker. Aquí tenéis mis humildes impresiones en formato micro-podcast.

Novedades de mi RPG "The Curse of the Red Forest"

listen to ‘Novedades de mi RPG "The Curse of the Red Forest"’ on Audioboo

Los avances en mi RPG que estoy creando con Unity para iOS y Android. Más info en la pagina oficial.

Mi nuevo proyecto: "The Curse of the Red Forest"

Los que leéis este blog, escucháis mi micro-podcast en audioboo o me seguís en Twitter sabréis que desde hace tiempo estoy trabajando en un nuevo proyecto personal, después de terminar "The Island of the Oracle 3D". Aunque ya había anunciado el titulo furtivamente en Twitter, ahora mismo estoy preparando la presentación en sociedad del juego.

Se trata de "The Curse of the Red Forest", un RPG clásico en primera persona con inspiración totalmente anime. Como comente en un audioboo, para este juego estoy utilizando tanto material creative commons como material de pago para tener mas libertad a la hora de crear el tipo de juego y historia que quiero contar.

Estoy preparando el juego para Android y iOS, que estarán listas a finales de esta primavera. A la estoy haciendo los arreglos para una eventual versión para Playstation Mobile. La versión para PSM permitiría sacar el juego para PS Vita (lo que me hace mucha ilusión), pero todo depende de que se libere el exportador para esta plataforma de Unity, que ahora mismo esta en beta cerrada.

Por de pronto aquí os dejo la pagina en IndieDB donde he registrado el juego y la web oficial. En breve tendréis un nuevo audioboo explicando los avances del juego y la semana que viene publicare el primer teaser trailer del juego. ¡Así que estad atentos!

Pensamientos sobre el lanzamiento de la PS4 en Japón

listen to ‘Pensamientos sobre el lanzamiento de la PS4 en Japón ’ on Audioboo

Mis pensamientos aleatorios sobre la salida de la PS4 en Japón y su futuro.

Primeras impresiones de Hearthstone

listen to ‘Primeras impresiones de Hearthstone’ on Audioboo

Después de unos días jugando a este juego de cartas de Blizzard os cuento que me parece.

Impresiones de Persona 4 Golden

listen to ‘Impresiones de Persona 4 Golden’ on Audioboo

Después de terminarme el juego con el final bueno y a punto de hacerlo con el final secreto creo que ya puedo dar una opinión definitiva sobre este juego.

El Famicom Disk

El Famicom Disk System es uno de los inventos de Nintendo de los 80 mas desconocidos en occidente. Y eso a pesar de ser donde se originaron muchas sagas clásicas como Zelda, Metroid o Castlevania (la versión FDS salio antes, por unos días, que la de MSX). Veamos como se ideo este complemento para la esta consola de 8 bits.

A mediados de los 80 Nintendo se había hecho ya con una muy buena posición en el mercado de consolas japones, aspirando al monopolio. Sin embargo la clásica Famicom se había diseñado para ahorrar costes y eso hacia que tuviera grandes limitaciones para albergar juegos mas elaborados. Principalmente, los problemas de la gran N era la cara memoria de los cartuchos ROM y la imposibilidad de salvar partida (algo muy necesario para géneros complejos como el RPG). Con cada vez mas competencia a la vista por parte de Sega y Nec, Nintendo se decidió a hacer evolucionar su maquina. Pero no con una maquina nueva si con un add-on que solventara sus carencias.

Y así nació el Famicom Disk System. El sistema se basaba en un relativamente barato disco amarillo o azul, que casi parece de juguete. Ademas, en los discos se podía escribir información del juego, con lo cual el problema de salvar partida estaba también solucionado. Y como extra, el dispositivo ampliaba la exigua RAM de la consola (originalmente 2Kb) y la dotaba con nuevas posibilidades de sonido.

Parecía el add-on perfecto y estaba acompañado de grandes títulos haciendo cosas nunca vistas en la Famicom. Nintendo incluso sacaba dinero vendiendo a parte el adaptador de corriente para el FDS (por que, si, ¡el sistema podía funcionar a pilas!). Grandes sagas nacieron y el sistema crecía con títulos de todos los géneros.

Pero, casi de repente, todo se desvaneció. ¿Que ocurrió? Pues lo primero es que el sistema era algo frágil, sobretodo la famosa goma elástica que llevan dentro los lectores de disco antiguos y que cualquier usuario de ordenadores de los 80 con disco conoce. Por otro lado, el precio de las memorias ROM bajo en picado, haciendo que ya no tuviera sentido un dispositivo especial. Y por ultimo el sistema de salvado por pila interna en los cartuchos clavo la banderilla definitiva en el disco de Nintendo, que no llego a ver la luz nunca fuera de Japón.

El sistema fue soportado por Nintendo hasta que discontinuo la Famicom, lo que es cosa de solo unos años, y ahora queda como un sistema curioso para coleccionistas. Muchos juegos se portaron a cartucho mas tarde, sobre todo para el publico americano/europeo. Hay ports que son mejores que la versión disco y otros que no (porque no incluyen, por ejemplo, los chips de sonido). 

En fin, por si os pica la curiosidad, aquí os dejo un vídeo en que desempolvo mi FDS y muestro un par de los juegos mas representativos del sistema.

Sobre mi blog

listen to ‘Sobre mi blog’ on Audioboo

Aprovechando la primera entrada del año, en este audioboo hago un poco de repaso de lo que ha sido mi blog y lo que es ahora.

Sistemas para crear aventuras conversacionales (III) : INFOCOM

Zork I para TRS-80, una de las versiones mas antiguas

Introducción

De entre todas las compañías que se dedicaron a crear aventuras conversacionales en los 80, INFOCOM es seguramente una de las mas antigua y de las mas recordadas en los paises donde llegaron sus juegos. Cuando las aventuras para ordenador no dejaban de ser clones de aventuras de Scott Adams o de una simplicidad similar, INFOCOM introdujo aventuras que eran verdadera ficción interactiva. Textos largos y descriptivos, parser de texto avanzado y complejo y unas herramientas para hacer aventuras cuya influencia aun esta viva hoy en día.

Pero hagamos primero un poco de historia. Y la historia de INFOCOM esta ligada a Zork, una aventura inspirada en la original creada por varios estudiantes de MIT. Esta versión primigenia de Zork esta programando en MDL, un lenguaje basado en LISP,usado para la investigación de varios temas relacionados con inteligencia artificial dentro del MIT. Zork fue portado por un hacker a Fortran y acabo distribuyéndose por todos los main frames de la época. La historia podría haber acabado aquí, como tantas otras aventuras para grandes ordenadores de la época pero sucedió que el grupo de estudiantes que había creado Zork originalmente se decidió por crear una empresa aprovechando el boom de los micro-ordenadores de finales de los 70. Su intención era crear aplicaciones, no juegos, pero al no tener ninguna aplicación pensada, se decidieron por portar Zork a los micros de la época. Y aquí comienza la prolífica historia aventurera de INFOCOM .

Como se hicieron los juegos de INFOCOM 

Hecho el prefacio histórico, vamos a centrarnos en como INFOCOM  hacia sus juegos. La primera versión, no comercial, de Zork estaba escrita en MDL y el código esta disponible. Pero al ser un lenguaje con muy poca difusión y apenas documentación  se hace difícil analizar el código (que es bastante complejo para la época). Mejor que eso nos vamos a centrar en los ports para micro-ordenadores, que guardan relación con el MDL, pero están mucho mejor documentados y por razones que explicare mas adelante es también mucho mas claro.

El primer problema que se encontró INFOCOM para portar Zork a micros fue el mismo que tuvo Scott Adams, la falta de memoria. Pero a diferencia de Adams, INFOCOM decidio centrarse solo en sistemas con disco, lo cual ya les daba bastante soltura en cuanto espacio, pero aun así tuvieron que comprimir bien el texto y implementar su propio sistema de memoria virtual (algo que era casi experimental en ese tiempo) para que Zork cupiera en los micros de primera generación.

Otro problema a solucionar era que, aun centrándose en sistemas con disco, la variedad de micros a finales de los 70 hacia que el mercado estuviera muy disperso, por lo que para maximizar los beneficios los juegos tenían que ser portados a varios sistemas. La solución de INFOCOM es casi obvia hoy en día: diseñaron una maquina virtual, la maquina Z. Con esta solución solo tenían que portar el código de la máquina Z a cada sistema (un programa llamado ZIP), dejando el código de cada juego tal cual. Esta maquina esta, por supuesto, orientada a reproducir aventuras, y esta tan bien diseñada que sigue siendo la base para sistemas de aventuras modernos como Inform.

La máquina Z

Así que la maquina Z implementaba funciones básicas de entrada y salida, memoria virtual y el sistema de compresión  dejando todo lo demás (incluido el parser) para ser programado dentro de ella. Lo bueno de que la Z-machine fuera lo mas simple posible es que todo Z-code, el código que interpretaba, no tenia que ser portado. Con lo cual si las partes mas complejas del juego, como el parser, se creaban en código-Z, ya no era necesario re-escribirlo para todos los ordenadores de la época; ganando en potabilidad.

La técnica de memoria virtual (algo muy nuevo en la época) les permitía tener en memoria solo las partes del juego que se estaban usando en ese momento. Cuando se requería algo que no estaba en memoria se cargaba de disco, borrando alguna parte de memoria cuando fuera necesario. Para poder hacer esto, la Z-machine clasificada en dos tipos de bloques de memorias: puros e impuros. Los bloques puros eran información que no se modificaba nunca como las cadenas de texto y las definiciones de objetos (que eran todos estáticos). Los impuros eran a su vez los que si se modificaban, como los flags de los objetos, su posición o las variables globales. Así que cuando fuera necesario mas espacio en memoria del disponible, la maquina-Z solo tenia que borrar cualquier bloque "puro" y reescribirlo con la nueva información. Si volvía a hacer falta el bloque borrado, sabiendo que es invariable, solo habría que re-leerlo del disco. Los bloques impuros debían permanecer siempre en memoria, y es lo que mas limitaba la RAM mínima para ejecutar los juegos. Los primeros juegos apenas requerían RAM, unos 32Kb, pero los últimos juegos, mas avanzados, requerían muchas mas memoria y prácticamente solo funcionaban en maquinas de 16 bits.

La memoria virtual, junto con un inteligente algoritmo de compresión de textos hicieron que los juegos de INFOCOM fueran los mas avanzados, complejos y largos durante años.

El Z-code era de un nivel parecido al ensamblador con algunas instrucciones especiales. Por lo tanto de crear los juegos directamente en Z-Code hubiera sido una tarea completísima. Usando su experiencia con grandes maquinas, decidieron crear un lenguaje especial de alto nivel para crear aventuras que se compilara generando z-code. Este lenguaje no era ni mas ni menos que un MDL (o sea LISP) muy simplificado, quitando cualquier cosa que no hiciera falta para hacer juegos de aventuras y añadiendo cosas que ayudaran al desarrollo.

Mirando por Internet, ninguno de estos compiladores de ZIL (Zork Implementation Language) ha sobrevivido hasta nuestra época, pero si alguna de la documentación para crear juegos, con lo cual podemos saber mas o menos como funcionaba. Y para ser un sistema de finales de los 70-principios de los 80, era toda una maravilla al servicio del creador de aventuras. Probablemente hasta la llegada de los sistemas especializados para PC a mediados de los 90, como TADS o Inform, no hubo mejor entorno para la creación de conversacionales.

El Zork Implementation Language: ZIL

Pero vamos a meternos en materia. La programación se realizada en este pseudo-LISP y la visión desde el punto del programador era bastante orientada a objetos, aunque la Programación Orientada a Objectos aun no se había desarrollado del todo por entonces, así que tiene algunas cosas un poco "raras", vistas hoy en día.

Lo primero vamos a estudiar la definición de una habitación:

<ROOM LIVING-ROOM
    (LOC ROOMS)
    (DESC "Living Room")
    (EAST TO KITCHEN)
    (WEST TO STRANGE-PASSAGE IF CYCLOPS-FLED ELSE "The wooden door is nailed shut.") 

    (DOWN PER TRAP-DOOR-EXIT)
    (ACTION LIVING ROOM-F)
    (FLAGS RLANDBIT ONBIT SACREDBIT)
    (GLOBAL STAIRS)
    (THINGS <> NAILS NAILS-PSEUDO)> 

Lo primero que salta a la vista es que se usan a la vez los paréntesis típicos de LISP con partes que se señalan con < y >, como las definiciones de habitaciones, objetos y las llamadas a funciones de sistema.

En todo caso, el lenguaje funciona como LISP, de forma que todo son listas de elementos entre paréntesis (o "<" ">"). Asi que una habitación es simplemente una lista con el identificador al principio ("ROOM LIVING-ROOM") seguida de las propiedades de la habitación. El primero "LOC" es el lugar donde esta el objeto, porque en realidad las habitaciones se tratan como objetos, solo que están siempre en el objeto especial ROOMS. Seguidamente tenemos las salidas, incluyendo una salida condicional que es bastante auto explicativa. La salida hacia abajo, mas complicada, en realidad llama a la función TRAP-DOOR-EXIT para decidir si se puede pasar o no.

La siguiente linea, ACTION, define la función que tratara algunos asuntos de la habitación, lo veremos mas adelante. Luego tenemos los objetos globales que están presentes en la habitación y la ultima linea es indescifrable para mi. Como podéis ver es un lenguaje bastante potente para definir cosas (contando en el año que estaban) y que a mi gusto me parece mas claro que lenguajes mas nuevos como Inform.

Habiendo visto una habitación, el código de un objeto es también bastante claro

<OBJECT LANTERN
    (LOC LIVING-ROOM)
    (SYNONYM LAMP LANTERN LIGHT)
    (ADJECTIVE BRASS)
    (DESC "brass lantern")
    (FLAGS TAKEBIT LIGHTBIT)
    (ACTION LANTERN-F)
    (FDESC "A battery-powered lantern is on the trophy case.")
    (LDESC "There is a brass lantern (battery-powered) here.")
    (SIZE 15)>

Aparte de los parámetros ya explicados tenemos diferentes descripciones para cuando se examine o se describa con la habitación, su peso, los flags que indica que da luz y se puede coger junto con los adjetivos y sinónimos que el jugador puede usar. 

Las funciones y el parser

Tal vez la parte mas potente de ZIL en si es la capacidad de crear funciones, que se pueden utilizar para crear la interacción con el juego. Se definían así:

<ROUTINE TURN-OFF-HOUSE-LIGHTS ()
            <FCLEAR ,LIVING-ROOM ,ONBIT>
            <FCLEAR ,DINING-ROOM ,ONBIT>
            <FCLEAR ,KITCHEN ,ONBIT>>

Como podéis ver vuelven a aparecer los "<" ">", tanto para definir la rutina como para las función de sistema FCLEAR (pone a cero un flag de un objeto, en este caso el de la habitación tiene luz). Las funciones admiten parámetros, variables locales y hasta parámetros opcionales, en la forma:

< ROUTINE CALLEE (X "OPT" Y "AUX" Z)
            <some-stuff>> 

Digamos que el lenguaje tenia muchas comodidades que tardarían en llegar años al a programación en general!

Bien, pues estas funciones se utilizaban para interpretar las acciones del usuario. Primero el parser léxico identificaba un verbo, objeto directo y indirecto (si están presentes). Entonces dará la oportunidad a cada uno de estos objetos (o mas bien a su función ACTION) en el orden inverso de resolver el comando o si no dará el típico de "No puedes hacer eso". Para ello utiliza una función COND, que es una lista de pares condiciones - acciones, de las que solo se ejecute la primera que se evalúe a cierto con la forma:

<COND (<predicado-condicion-1> 

           <hacer-algo-1>)

         (<predicado-condicion-2>

           <hacer-algo-2>)

         (<predicado-condicion-3>

           <hacer-algo-3>)> 

En cada predicado podemos comprobar si el verbo y los objectos cumplen ciertas condiciones o si el estado del juego es el correcto para activar un programa que muestre un mensaje, mueva objetos, etc. Cuando se empiezan a amontonar paréntesis es un poco complicado, pero en realidad es mucho mas fácil de definir y releer condiciones complejas que con otros sistemas de los 80. Por ejemplo, podemos responder una acción así al comer un aguacate envenenado:

<ROUTINE AVOCADO-F ()
     <COND (<VERB? EAT> 

               <SETG PLAYER-POISONED T>
               <REMOVE ,AVOCADO>
               <TELL "You begin to feel sick.">)>>

Creo que es bastante auto-explicativo, pero SETG cambie el valor de una variable global, en este caso a cierto (T, es decir true), REMOVE quita un objeto (cambiando su propiedad de LOC, en realidad los objetos no se pueden destruir) y TELL muestra un mensaje por pantalla.

Las acciones de habitación, mencionadas al principio, en realidad lo hacen nada con el input del jugador, si no ejecutan ciertas funciones necesarias en cada habitación. Esta función recibe un parámetro en el que se especifica que tiene que hacer, siendo el mas habitual "M-LOOK", para describir la habitación como aquí:

<ROUTINE CAFETERIA-F (RARG) 

   <COND (<EQUAL? .RARG ,M-LOOK>

         <TELL "This is a lunch room, with windows overlooking a loading dock. ">

         <COND (<IN? LUNCH-CROWD ,CAFETERIA>

                <TELL "Every table is jammed with patrons. ">)>

                <TELL "The only exit is north." CR>)>>

Esto es especialmente útil para habitaciones que cambian con el tiempo o si hay algún objeto especial dentro. También hay funciones adicionales para cuando el jugador entra, sale o realiza una acción dentro de cada habitación; así que podemos controlar todo lo que ocurre dentro de la habitación.

Aun quedan muchas mas cosas, como crear personajes interactivos, timers, la definición del léxico... pero todo esto se hace de una manera parecida a la que hemos visto, así que si tenéis interés en saber aun mas de las interioridades de ZIL os recomiendo echar un vistazo a la bibliografía.

Conclusiones

Como podéis ver es un lenguaje muy potente, que permite especificar acciones complejas de una manera sencilla. Y todo en una época cuando muchos programadores la herramienta mas elaborada que tenia era un BASIC de 8 bits. Desde luego este sistema de creación de aventuras se tradujo en que las aventuras de INFOCOM fueran las mas depuradas, complejas y avanzadas durante toda su vida. Digamos que ello tenían una sierra mecánica para cortar arboles cuando la competencia usaba una lima de uñas.

Una parte de estas herramientas estaban tan bien diseñadas que sobrevivieron durante años, llegando hasta hoy en día. Me refiero al estándar de Maquina-Z, que esta aun vivo y portado a todos los sistemas existentes gracias a que fue la plataforma que Graham Nelson decidió para que su compilador Inform. Y aun hoy en día se crean aventuras con esta herramienta para las versiones clásicas de la máquina-Z. Desde luego el estándar ha sido extendido para soportar gráficos, sonido y quitar el limite de memoria entre otras cosas; pero hoy en día no hay ningún interprete de aventuras que no soporte el estándar Z.

Por desgracia, mientras que la máquina-Z aun sigue viva hasta hoy, el compilador ZIL se ha perdido en el tiempo y solo nos queda su documentación...

Update 2019

Recientemente se ha liberado el codigo fuente original en ZIL de todos los juegos de Infocom, como el mismo Zork I. No se ha recuperado el compilador original, pero solo con los fuentes podremos aprender nuevas cosas de como trabajaba Infocom.

Bibliografía y links de interés

• Post recomendadísimo en "The Digital Antiquarian" sobre las herramientas de INFOCOM .
• Documentación interna de INFOCOM sobre ZIL que ha sobrevivido hasta nuestros días.
• Entrada en Mobygames de Zork I, de donde he sacado la captura de esta entrada.
• Frotz, un interprete moderno y portable de la máquina-Z.
• (Nuevo!) Repositorio con todos los sources de Infocom

Entradas anteriores

• Sistemas para crear aventuras conersacionales (I)
• Sistemas para crear aventuras conversacionales (II) : Scott Adams

Continuando las primeras impresines de Pokemon X/Y

listen to ‘Continuando las primeras impresines de Pokemon X/Y’ on Audioboo

Estaba vez centrandome en la nueva entrega en si.