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.

Mis historias con Pokemon y primeras impresiones del Pokemon Y

listen to ‘Mis historias con Pokemon y primeras impresiones del Pokemon Y’ on Audioboo

Hablo un poco de los juegos de Pokemon que jugué y sobre el nuevo Pokemon Y.

Atomic Runner para Megadrive y arcade

Este juego, también conocido como Chelnov aunque yo siempre lo recordare como Atomic Runner, es una recreativa clásica de Data East en que nuestro protagonista no parara de correr hacia delante (bueno, no, puede pararse, pero el scroll no se detiene nunca) y destruir enemigos de lo mas variopinto con un gran arsenal.

Es un juego difícil, pero como pasa con otros arcades complicados, una vez has jugado unas cuantas partidas y lo dominas se hace un juego muy gratificante. Ademas, la variedad de armas y situaciones lo hacen un juego muy entretenido y con muchos detalles para dominar.

En la versión arcade siempre me llamo la atención esos escenarios oscuros y llenos de elementos orgánicos, como manos que salen de la tierra o esa especie de "estatuas humanas" que aparecen de vez en cuando. Los enemigos también son de lo mas variopinto, desde humanos en armadura, arañas, estatuas de dioses mitológicos que cobran vida o enemigos tecnológicos... Lo cierto que quien quiera que diseño este juego tenia mucha imaginación y muchas ganas de mezclar conceptos.

Tuve la oportunidad de jugar mucho a este juego en recreativa y cuando despareció de las salas de juegos que frecuentaba dejo para mi un gran vació. Es una pena que ni siquiera tuviera una conversión a los 8 bits de la época, ya que este tipo de recreativas era frecuentemente trasladadas a Spectrums y otros ordenadores domésticos. Y es que ni siquiera conozco ningún juego de entonces que clonara las mecánicas, como hacia el clásico de Dinamic Satan con Black Tiger.

Cuando, años mas tarde, se anuncio una versión para Megadrive me dio mucha rabia no tener una entonces para jugarlo. Lo cierto es que al principio me decepciono un poco, porque habían cambiado los escenarios mas "oscuros" que yo recordaba por una orgía de color. Pero a pesar de eso, lo de hacer un collage de varias cosas seguía presente, porque sino que me expliquen que hace la Sagrada Familia en Rusia!

Un año mas tarde y ya con Megadrive, me hice con este gran cartucho y pude disfrutar mucho mas que en la recreativa (lo que tiene que cada continue no cueste cinco duros) y de la gran banda sonora de esta versión (que siendo sincero me parece mejor que el arcade).

Poniéndolo en perspectiva, Atomic Runner es una arcade que hoy en día aun sigue siendo muy divertido. El lavado de cara de la versión de Megadrive ha envejecido bastante bien, ya que algunos detalles gráficos del arcade, como algunos enemigos o fondos negros, son muy sencillotes, pero ambos te pueden hacer pasar una buena tarde en cualquier momento.

Aquí os dejo un vídeo en que echo unas partiditas a cada versión, espero que os guste.

P.D.: No comento nada de la historia porque en el arcade siempre iba demasiado rápida para leerla y la historia de la intro en Megadrive me parece tan ridícula que prefiero no contarla.

P.P.D.: Tampoco voy a hablar del parecido del nombre de Chelnov con Chernobil, ya que yo nunca lo recordé/conocí por ese nombre.

P.P.P.D.: En cambio si me interesa saber que hubo un port para Saturn del arcade original que fue cancelado pero que apareció hace poco.

Impresiones de dos juegos de iOS que no me han gustado

listen to ‘Impresiones de dos juegos de iOS que no me han gustado’ on Audioboo

Mis impresiones de Metal Gear Solid Social Ops y AD&D Arena of War, que me sirven para desahogarme un poco.

Como simular el movimiento de un RPG clásico en primera persona con Unity 3D

Eye of the Beholder, Ishar, Dungeon Master, Wizardray... Son solo alguno de los mas famosos nombres de RPGs en primera persona que triunfaron en los '80 y principios de los '90. Debido a limitaciones técnicas, estos juegos simulaban una vista 3D usando unos cuantos trucos que hacían que funcionaran en casi cualquier maquina. Los primeros y mas sencillos RPGs en primera persona dibujaban los pasillos de las mazmorras como lineas en perspectiva, creando la sensación de profundidad. Era un efecto que dejaba todo a la imaginación, pero tenia la ventaja que prácticamente cualquier maquina que tuviera gráficos lo podía manejar.

Un poco mas adelante, cuando las capacidades gráficas de los ordenadores y las técnicas de programación mejoraron, se empezó a utilizar un nuevo método que simulaba las paredes de los pasillos esta vez con todo detalle. El truco estaba en que el diseñador creaba, para cada tipo de pared, un gráfico desde todas las perspectivas posibles. Normalmente no eran muchas, de frente y de lado a 3 o 4 tamaños máximo. Y luego, dentro del juego, los colocaba siguiendo un mapa 2D, simulando la profundidad con los diferentes tamaños (grandes cerca, pequeños lejos). La técnica era bastante "espectacular" para la época y fue muy usada con juegos que están en la memoria de todos como los anteriormente mencionados.

 Pero también esta técnica tenia grandes defectos. Primero por que estaba limitado a un mapa 2D con paredes perpendiculares y segundo porque, al no poder haber transición entre un punto a otro del mapa, el movimiento era a saltos. Este movimiento brusco era bastante confuso hasta que te acostumbrabas, y muy desconcertante si tu no controlabas el personaje.

Con el tiempo este sistema callo en el olvido al ser remplazado primero por sistemas de ray casting (Legend of Valour, Elder Scrolls Arena como ejemplos primerizos) y mas adelante por engines 3D reales. Pero creo que en el proceso se perdió una parte de la magia y sencillez de estos primeros RPGs, que conseguían recrear un mundo 3D en cualquier maquina. No en vano aun hay juegos que intentan recuperar esta sistema junto con otros detalles retro, como Legend of Grimrock o Grimoire.

Pues bien, como un engine de este tipo es muy fácil de simular con un engine 3D actual, aquí tenéis un pequeño tutorial, con proyecto incluido, que muestra como crear vuestra vista en primera persona clásica en Unity 3D. Obviamente es solo una simulación, ya que los juegos originales utilizaban técnicas muy diferentes, pero es fácil crear una ambientación parecido.

Para el tutorial he utilizado texturas de alta calidad, pero nada os impide utilizar texturas mas retro para darle ese look vintage. También comentar que es necesario conocimientos básicos de como funciona Unity para poder seguirlo.

Espero vuestros comentarios!

Update con los links

No me había dado cuenta que con el vídeo empotrado es complicado que vierais los links que había en la información de youtube. Así que aquí los teneis:

El proyecto se puede descargar aquí
https://mega.co.nz/#!OB1WkRyC!DveNGEi...

(la demo se controla con los cursores)

El articulo en la Wiki de Unity sobre el movimiento en rejilla
http://wiki.unity3d.com/index.php/Gri...

Texturas usadas en la demo
http://opengameart.org/content/pietex...
http://opengameart.org/users/yughues

Y muchas mas arte libre en http://opengameart.org/

Sobre mi nuevo proyecto de videojuego con Unity 3D

listen to ‘Sobre mi nuevo proyecto de videojuego con Unity 3D’ on Audioboo

Hablando un poco de mi nuevo proyecto de videojuego, nuevamente un RPG en primera persona con toques retro, pero esta vez con ambientación anime.

Impresiones del GTA V despues de 20 horas

listen to ‘Impresiones del GTA V despues de 20 horas’ on Audioboo

Lo que mas me gusta del juego después de perderme mas de 20 horas por Los Santos y alrededores.

Vamos a jugar al Space Quest IV (parte 2)

Continuamos con las aventuras de Roger Wilco en Space Quest IV dentro de Space Quest XII, repitiendo una parte que nos habíamos dejado y viajando atrás en el tiempo hasta Space Quest X.

Primeras impresiones de Grand Theft Auto

listen to ‘Primeras impresiones de Grand Theft Auto’ on Audioboo

Mis impresiones cuando solo llevaba unas pocas horas jugando con el GTA V

Vamos a jugar al Space Quest IV (parte 1)

A principios de los 90 vivía feliz con mi Spectrum +2 y mi flamante Amstrad CPC+ recién adquirido de un saldo del Continente. En aquella época mi principal fuente de información videojueguil provenía de la Microhobby, que ademas me proveía de una buena ración de demos y juegos completos. Pero un día de 1992, no llego a recordar si porque ya no había Microhobby, decidí atreverme con esa gran revista que era la Micromania. Y lo de grande lo digo porque por aquel entonces era tamaño que mas que periódico parecía una manta.

Y esa compra fue un shock para mi. Yo vivía tan feliz con mis juegos de 8 bits; pero esta revista me abrió los ojos a un nuevo e incipiente mundo: los 16 bits. Jamas olvidare la juegos como Future Wars o Heart of China, junto con la solucion del juego que hoy nos trae aquí, Space Quest IV. Yo era gran fan de las aventuras conversacionales, y devoraba todo lo que AD sacaba, pero este nuevo mundo de color, ratón e iconos me parecía la evolución natural del genero y me quede prendado de las nuevas aventuras gráficas.

Paso mucho tiempo hasta que tuve un PC, y aun mas hasta que pude jugar finalmente al Space Quest IV, cuando ya era casi un juego pasado de moda, pero esta aventura tiene un rincón muy especial en mis recuerdos sobre el ocio electrónico.

No me la acabe en su tiempo, y apenas recuerdo nada quitando la parte del principio, pero espero pasármelo, aunque tenga que echar un vistazo de vez en cuando a la solución.

P.D.: Curioso es que buscando una solución en internet, encontré esta en Meristation, fechada en nada mas y nada menos que en 1993, antes incluso que existiera la revista electrónica como tal.

Compras de septiembre 2013

listen to ‘Compras de septiembre 2013’ on Audioboo

Un repaso a mis (escasas) compras de septiembre.

Making-of de "Tokyo Super Night"

Como sabéis Tokyo Super Night ya esta disponible tanto en iOS como en Android, así que para celebrarlo grabe un vídeo explicando como funciona la versión Android. Esta versión esta hecha con el sistema de desarrollo Unity 3D, sin usar ninguna extensión especial. No estoy seguro que sea de utilidad a nadie (demasiado técnico para gente que no conozca el mundillo, pero poco profundo para quienes sepan de que va esto de la creación de juegos), aunque si tenéis curiosidad en saber que hay detrás de un juego 2D sencillo, echadle un vistazo.