SPAC
Portada > Webzine > Temas subjetivos > Entrevistas > Entrevista a Rubes (Creador de Vespers 3D)

Entrevista a Rubes (Creador de Vespers 3D)

(E inventor de un nuevo medio: IF/3D: Aventuras Conversacionales en 3D)

Lunes 21 de julio de 2008, por El Clérigo Urbatain


- Mike Rubin es un autor independiente y mente pensante tras el experimento Vespers 3D. Como sabéis Vespers es la muy premiada Ficción Interactiva de Jason Devlin, y esa coletilla 3D significa lo que estais pensando. Vespers 3D, un trabajo en progreso, será el primer juego en la historia en mezclar las aventuras conversacionales con los juegos FPS tipo Quake de alta calidad; un proyecto que para mí es como maná caido del cielo, pues sintetiza con éxito un tema en el que yo mismo me he embarcado (de forma mucho más modesta que él, hay que decir). Rubes es su nick...

Nota: a lo largo de la entrevista se usan los términos IF, AC, Ficción Interactiva, Aventuras, Aventuras Conversacionales, Aventuras de Texto, Juegos de Texto de forma indistinta, sin hacer distinciones dentro del medio como tal.

Urbatain: Rubes, para empezar, me gustaría saber algo más sobre tí, como te he dicho en privado, estoy realmente expectante con tu proyecto, y algo que me golpea muy positivamente es que todo esto no es simplemente el vaporware de un wannabee, has venido aquí con los deberes hechos, hay maravillosos pantallazos ahí en la red, hay videos, y todos los conceptos de diseño sobre el modelo de mundo ya han sido discutidos y detallados. Así que, es evidente que tienes un recorrido detrás. Cuéntanos un poco sobre tí, y la Ficción Interactiva, cuando la encontraste y si has realizado algún juego de sólo texto antes.

Rubes: Bien, yo no iría tan lejos diciendo que mis labores están hechas; probablemente sólo tenemos hecho un 20% del juego, pero comprendo lo que dices y te lo agradezco. He jugado IF durante mucho tiempo, aunque no he jugado a un gran número de juegos. Recuerdo jugar a la original Colossal Cave en la computadora de mi padre, en los 70, aunque no puedo decir específicamente qué versión era, probablemente sólo tenía 8 o 9 años en aquellos tiempos. Recuerdo que lo teníamos en un disquete de 5.25", y yo me entusiasmaba cuando tecleaba un comando que causaba que la disquetera comenzase a girar — eso significaba que había encontrado algo nuevo y que algo bueno iba a ocurrir. Desde ahí tiré más hacia los juegos de Scott Adams, como Adventureland, y Pirate Adventure. Amo esos juegos.

Nunca he escrito una pieza de IF por mí mismo, sin embargo, creo que puedo escribir bien, pero no me considero un buen escritor creativo. Sin embargo, he tenido algunas ideas al respecto. Si no estuviera trabajando en Vespers, creo que lo intentaría ahora.

Urbatain: ¿Y cómo un desarrollador indie? Dos mundos se juntan aquí, la IF y el desarrollo de juegos en 3D. Cuéntanos algo acerca de tu experiencia como un desarrollador de juegos gráficos.

Rubes: Bueno, no he empezado desde cero, pero no muy lejos de eso. Sólo he creado un juego indie, un juego shareware para Mac allá a mediados de los 90 llamado "Missions of the Reliant". De pequeño, aprendí a programar y me moría por hacer un juego, pero como la mayoría de los niños no tenía ni idea de lo que estaba haciendo y nunca conseguí nada. Pero a principios de los 90, con algo de tiempo extra en mis manos, decidí ponerme en serio a ello. Bueno, no tan serio, considerando que yo era un estudiante de graduado (bachiller) perezoso en aquella época. Y realmente aún no tengo ni idea de lo que estaba haciendo, pero al menos llegué a algún lado con él. "Missions" era un juego en 2D basado en sprites, inspirado por aquel viejo juego en ASCII "Star Trek" donde saltabas de sector en sector en una rejilla aniquilando Klingons con torpedos de protones y fasers. Lo hice prácticamente sólo, y creo que lo hice bastante bien para un juego shareware de entonces. Fué nominado por el magazine "MacUser" para "Mejor juego shareware para Mac" de 1994, creo, y quedó en segunda posición (¡maldito Andrew Welch!).

Fue una experiencia divertida, pero en tanto que seguí con mi vida cada vez encontraba menos tiempo o entusiasmo para más desarrollo de juegos. Entonces, hace unos cuantos años, me entró el gusanillo de nuevo, así que empecé a echar un vistazo. Y realmente eso es todo en cuanto a mi historia sobre ser un desarrollador indie — un pequeño juego espacial hace veinte o treinta años.

Urbatain: Por supuesto tienes un equipo contigo para esta empresa. Es casi imposible realizar un juego de calidad sin gente con talento detrás. Así que, cuéntanos algo acerca de tu companía independiente. ¿Cómo se organiza, si tenéis una oficina o si realmente los miembros contactan por la red?

Rubes: Tienes razón, realmente no hay manera de hacer un juego en 3D como este sin un montón de ayuda. Sin embargo, aún somos un grupo muy muy pequeño. El nombre de la compañía es "Orange River Studio", que es algo así como un tributo a los cañones (desfiladeros) de Utah (donde vivo) y a la habitación de la aventura original Colossal Cave. Ahora mismo, el grupo está formado por mi mismo, Jason Devlin (el autor de Vespers), un modelador 3D (N.R.Bharathaw), dos animadores de personajes (James Allan y Marc Schwegler), y un compositor (Daniel Godsil), aunque algunas de esas personas trabajan de forma independiente para la compañía. Este proyecto realmente comenzó como un hobby más que otra cosa, así que estamos aún en el proceso de evolucionar hacia algo más organizado. Estamos dispersos por toda Norte América (y Suiza), así que no hay nada de oficinas. Todos trabajamos desde nuestras casas, hasta donde yo sé, y creo que la mayoría de nosotros tenemos trabajos a diario y hacemos todo este trabajo por las noches y los fines de semana.

Urbatain: Echas las presentaciones, vamos al grano. ¿Cuándo te vino la idea de realizar un juego de Ficción Interactiva (3D o 2D) con gráficos?

Rubes: Bueno, como he mencionado, hace unos cuantos de años me dio el gusanillo otra vez de hacer un juego. Realmente no preveía hacer un juego en 3D, creo, porque no tenía interés en la complejidad de los motores gráficos en 3D y los pronunciados requerimientos gráficos, pero de alguna manera tropecé con el motor "Torque Game Engine" de GarageGames, y de repente me pareció que hacer un juego en 3D era una posibilidad. Aún existían grandes obstáculos por vencer con respecto a la generación de contenidos, pero después de considerarlo pensé que le daría una oportunidad.

La parte fácil fué decidir hacer un juego; la parte difícil fué decidir qué juego hacer. No recuerdo exactamente cómo me vino, pero al inicio del proceso decidí intentarlo y mezclar la IF con un motor en 3D. Creo que es algo que nadie antes ha intentado, y podría ser una manera de combinar lo mejor de ambos mundos, hacer una aventura que sea más interactiva e inmersiva. Parecía una tontería intentarlo, al principio, e incluso algunos días parece muy tonto. Pero sé que el texto ofrece algo que los juegos AAA FPS no tienen, y viceversa. Así que pensé en darle una oportunidad con un "pequeño experimento" — un juego que sea corto y más contenido. Ésa es la razón por la que comencé a mirar en las IF comps buscando posibles juegos a implementar.

Urbatain: Yo siempre he soñado con la evolución de las primeras crudas mezclas entre los gráficos y una interfaz por parser; más en concreto, hoy en día estoy realmente interesado en implementar el mismo tipo de profunda interactividad de los modelos de mundos de Inform y TADS en un juego gráfico, no me importa la interfaz, point and click, iconos, FPS, no me importa, lo único que sé es que quiero hacerlo... algún día. Y entonces voy y te encuentro a ti, desarrollando la misma idea y con un juego que no es materia fácil de "portar" al tipo de materia que estamos hablando. Entonces... ¿Por qué Vespers? Creo que por sus finales, interacciones... es un juego difícil de portar a 3D...

Rubes: No quise comenzar completamente desde cero con este experimento, así que, como he mencionado, eché un primer vistazo a las IF comp en busca de un buen juego en cual basarme. Y empezar con un juego de IF completo, mucho trabajo de base importante y difícil ya estaría realizado, y podría comenzar con un juego que ya tendría una buena escritura, personajes fuertes, y un guión desarrollado — algo que muchos juegos grandes del momento no tienen. Esto no es tan distinto de como un productor de películas busca un libro de éxito para su siguiente proyecto, supongo.

Después de jugar a un buen número de juegos de las IF Comp de diferentes años, encontré que había disfrutado Vespers muchísimo, y caí en la cuenta de que sería un juego gráfico realmente interesante. Algunas de las cosas que me gustan sobre Vespers es que, siendo un juego corto, estaba relativamente bien contenido, sin muchas habitaciones u objetos, y además tenía unos cuantos puzzles decentes, así que no sería desesperante de implementar todo el asunto. Además me encantaba el escenario y la atmósfera del juego, al igual que los personajes, diálogos, e historia. Creo que funciona muy bien en texto, pero además pensé que presentaba una gran oportunidad de traducirlo a un juego gráfico. Tenía la sensación de que sería divertido explorar ese mundo en 3D, y que funcionaría en este tipo de medio.

También, definitivamente, tiene sus desafíos, creo. El juego se basa profundamente en los diálogos, eso significa que los personajes deben de ser modelados, animados, y doblados con voz, todo realizado con calidad o acabará siendo muy artificial. Además hay algunas escenas que serán difíciles de montar, como la escena de la avalancha, la escena en el sótano, o la escena final. Pero creo que seremos capaces de lograr algunas soluciones satisfactorias para estas. O al menos eso espero.

Urbatain: Deberías haber escogido otra, algo más típico típico del género. Tu sabes, las mayoría de los trabajos de aventuras son simplemente mundos modelados en detalle pero donde el tiempo es más o menos estático. Pero por supuesto creo que un paradigma más moderno será una mejor motivación y mayor desafío, así que pienso que Vespers es perfecto para tu experimento, de hecho, cualquier juego posterior a Fotopía mostraría todo el potencial que estás buscando...

Rubes parpadea perplejo... lost in translation.

Urbatain: Me refiero a que Vespers... es plena y abundante Ficción Interactiva en toda su gloria, y que por eso es un juego difícil de portar a un juego gráfico. Me pregunto si no deberías de haber empezado por algo mucho más simple, sin apenas "contacto físico", sin ramas en la historia, sin elección real por parte del jugador, sobre qué ser, o qué hacer. Ya sabes... la típica tópica exploración de cavernas. ¿Quizás debiste de comenzar este experimento con un modelo de mundo más sencillo?

Rubes: ¡Y ahora me lo dices! :)

De hecho, todo eso es probablemente cierto, y si hubiese pensado un poco más sobre ello al principio, creo que habría comenzado con una abreviada implementación de Collossal Cave o algo similar. No obstante, las cavernas realistas pueden ser un poco difíciles de modelar convincentemente en 3D, así que quizás no. Cuando comencé, mi mayor preocupación era encontrar una aventura que fuese breve (para mantener el alcance del proyecto bajo) y factible (para limitar los desafíos de implementación). Vespers presenta algunos problemas de viabilidad — como implementar la larga marcha a caballo hasta el río, la avalancha, la escena con los lobos, etc — pero tenemos algunas soluciones para estos problemas. Lo que más encuentro interesante acerca de estos desafíos es que van al corazón de las diferencias entre un juego de aventuras basado en turnos y el tiempo real del 3D, y espero que el juego genere bastante discusión sobre los caminos alternativos para resolver estos problemas.

Urbatain: Tengo dos juegos en mente que creo valdrían muy bien para portar a gráficos. Tenemos uno en español, El Anillo, en donde el jugador es un anillo que sólo puede hacer: examinar, mirar, brillar, aumentar de tamaño y disminuir de tamaño, y hablar con quien lo lleve puesto. Así que es un modelo de mundo fácil de implementar (en la primera parte, luego el anillo controla a un jorobado retrasado, con lo cual la cosa se complica); se podría implementar como el juego flash Sprout (haced una búsqueda en Google y jugadlo, merece la pena). Otro podría ser Spider and Web, de hecho, le comenté esta posibilidad a Zarf, pero el fue pesimista en cuanto a que funcionase bien como juego gráfico "arcade". Todo esto me lleva a Vespers: ¿Cómo decides finalmente implementar la interfaz y el modelo de mundo tal como está ahora? ¿Has considerado otro tipo de aproximaciones para implementar un modelo de mundo de IF decente, en 3D?

Rubes: Esa es una buena pregunta. Uno de los mayores retos al implementar un juego de IF en 3D en tiempo real es que la aventura es basada en turnos tradicionalmente; la actividad sólo toma lugar entre los comandos del prompt, y los jugadores tienen todo el tiempo que quieran para ponderar cual será la siguiente acción. Por supuesto, en un juego en tiempo real hay, generalmente, más presión sobre los jugadores para pensar y escribir rápido, pero ese no es el juego que quiero crear. Así que he intentado diseñar el sistema y la interfaz para que sea un híbrido entre tiempo real y juego basado en turnos.

Un juego basado en turnos es en realidad un juego que espera la entrada del jugador para poder avanzar la acción una cierta cantidad, y este juego en realidad no es diferente a eso — a pesar de que da la apariencia de que transcurre en tiempo real. Ocurren cosas alrededor del jugador todo el tiempo, pero éstas no son más que actividades anodinas, y la mayoría actúan de forma continua o al azar hasta que el jugador realiza una orden o algún tipo de acción significativa para interrumpirlas. No se diferencia mucho de un juego basado en turnos, al menos de la forma en que lo estoy implementando.

Lo que estoy haciendo es una traslación directa de un juego de texto basado en turnos, haciendo representaciones (animadas) gráficas de objetos y personajes que está definidos de forma similar al código original en Inform. Por este motivo, nuestro modelo de mundo es muy cercano al que existen en IF, sólo que con modelos, animaciones, y relaciones espaciales más detalladas. Pero, como éste es el acercamiento que yo he tomado, realmente no estoy presionando los límites del medio, por decirlo de algún modo. Hay mucho más que se podría hacer, yo, sencillamente estoy usando este experimento para ver de qué es capaz el modelo, después ya probaremos sus límites con un futuro proyecto.

El verdadero reto viene en las escenas que contienen una actividad continua, como la avalancha o la escena del sótano de Vespers. Es un desafío crear todo eso en un juego de texto basado en turnos, por supuesto, pero nunca hay ninguna desviación del, estrictamente discreto, juego basado en turnos. Una vez que entras en el mundo del 3D animado, incluso este pseudo-tiempo-real, tropiezas con problemas donde el jugador está esperando a tomar la acción. Hay ciertas cosas que podemos hacer al respecto, pero requieren un montón de trabajo creativo el realizar esas escenas.

Urbatain: Esto es muy interesante, pero tienes algunos ejemplos reales de tiempo real en las aventuras, o casi, puedes mirar en algunos MUDs o por ejemplo en Castle Marach de Skotos; y un amigo mío está haciendo un sistema para hacer MUDs y aventuras al mismo tiempo (¡aventuras multiplayer al alcance de la mano! ¡Al fin! ;) ¿Cuantas veces oiremos esto?) donde las acciones llevan cierto tiempo realizarlas, de esta forma un jugador puede ver como otro jugador comienza a forzar una cerradura, luego ve como está forzando la cerradura, y finalmente observa cómo termina de forzar la cerradura. Entonces, finalmente, ¿Has hecho algún control sobre el paso del tiempo en ciertas acciones?

Rubes: Todavía no he alcanzado ninguna de esas situaciones del juego, pero pronto lo haré. Hay unas cuantas de esas en Vespers, como las que hemos mencionado antes, donde las acciones toman lugar sobre un cierto número de turnos. No estoy completamente seguro sobre cómo funcionará el sistema, pero creo que será algún tipo de híbrido entre juego basado en turnos y jugar en tiempo real. Por ejemplo, al jugador, probablemente, se le dará mucho tiempo para pensar, pero no será un juego basado en turnos puro donde el tiempo sólo avanza cuando las acciones se realizan.

Urbatain Otro juego que me gustaría portar a toda posible plataforma o formato con gráficos es un mío llamado "El Extraño Caso de Randolph Dwight", es un experimento sobre eliminar los puntos cardinales, así que, aunque hay habitaciones, el jugador debe preceder dentro y fuera de ellas con la acción "IR HACIA", ve cerca del armario y ábrelo, ve a través de la puerta, etc. Este juego tiene un sistema donde el jugador camina automáticamente cerca del objeto que se necesita interactuar (Shade de Zarf también usa en cierto modo este tipo de aproximación con bastante éxito), veámoslo con un ejemplo:

>abre el armario
Caminas hacia el armario y lo abres, descubriendo tus ropas.

Implementé esto porque mis testers protestaron porque el mensaje "Estás demasiado lejos para hacer eso...", y además para ciertas acciones podía ser un poco tedioso y cansado. Pero he visto en tus pantallazos que en Vespers 3D este tipo de mensaje será usual. ¿Porqué decidiste esa aproximación? o, ¿quizás es algo más flexible?

Rubes: He intentado ser flexible con esto, aunque he tenido que poner el límite en algún sitio. Estoy muy en contra a tomar el control del avatar del jugador y moverlo alrededor sin consentimiento — puede ser molesto para algunos jugadores, e introduce unos cuantos problemas con los que tratar, tales como búsqueda de caminos. Pero, precisamente por esto, para la mayoría de las acciones he tenido que crear una serie de comprobaciones para ver si la acción está permitida. Una de estas comprobaciones es para la distancia, y una forma en la que he intentado ser flexible es permitiendo diferentes distancias máximas para diferentes acciones. Asi que, para algunas acciones más generales, como coger o abrir, puedes estar a una cierta distancia, pero para otras, como leer, necesitas estar más cerca. Esto puede llevar a cierta frustración por parte del jugador, estoy seguro, pero no quiero que los jugadores sientan que está bien cerrar puertas a más de 30 pies de distancia, en el otro lado de la habitación.

Algunas de estas comprobaciones son para cosas como la línea y campo de visión, simplemente para asegurarnos de que el jugador no está intentando una acción sobre un objeto que está a su espalda, por ejemplo. Pero la meta de estas comprobaciones no es hacer el juego hiperrealista; tiene que haber cierta flexibilidad para que los jugadores en general no se fustren. Ya veremos como va cuando pongamos a gente a testearlo.

Urbatain: Sí, hay que tener cuidado con esta característica de mi "Dwight", algunas acciones eran demasiado peligrosas al dejar que el avatar se moviese por si solo automáticamente, un pequeño examinar te podía lanzar a una muerte segura. Creo que no hay una solución perfecta para todo esto, aunque, ¡ey!, un "examinar" inteligente que de diferente información dependiendo de lo cerca que estés de un objeto, puede ayudar. Piensa en la escena de Vespers:

>examina el árbol
Vale, caminas hacia allí y pasas por alto el circulo de lobos que te rodea, los cuales están muy contentos de que te unas tan voluntariamente a su festín.

Rubes: Sí, creo que algunas acciones como "examinar" pueden implementar diferentes respuestas basadas en la distancia entre el jugador y su objetivo, aunque eso introduce más requerimientos de contenido. Pero la mayoría de los verbos, desafortunadamente, no se conforman a esa estructura.

Urbatain: Hablando sobre lo que un juego de aventuras ofrece que los juegos gráficos pierden por completo, al menos en las aventuras gráficas... creo que es el "factor eureka". Ya sabes, el placer de resolver un puzzle o avanzar en la historia, o mejor aún: poder tornar el destino y cambiar la historia a nuestros propósitos. Creo que este factor sólo es posible gracias a la singular interface: el lenguaje natural. En los juegos gráficos en que las acciones están todas detalladas, así que el placer de resolver un puzzle no es tan completo como en un juego de aventuras. Así que creo que tu juego mostrará al mundo el potencial real de una interfaz de parser, que en su evolución, menospreciaron tan a la ligera.

Rubes: Realmente estoy en desacuerdo con eso, pero creo que estás cerca. Hay mucho de ese "factor eureka" en una aventura gráfica cuando resuelves ciertos tipos de puzzles, aunque la calidad de esa experiencia puede ser diferente que en una aventura conversacional. Creo que el "factor eureka" es uno de los principales atractivos del género de aventuras en general, gráfico o texto, porque la resolución de problemas forma parte integral del diseño del juego y su jugabilidad.

La entrada por texto es, desde luego, una de las características más únicas de este proyecto. Así que creo que la auténtica pregunta es entonces, ¿por qué? ¿Por qué usar un parser de texto? ¿Qué añade a la experiencia?

Como tú mismo sugieres, en las aventuras gráficas las acciones están a menudo simplificadas — por ejemplo, agrupadas juntas en una categoría más amplia, como "usar" o "interactuar" — típicamente menores en número. Algunos podrían argumentar que los objetos en las aventuras sólo tienen unas pocas acciones aplicadas a estos de todas formas — así que, ¿para qué preocuparse con un conjunto de verbos más amplio que frecuentemente no funcionan o sólo dan respuestas estándar de la librería?

Yo ya he mirado este asunto en cierto grado en mi blog: _(http://monksbrew.blogspot.com/2008/02/verb-analysis-in-if.html) _de una manera apresurada y altamente no científica, y parece que en realidad hay un bien montón de verbos usados en tres muy bien conocidos trabajos de IF, tal y como se especifica en sus soluciones paso a paso. Por supuesto, algunos juegos de IF usan más verbos que otros, y otros usan tan sólo unos pocos — por supuesto depende mucho de cada juego y de cada diseñador. Pero, encuentro interesante que sea muy común encontrar aventuras que usan 50, 60 o más verbos diferentes o acciones. Eso son un montón de opciones, así que no estoy seguro de como crear una interfaz eficiente para todos esos en un juego gráfico.

Además existe una diferencia entre un sistema encubierto, como un parser de texto, y un sistema interfaz completamente descubierto, tal y como se puede ver en la mayoría de las aventuras gráficas. Esto es, en un sistema completamente descubierto, el jugador sabe de antemano el conjunto completo de acciones del juego, puesto que las opciones (verbos) están presentadas de cierta manera en un menú visual. Creo que, al que tú te refieres en el comentario anterior es que, con un sistema como ese, a veces no tienes la misma sensación de descubrimiento que podrías experimentar en la ausencia de una lista completa de todas las opciones. Con un sistema encubierto — como un parser de texto, que (típicamente) no descubre una lista de todos los verbos posibles — puedes obtener una participación más profunda y comprometida en el mundo del juego, y además puedes usar ciertas acciones especiales para más ventaja. Hay algunas experiencias maravillosas en IF que simplemente no funcionarían si todas las opciones posibles se mostrasen claramente, y el parser está más capacitado para este tipo de situaciones creativas.

Esto tiene sus beneficios y perjuicios, por supuesto — el perjuicio más obvio es que los jugadores se pueden frustrar intentando encontrar o expresar la acción precisa que el juego requiere para una situación particular. Pero en muchos casos determinar (o expresar) cómo usar un objeto o realizar una acción determinada puede ser un puzzle en si mismo. Para que esto funcione bien los autores deben de hacer un trabajo cuidadoso, (1)diseñando puzzles inteligentes y justos, (2) dando al jugador una percepción intuitiva de lo que es posible y lo que no es posible, y (3) testando el juego para estar seguro de que da cuenta de todas las maneras alternativas de expresar la misma acción. Sin eso, el juego puede encontrarse como innecesariamente complicado o difícil, con muchos jugadores responsabilizando al parser mismo.

Urbatain: Sí, estoy de acuerdo, y creo que estamos de acuerdo desde el principio, pero mis carencias en Inglés me impiden expresarme con propiedad sobre esta idea. He pillado la idea: "sistemas encubiertos u opacos" vs "sistemas descubiertos o transparentes", no olvidaré estos conceptos, ¡gracias! Sí, por supuesto sí puedes tener el factor eureka en una gráfica, pero creo que el comportamiento de la mente humana tras una "resolución de puzzles" es más satisfactoria gracias a la interfaz encubierta de la que has hablado, simplemente, resolver un puzzle en una AC se siente más natural a la mente humana, porque tu mente piensa una solución, tu mente la expresa de una manera en la cual está más afinada por naturaleza: lenguaje natural, escribes la posible solución y el juego responde apropiadamente (o no).

Rubes: Creo que podrás encontrar a un montón de gente que no estén de acuerdo necesariamente con eso, e intuyo que es sólo cuestión de preferencia. Algunas personas encontrarían que un sistema simplificado de point-and-click es más fácil y más natural, particularmente dado que es la típica interfaz de un ordenador. Creo que una de las atracciones de parser de texto es que permite a los jugadores expresar de forma más natural la acción deseada — escribir COGER, DEJAR, EMPUJAR, o ABRIR es más explícito y expresivo que mover o clicar el ratón, así que para algunas personas (yo incluido) es una manera más confortable de hacer las cosas. Pero debo decir que la popularidad de los juegos de aventuras de point-and-click argumentan, al menos en cierto grado, que ese tipo de interfaz es preferida por mucha gente.

Urbatain: Pero las preferencias no tienen nada que ver con el comportamiento de la mente... tenlo en cuenta... Y acerca de las cosas negativas del parser: simplemente son problemas de diseño. El síndrome de la palabra exacta es un problema de los autores, no del sistema en sí. De hecho he leído tu análisis sobre verbos en IF, y como estás haciendo un duplicado del modelo de mundo de Inform, pensando sobre los atajos de ratón para jugadores perezosos... ¿qué tipo de aproximación has elegido para ello? ¿Es posible completar el juego sólo con ratón y los controles de Quake? ¿Los atajos de acciones con el ratón (pulsando el botón derecho sobre un objeto) mostrará una lista muy larga de verbos?, ¿o sólo los más comunes?

Rubes Deseo crear un juego que pueda ser jugado completamente con el teclado, pero no necesariamente con el ratón. Una de las características del parser que más me gustan es que hay una completa ocultación de la interfaz; lo que hemos hablado de que el jugador no conoce todos los comandos permitidos por el juego, y parte del puzzle es adivinarlos. Con los juegos basados en point and click de ratón, necesitas tener todo al descubierto, y eso elimina uno de los retos del género de los juegos de aventuras. Eso es especialmente cierto para algunos verbos "especiales" y cosas como la magia, donde el diseñador puede que no quiera que el jugador sepa ciertas palabras o verbos hasta que son descubiertos. Así que hay ciertas cosas que no quiero que el ratón haga.

Ahora mismo puedes hacer casi todo con el teclado. Lo único que no puedes hacer es rotar de izquierda a derecha (sólo está soportado de momento el caminar de lado: strafe), o mirar arriba y abajo. No puedes seleccionar objetos, tampoco, pero no hay necesidad de ello — puedes referirte a los objetos por su nombre. Realmente el juego puede terminarse usando sólo el teclado, pero probablemente no sería una experiencia ideal. Añadir la habilidad de girar y mirar hacia arriba o hacia abajo con el teclado no es difícil, pero no estoy seguro de cuántas personas estarán realmente cómodos haciéndolo de esa manera. Esto es algo que probablemente miraremos cuando lleguemos al testeo.

El ratón es más restrictivo. El cursor se usa para seleccionar objetos al clicar con el botón izquierdo, lo cual lo resalta. El botón derecho se usa para realizar una acción basada en el verbo en el cual el botón esté puesto. Ahora mismo la lista de verbos posibles está restringida a cuatro acciones muy comunes (tomar, mirar, examinar, e inventario), y seleccionas el que deseas girando la rueda del ratón (si tu ratón tiene una). Además puedes escoger el verbo asociado al botón derecho tecleando el comando SET RIGHT BUTTON TO (PON EL BOTÓN DERECHO A ). Para los verbos que requieren un objeto (TOMAR y EXAMINAR), el juego asumirá automáticamente que cualquier objeto seleccionado es el objetivo de la acción. Así que, por ejemplo, digamos que el botón derecho está puesto a examinar, y que el jugador clica sobre una mesa para seleccionarla. Clicando con el botón derecho generará el comando EXAMINAR MESA y lo mandará al parser, donde será interpretado y ejecutado.

Además, si cualquier botón es pulsado y se arrastra el ratón, hará que la cámara gire para poder mirar alrededor. Al pulsar los dos botones a la vez, hará que el jugador camine hacia adelante. Así que hay algo de funcionalidad en el ratón, pero aún así necesitarás el teclado para jugar. La mayoría de las veces tener una mano en el ratón y otra en el teclado funciona muy bien, sin mucha interrupción.

Por supuesto, la mayor parte de todo esto no está grabado en piedra, asi que podemos (y es muy probable) hacer cambios si hace falta una vez que comience el testeo.

Urbatain: Hablando de interfaces, las premisa sobre la que te he hablado tan sólo hace una pregunta, yo creo (y unos cuantos visionarios de la aventura) que la evolución natural de las ACs es o iba a ser el 3D y los juegos de realidad virtual, así que ahora creo que con los juegos en 3D podemos reunir el camino de los mundos modelados con la interactividad y la simulación, lo cual, en mi opinión, es la parte más importante tanto en la Ficción Interactiva y los Juegos de Aventuras. En cambio la evolución del mercado de los videojuegos ha ido por otros derroteros (entornos en alta definición pero con modelos de mundos muy pobres y peor interactividad. De nuevo, Vespers 3D, creo que puede suplir esta carencia. Y hablando de nuevo sobre el factor eureka tal y como lo has mencionado, tienes razón: creo que los juegos en 3D con controles que simulan un modelo de mundo y tienen simulación (aunque pequeña y simple), por ejemplo, Quake, también puedes tener el factor Eureka, por ejemplo: ves a un enemigo, tu mente calcula el movimiento, trayectoria y momento, lanzas un misil con cierta trayectoria implementada con las reglas del modelo de mundo y simulación y... ¡Eureka! ¡Frag! Otro ejemplo, en Clive Barker’s Undying hay un puzzle donde una chimenea sin encender está esperando a que le lancemos un hechizo de fuego sobre la madera, de manera diferente a las aventuras gráficas, tu no clicas sobre la chimenea y seleccionas "Quemar", sencillamente tu eliges invocar ese hechizo en favor de la experimentación. Puedo imaginar que la mejor evolución para la IF-3D sería un parser controlado por voz, usando un micrófono.

Rubes: Bien, estoy de acuerdo en que sería fascinante ver un juego controlado completamente por lenguaje natural entrado por un micrófono, pero creo que aún falta algo de tiempo para que lo podamos ver. Y sobre la evolución de los modelos de mundo en general, creo que nos estamos moviendo en una dirección donde sistemas más avanzados permitirán la experimentación creativa y la resolución de problemas, y será muy interesante ver hasta donde llegan los desarrolladores. Vespers, a pesar de todo esto, no está muy avanzado al respecto — su modelo de mundo es, simplemente, una representación directa del modelo de IF que Jason creó en Inform 6. Existen, quizás, más opciones para la interacción de las que podrías encontrar en cualquier juego típico de 3D en primera persona, pero está diseñado para trabajar de forma muy parecida al modelo de mundo en una AC en tanto como pueda.

Este es, realmente, una de las metas más importantes de este proyecto: crear un modelo de mundo en 3D que implemente el modelo de mundo de una AC lo más exacto posible, de manera que los jugadores y los diseñadores puedan ver cómo sería una AC directamente trasladada al 3D. Pero para mí eso tan sólo representa el primer paso; a partir de ahí, espero que la gente lo mire y comiencen a pensar en cómo podrían ellos explorar este medio, al tomar gran ventaja de las cosas que el 3D ofrece, para hacer un juego que sea algo más que una directa representación del modelo de mundo de una AC.

Urbatain: ¡Ey! Recuerda que el modelo de mundo de Vespers está basado en Platypus (Nota: librería hack de la librería estándar de Inform 6 para lograr una librería orientada a personajes, y no al jugador) ¿Has observado algunos juegos comerciales con modelos de mundos complejos a modo de investigación? Por ejemplo, tengo en mente la saga Thief, sobre todo las misiones de los fans, que se han especializado en la narrativa dentro de un entorno en 3D en primera persona.

Rubes: He jugado a un cierto número de juegos comerciales, aunque como soy un usuario de Mac, no tengo acceso a los juegos más populares de PC tanto como me gustaría. Uno de los juegos que más he disfrutado es Deus Ex, el cual creo hace un buen trabajo siguiendo una historia sencilla pero entretenida y proveyendo de unos visuales bonitos, así como atmósfera y entorno. Aún así, era más un shooter que una aventura, lo cual no es lo que yo quiero crear. No hace mucho me compré un portátil Mac Intel e instalé Windows XP usando Boot Camp, así que una de las cosas que estoy haciendo últimamente es mirar atrás y probar algunos de los juegos de aventuras más populares que me he perdido, para experimentarlos y estudiar sus modelos de mundos e interfaces. Por ejemplo, he estado jugando a Dreamfall recientemente y, aunque me ha gustado, encuentro su interfaz verdaderamente irritante.

Rubén: Para aumentar la comicidad vamos a cambiar nuestros nombres, mi nombre real es Rubén, y el tuyo es Rubin, así que cambiemos los nicks para confundir a los lectores... escucha, realmente, deberías mirar los juegos de acción comerciales, no las típicas tópicas aventuras gráficas, ¡olvídate de ellas! Están estancadas en el pasado. Déjame recomendarte algunos juegos con unos modelos de mundos más complejos por encima de la media en 3D: por supuesto Deus Ex, la saga Thief, si consigues una copia de Thief 2 puedes tener años y años de diversión de alta calidad narrativa con las toneladas de misiones de los fans, Thief Deadly Shadows, por supuesto, System Shock 2, Half Life 2, Portal, Bioshock (curiosamente todas mis preferencias son juegos de la misma gente una y otra vez, discípulos de la misma filosofía sobre los juegos heredada del desaparecido estudio Looking Glass; No se me ocurre ningún juego indie que encaje en este tipo de aproximación. Y de las aventuras gráficas... están estancadas, bueno, quizás salvo Real Myst tenga algo de peso, porque marca la diferencia tan sólo con el poderse mover libremente en 3D, y quizás Zork Grand Inquisitor, con un sistema de magia casi apropiadamente hecho para ser un juego comercial.

Rubin: Efectivamente algunas están estancadas en el pasado, pero existen algunos juegos que han surgido realmente muy interesantes o que se espera que vayan a surgir con visión de futuro. La serie Penumbra me viene a la mente. Estos están enfocados profundamente en narrativa e inmersión, y usan gráficos 3D avanzados y físicas. Además te permiten interactuar con los objetos del mundo a través de movimientos naturales tales como tirar de palancas, o abrir cajones con el cursor, aunque no estoy completamente seguro de qué este tipo de interacción sea necesariamente mejor. No obstante, admiro sus ideas y aproximación.

Rubén: Otra cosa muy importante sobre IF vs juegos comerciales es que el texto nos permite presentar modelos de mundos perfectos (aunque puedo imaginar algunos problemas y puzzles donde un juego en 3D funcionaría mejor al modelarlos). Por ejemplo, en IF tenemos contenedores y soportes, y... así es, muy sencillo, una cosa puede estar dentro de otra. Pero, en un juego gráfico estos deben de usar sublistas de subobjetos mostrados en una ventana pop-up. Uno podría esperar que los mundos en 3D arreglasen esto, sin embargo estos siguen usando las sublistas de objetos como solución, porque son fáciles de implementar. Un mundo en 3D perfecto nos permitiría mirar (realmente) dentro de un contenedor. Lo cual no es nada fácil de implementar, mira por ejemplo en Thief Deadly Shadows, estos usan contenedores reales en 3D, y funcionan muy mal. Otra razón para usar las soluciones antiguas en el inventario es que... sencillamente es imposible mostrarlo en 3D reales porque el modelo de mundo tiende a ser irracional en favor de la jugabilidad. He visto algunos pantallazos de Vespers 3D donde tú te apoyas en este tipo estándar de soluciones para los contenedores. ¿Podrías comentarnos esto? Y tengo curiosidad por los soportes, porque, estos están a simple vista, así que estos podría evitar el usar esas aproximaciones tradicionales...

Rubin: Bien, debo decir que el texto no nos permite necesariamente representar modelos de mundos perfectos, particularmente con respecto a contenedores y soportes; dependiendo de la implementación, por ejemplo, podrías contenedores que aguantan muchos más objetos de los que deberían (ya que el espacio y el peso son pasados por alto o son demasiado difíciles de implementar). Pero sí, este tipo de cosas son mucho más fácil de implementar en texto qué en 3D. Los soportes, como las mesas, son algo más fáciles en 3D hoy en día, particularmente si tienes un buen motor de físicas a tu disposición. Pero en general, suelen ser conceptos difíciles de modelar en un sentido práctico.

Vespers tiene la gran ventaja de que sólo contiene un puñado de objetos que el jugador pueda coger, pero aún así la cosa puede ponerse complicada. Ahora mismo sólo puedo recordar unos cuantos de los contenedores de Vespers de memoria — la caja de limosnas en el pasillo de entrada, y el armario de la cocina, aunque probablemente me olvide de algunos. En vez de tratar de modelar estos contenedores de una forma realísta, he elegido modelarlos de una manera más práctica. En la versión de texto de Vespers, por ejemplo, sólo hay un objeto que es permitido meterlo dentro de la caja de limosnas es la moneda — el código no permite al jugador meter dentro otra cosa que no sea la moneda. Así que yo he hecho lo mismo. La moneda se esconde muy bien dentro de la caja cuando la tapadera está cerrada, pero ningún otro objeto se puede meter dentro.

El armario es algo más complicado, creo. En el texto del juego, el armario es descrito como que tiene una sóla puerta, y el interior no está descrito en absoluto. Así que hemos decidido modelar el armario en 3D basándonos en unos diseños que hemos encontrado, pero el diseño incluye 4 puertas. Así que ahora tenemos cuatro sitios diferentes donde el jugador puede (y debería) poner objetos. He conseguido implementar esto, pero la forma más sencilla de hacerlo es crear un "sostén" para un objeto detrás de cada una de las cuatro puertas del armario. El problema es que sólo puedes poner un sólo objeto en cada sostén. Desde el punto de vista del juego esto no es un problema: el jugador raramente tiene más de unos pocos objetos a la vez, y de todas formas no hay necesidad de colocarlos allí. Pero desde la perspectiva de la mimesis, puede ser irritante si colocas una pequeña moneda en un armario y te dicen que ya no hay más sitio para más objetos en ese espacio.

Seguramente hay soluciones más elegantes a este problema, pero el trabajo que requieren no merecen el esfuerzo en Vespers.

Como el Torque Game Engine no tiene implementado un motor de físicas muy bueno, he decidido implementar los soportes de una manera similar: simplemente he creado una serie de puntos en lo alto del soporte donde los objetos se colocarán al ponerlos encima. Así que por ejemplo, la cama en la habitación del Abad tiene 5 localizaciones diferentes para colocar objetos, y si el jugador quiere poner un objeto sobre la cama (por cualquier motivo), encontrará una localización vacía y lo pondrá ahí. Una vez que las 5 localizaciones está ocupadas, no hay más sitio para más objetos sobre ese soporte. De nuevo, está bien para nuestros propósitos porque, en Vespers, el jugador nunca tendrá más de 5 objetos que pueda soltar (si es que lo recuerdo correctamente). Si hubiese más objetos, encontraríamos algunos problemas de mimesis, pero de igual forma que con los contenedores, una solución más elegante no merece el esfuerzo que requiere.

Rubén: De nuevo mi carencia en inglés. Sí, pero me has entendido, hablaba del tema de que "en la literatura, la imaginación crea mundos mucho más perfectos en nuestra imaginación que cualquier juego de alta definición en 3D pudiera hacer". En las ACs, realmente, tu tienes una cosa dentro de otra, y es así, un modelo muy simple (una cerilla dentro de una caja de cerillas). Me refiero a que, el modelo de mundo puede ser el mundo de un juego, con sus irrealidades y cosas de ese tipo (Guybrush sacándose de su inventario una escalera muy larga), y hoy en día se puede controlar fácilmente el peso y el volumen en una AC con ciertas librerías... es más en los 80 y los 90, el PAW para spectrum permitía tener volumen y peso. Pero, volviendo al tema, en definitiva, ¿Vespers 3D mostrará las cosas dentro de los contenedores a simple vista? ¿En la vista 3D real? ¿Sin usar ventanas pop-up con listas de los subobjetos del inventario actual?

Rubin: Bueno, no hay muchas instancias de esto en Vespers, en su mayor parte porque en el juego no hay muchos objetos de inventario y contenedores. Pero para los que tenemos, sí, los objetos serán representados visualmente dentro de otros objetos. La moneda, por ejemplo, aparece dentro de la caja de limosnas cuando la abres, y cuando la caja está cerrada, no puedes verla. Lo mismo para la comida que hay dentro del armario.

Por supuesto, el texto también refleja esto, tal y como lo haría una AC. Así que si el jugador escribe MIRA DENTRO DE LA CAJA DE LIMOSNAS, la respuesta será "Dentro de la caja de limosnas hay una moneda."

Rubén: Bien, ¡bien! Ok, entonces sólo el inventario recurre a sublistas, por razones obvias. Bajemos un poco el tono de la entrevista, sólo por un momento. ¿Esperas (la compañía) hacer dinero con Vespers 3D, o será gratuito?

Rubin: En realidad esa es una pregunta difícil de responder. Originariamente planee hacer el juego gratis, pero también pensaba gastar mucho menos al hacer el juego. Es realmente difícil hacer un juego en 3D con los personajes y animaciones con un presupuesto diminuto. El plan era usar este juego como lanzadera para un juego de IF-3D posterior, de una longitud mayor, pero para hacer eso probablemente tenga que recuperar al menos algo del coste de este juego. El problema en cargar dinero por un juego como este es que es muy corto en comparación a los demás juegos comerciales, así que no podría cargar mucho por él. Así que, si finalmente termino por cargarlo, será probablemente por una pequeña cantidad — probablemente una cantidad cercana al precio de una entrada de cine.

Rubén: ¿Además la presentarás a varios concursos? ¿Cómo el IGF?

Rubin: Ciertamente me gustaría, esa es la meta — IGF, IndieCade, y todos esos. Pero aún queda mucho camino antes de que podamos llegar a ese punto.

Rubén: Bueno, para ser sincero, siempre prefiero los juegos indies gratuitos, es un rollo ver que la mayoría de los ganadores del IGD son de pago, comerciales a través de Xbox live, o sharewares con demos de descarga, como mal menor. Y luego puedes bajarte gratuitamente algunos de los mejores juegos indies de la historia, como Knytt Stories, o la saga 6 days sacrifice, los juegos de IF, los fantásticos juegos gratuitos online en flash (aunque estos últimos si tienen un sistema donde los desarrolladores están obteniendo dinero por ellos), así que, algunas veces no puedo entender como algunos tipos de juegos pretenden cobrar por ello... ¡Ja! quizás cuando yo esté dentro de la escena indie cambie de opinión. Y pronto veremos a TextFyre con juegos de IF de alta calidad, de los cuales, estoy seguro, estaré encantado de pagar por ellos... ¡Así que me siento dividido! Bueno quizás podrías usar un término medio como Radiohead, que vendió su disco In Rainbows online, y los compradores podían elegir el precio a pagar, desde 0 libras (gratis) hasta 99... ;)

Rubin: Ciertamente miraremos diferentes opciones, pero también puedo entender porque algunos de estos diseñadores quieran cargar un cierto precio por sus juegos. Es algo raro para un diseñador de juegos indie terminar un proyecto sin pérdidas, mucho menos obtener un beneficio significativo. Y es duro seguir haciendo juegos por poco o por ningún precio — especialmente juegos en 3D, los cuales pueden encarecerse muy rápido. Yo ya he gastado una cantidad considerable en Vespers, y es poco probable que pueda volver a realizar otro de estos juegos tanto sin obtener algo de lo que he gastado o consiguiendo que una aportación externa esté interesada en darle soporte. Pero si haces esto último, entonces no tienes más remedio que cargar por tu juego. Así que es un tema bastante complicado.

Urbatain: Subamos de tono la entrevista de nuevo :) Hablemos un poco sobre la auto-censura, porque Vespers, sin destripar el guión, tiene una buena carga de violencia, y sexo casi explícito. En un juego de texto, el sexo, puede ser escrito implícitamente con buena literatura y elipsis, sin necesidad de escribir todos los detalles sucios. Pero, simplemente, no puedo imaginar como te las has apañado para adaptar estas escenas, o si has decidido "cortarlas". Gracias a Dios, los desarrolladores indies no tienen que tratar con códigos morales, censura oficial y leyes (eso espero... eso creo...) Corrígeme si me equivoco.

Rubin: Además es algo especialmente desafiante en un juego en 3D que tiene una perspectiva en 3D. Cualquier cosa que requiera una directa, interacción física coordinada entre el jugador y un PNJ, tales como el sexo o la violencia (o incluso una simple conversación), va a ser difícil en un FPS en 3D y requerirá algunas soluciones creativas. No hemos decidido cortar ninguna de esas partes del juego, pero tampoco hemos trabajado en soluciones finales para estas. Tenemos algunas opciones, y las probaremos para ver como funcionan. No va a ser fácil, creo. Y en cuanto al material sexual, basta decir que no será gráficamente representado de ninguna de las maneras.

Rubén: Pero no es sexo y sangre lo que me interesa de todo esto, hemos hablado antes de que algunas escenas son difíciles de implementar. Hablemos de los problemas técnicos de una adaptación... La versión original tiene un buen puñados de esas escenas de "contacto" (quizás esto tenga que ver con el sexo... o no), sobre esas escenas difíciles... ¿Cómo has manejado estas escenas de "contacto? Tengo en mente, por ejemplo, la escena final, y sí, la escena del sótano, que es similar a la "escena del pozo" de Anchorhead, la cual, sencillamente, No soy capaz de imaginar cómo hacer eso en 3D... Bueno, en la escena final siempre puedes mostrar un gráfico muy bonito, o un vídeo, así que aquí tienes la solución estándar básica; pero en el sótano o en una posible escena en el pozo de Anchorhead, sencillamente, son interactivas, así que son la mar de difíciles de implementar.

Rubin: Correcto, absolutamente. Volvemos a mi punto anterior, donde la interacción física coordinada en un juego en primera persona en 3D es muy difícil de resolver. Hay algunos trucos que podemos hacer para restringir donde debería de estar el jugador, o cuanto es permitido moverse al jugador o actuar, pero algunas veces incluso esos métodos no funcionan. El gran problema es que no podemos predecir donde estará el jugador físicamente localizado cuando intenta realizar una tarea en particular, o cuando una acción necesita ser realizada en el juego, lo cual es información que deben tener los PNJ para que sus animaciones aparezcan apropiadamente. Una solución es diseñar el sistema de forma que el jugador puede ser manipulado para moverlo a uno o más localizaciones predecibles, en las cuales lanzamos animaciones que tendrán un mayor sentido. Es difícil habla de ejemplos específicos en Vespers sin destripar el juego, pero espero que esto te de una idea de lo que estamos pensando para el juego.

Rubén: ¡Para nada! :) Pero tienes razón... habrá que esperar a la versión pública final para ver la resolución a esta pregunta.... :) A pesar de ello, esto me trae a la mente un tema muy importante, este es, la narrativa en 3D. Los juegos comerciales, sencillamente, no saben a donde van con el medio, algunas veces copian las aproximaciones del cine, una mala idea porque estos son, nosotros somos, interactivos. Siendo más conciso: Hablo sobre el tema de cambiar la perspectiva de la cámara desde primera persona a tercera persona. Tu sabes... en los juegos Quake, cuando mueres, la cámara salta fuera del cuerpo (¡Guau! pensándolo mejor, ¡eso está realmente bien como filosofía de narración!); en la serie Half Life, la cámara está SIEMPRE dentro de Gordon Freeman. ¿Podrías comentarnos algo sobre esto? Quizás para esas escenas difíciles podrías cambiar la cámara a tercera persona. ¿Qué tipo de filosofía has decidido para la narración en Vespers 3D?

Rubin: Nunca he sido un fan de cambiar la perspectiva de la cámara en mitad de un juego, al menos en los que juegas un rol en particular (en juegos del estilo Quake es un problema menor). Prefiero la vista en primera persona a la tercera, porque me permite como jugador estar más inmerso en el personaje que estoy jugando, y prefiero mantener esa perspectiva de cámara por completo.

Hay algunas situaciones donde el control de la cámara será quitado del jugador para mostrar unas escenas breves, pero no planeamos mostrar el personaje principal (al Abad) en estos casos. Lo hemos hablado, el grupo entero, algunas veces, pero creo que mi filosofía es dar a los jugadores un rol, y dejar que estos se imaginen a si mismos en ese rol, en vez de mostrarles explícitamente el personaje.

Rubén: Hemos hablado antes sobre el control de la interface y lo difícil que es dejar que el avatar se mueva automáticamente por medio de algoritmos de búsqueda de caminos (path-finding). Pero, creo que me encantaría ver la interfaz del juego completamente controlada por el parser. Por ejemplo, en Facade el jugador debe de usar las flechas para mover el PJ, pero para hablar con los PNJs hay que escribir. En tu juego también habrá un cambio de interfaz, pero, sinceramente creo que en los juegos en los que el jugador debe de saltar desde el ratón a las flechas, de las flechas al teclado, puede distraer del juego en si. Por eso me gustaría un control del juego sólo por texto, "camina hacia la puerta", "ve cerca de la mesa", gira 45 grados, etc. Sí, estoy puede ser un poco complicado con los algoritmos pathfinding y todo eso... pero yo creo que merece el esfuerzo. ¿Podrías comentarnos un poco todo esto? Sobre el diseño del control... ¿Qué elementos debiste abandonar para mantener la interfaz sencilla, y cual es el diseño final de la interface?

Rubin: Bien, como he mencionado, los jugadores pueden usar el teclado casi exclusivamente. Pero no puedes escribir GO TO , aunque puedes moverte fácilmente con los controles del tipo WASD. El problema real de permitir comandos GO TO es que nunca puedes predecir dónde está el jugador cuando el comando es entrado, así que en cualquier momento puede haber objeto, un muro, una puerta, o un PNJ directamente en medio del camino del jugador. Así que te quedas con dos opciones: simplemente teleportar al jugador a una nueva localización (lo cual creo que es muy irritante, además, ¿qué pasa si ya hay un objeto en el punto de destino?), o desarrollar un sofisticado conjunto de código de algoritmos de búsqueda, lo cual puede ser complicado y consumir demasiado tiempo. Estoy de acuerdo de que cambiar constantemente entre el teclado y el ratón puede ser algo que distrae y algo molesto, pero sería igual (sino más) de cansado el tener que teclear comandos tan específicos como GIRA A LA IZQUIERDA 45 GRADOS cuando lo mismo se consigue pulsando una sola tecla o moviendo ligeramente el ratón.

En cuanto al diseño de la interface, he hablado sobre los elementos de la interfaz más arriba, pero hay unas cuantas cosas que aún no he mencionado. Una es el hacer comandos muy comunes tan simples como pulsar una sola tecla, así que INVENTARIO se puede conseguir pulsando I, LOOK pulsando L, EXAMINE, pulsando X, OPEN pulsando O, y AGAIN pulsando G. He intentado mantener simples la mayoría de los comandos; por ejemplo, examinar objetos se convierte en un proceso tan sólo de clicar sobre un objeto y pulsar X, abrir se convierte en tan sólo clicar sobre un objeto y pulsar O, etc.

También he intentado incorporar algo de customización, por ejemplo, utilizando la tecla TAB: como si fuera el botón derecho del ratón, puede ser puesta a un verbo elegido, que se ejecuta cuando la tecla TAB es pulsada. El verbo por defecto es INVENTORY, pero también puede ponerse a LOOK, EXAMINE, o TAKE, y se inicializa escribiendo el comando SET TAB KEY TO .

La habilidad de customizar (como la tecla TAB o el ratón derecho) me dio la idea de que podíamos permitir una customización aún mayor si quisiésemos. ¿Por qué restringir las posibilidades de los verbos tan sólo a cuatro acciones muy comunes? ¿Podríamos permitir que los jugadores entrasen SET TAB KEY y permitir cualquier verbo válido? ¿Y además podríamos permitir que los jugadores asignen verbos específicos a ciertas teclas también? ¿Como si alguien quiere tener la tecla T para TAKE, mientras que otro quiere tenerla para ejecutar TALK TO? ¿Por qué no permitir que puedan especificar esto?

Siguiendo con este tema ¿no podríamos permitir a los jugadores que asignen frases enteras a teclas específicas? En la manera en que la interfaz del juego está construida, cualquier comando es enviado — ya sea desde la linea de comandos, o por una pulsación de tecla, o con el botón derecho del ratón — funciona generando el comando apropiado en forma de texto, y enviándolo a través del parser. Así que si la tecla TAB está puesta a INVENTORY, presionar la tecla TAB realmente genera una cadena de texto que contiene "INVENTORY" y lo manda al parser. Así que, en teoría, es perfectamente posible asignar una frase completa a una tecla específica. Podríamos, por ejemplo, permitir a los jugadores escribir SET F1 to SET TAB KEY TO TAKE, y el resultado sería que cuando la tecla F1 es pulsada, la frase "SET TAB KEY TO TAKE" sería enviada al parser, y la tecla TAB se inicializaría a TAKE. Todo tipo de posibilidades se hacen posibles.

Pero la verdadera cuestión es, ¿los jugadores quieren ese nivel de customización? Siento que la interfaz es ya de por sí bastante complicada, y creo que añadir más y más posibilidades podría abrumar a mucha gente. La simplicidad es algo en que creo debería ser buscada, y aún no estoy seguro de qué pensar de todo esto.

Rubén: Una cosa que creo es realmente importante en piezas interactivas modeladas en mundos 3D es ese "contacto" que hemos hablado entre el avatar y el objeto con el cual va a interactuar (no sólo los PNJs de los que hemos hablado), por ejemplo en casi todos los juegos en primera persona desde más allá de hace 2 años, nunca hemos sido capaces de ver nuestro propio cuerpo, solamente un brazo flotante en mitad del aire; aún así algunos de estos brazos son muy satisfactorios, pulsando botones, tirando de palancas, rompiendo cabezas, etc. Como lado negativo, tengo en mente un juego: Thief Deadly Shadows, donde somos capaces de ver todo nuestro cuerpo, pero cuando decidimos coger un objeto, simplemente este desaparece del suelo y es mágicamente teletransportado al inventario; menuda decepción, tenemos a un ladrón perfectamente modelado pero necesita de la telekinesis para mover los objetos de un lado para otro. En otros juegos como Blade (un juego comercial Español con "percepción del cuerpo (body awareness)" el avatar mueve muy correctamente el brazo para coger un trozo de pan y llevárselo a la boca; o en Dark Messiah donde patear los culos de los enemigos, empalarlos, cortar cuerdas para trampas improvisadas, etc, y en general toda la "percepción del cuerpo" está realizada a la perfección y es realmente satisfactorio. Así que, la pregunta es, ¿habrá animaciones del brazo, o de todo el cuerpo del avatar para cada una de las acciones de Inform?

Rubin: Hemos pensado en hacer algo así, pero probablemente no para este juego. Creo que si tuviera dos o tres programadores trabajando para mí, probablemente podríamos hacerlo, pero es algo muy complicado de hacer para que parezca convincente. Así que por ahora, aún tendremos jugadores que trabajan telekineticamente. ;) Realmente es una cuestión de recursos y mano de obra vs los beneficios adicionales que esto proporciona.

Rubén: Y casi más importante que lo de antes, el feedback negativo del juego... ¿habrá algún tipo de modelado en 3D y animaciones para un "No puedes hacer eso"?

Rubin: En general, la respuesta es no. En esta etapa del desarrollo estamos concentrándonos más en la traducción desde la AC, así que la mayoría de las respuestas como esa aún estarán probablemente en forma de texto. Si tiene sentido añadirlo gráficamente y añade al juego algún tipo de feedback visual negativo, entonces deberíamos de hacerlo para algunas cosas.

Rubén: Y "feedback de audio"? Esto es, hablar y grabación de voz para las acciones del Abad, y para ese "feedback negativo", esto es, acciones fallidas siendo descritas en texto y audio...

Rubin: Ahora mismo tenemos algunas voces grabadas para el Abad. Va un poco en contra de mi aproximación a no revelar aspetos del personaje jugador al jugador (tales como la apariencia y sonido, lo cual, algunas veces, puede romper la inmersión), pero creo que es necesario en algunos lugares. Por ejemplo hay algunas conversaciones entre el jugador y otros hermanos que dependen de un intercambio de una parte a otra, así que realmente necesitamos de una voz del Abad. Creo que, en general, funciona muy bien.

Ahora mismo no tenemos grabaciones de audio específicas para acciones fallidas, sólo una respuesta textual. Estoy experimentando con distintos tipos de feedback de audio, lo cual creo es importante, pero quiero usar algo que rompa la inmersión lo mínimo posible.

Rubén: Entonces debo recomendártelo para el juego. Estamos jugando un rol, así que: ¡está bien tener voz para el Abad! Y... ¿qué grado de profundidad tienes implementado del modelo de mundo de Inform? Por ejemplo, ¿has modelado el sistema de reacciones sobre acciones, antes, después, reaccionar_antes, reaccionar_despuès, o quizás has tenido que simplificar esto? Si es así, ¿tienes planes de extender esta característica en el futuro?

Rubin: El Torque Game Engine tiene su propio lenguaje de script, y yo simplemente lo he adaptado para mis propósitos, incluyendo un tipo de estructura que es (vagamente) similar a la manera en que Inform 6 trabaja. Así que, por ejemplo, cuando defino un objeto en el juego (como la caja de donativos o la moneda) les doy atributos y propiedades similares a la manera en que Inform lo hace. Así que la caja de donativos tiene un campo nombre que incluye "almsbos" y "box", y un campo adjetivo que incluye "alms", y el parser usa éste para determinar si el jugador está o no está refiriéndose a este objeto. Además tiene un campo para el pronombre ("it"), plural (false), contenedor (true), abierto (false, inicialmente), y abrible (true), al igual que campos para padre, hijos, y objetos hermanos,

Y en cuanto a acciones y reacciones, he tratado esto de una forma un poco diferente, más bien porque el juego es en tiempo real, y es difícil implementar cosas como antes y después de alguna manera que no sea un juego puramente basado en turnos. Por ejemplo, hay unos cuantos casos de "reaccionar_antes" en Vespers (la versión de texto) que responden a un comando de movimiento, lo cual sería difícil de hacer en 3D porque el movimiento usualmente se hace pulsando una tecla. Así que algunas de estas instancias está codificadas directamente de diferentes formas, pero está bien porque mi meta no es necesariamente diseñar un sistema completamente independiente del juego tal y como es Inform.

Rubén: Pero finalmente, ¿obtienes un lenguaje o script similar a TADS3 o Inform para programar todo el juego? Si es así ¿podrías pegarnos un código de ejemplo?

Rubin: Como he dicho, sólo he adaptado el lenguaje de script del Torque Game Engine para hacer lo que necesito. Algo de lo que he diseñado es similar a Inform, y algunas cosas son diferentes. Por ejemplo, cada verbo tiene su propio código de ejecución. Primero, realiza una serie de comprobaciones para estar seguro de que la acción puede ejecutarse (por ejemplo si el jugador está lo suficientemente cerca del objeto, si está mirando hacia el objeto, etc). Entonces, chequea el objeto en sí para buscar algún código específico de esa acción, y entonces la ejecuta. Un ejemplo de esto sería la acción INSERTAR. Si un jugador escribe INSERTA LA MONEDA EN LA CAJA DE LIMOSNAS, el motor iría al código de INSERTAR y haría primero una serie de comprobaciones para estar seguro de que la moneda está en posesión del jugador, que la caja de limosnas es un contenedor válido, que el jugador está lo suficientemente cerca de la caja de limosnas, etc. Luego llama al código específico de la caja de limosnas para ver si hay algún caso especial; en este caso, la acción de INSERTAR sólo se permite para la moneda, y ningún otro objeto más. Así que si el jugador intenta poner otro objeto en la caja de almas, aquí es donde el comando retornaría un mensaje de error y cancelaría la acción. Por como en este ejemplo el objeto es la moneda, se le permite continuar. Se vuelve al código de la acción INSERTAR, y entonces realiza la acción de poner el objeto en el contenedor visualmente, y coloca apropiadamente los valores de padre/hijo/hermano, y aporta el mensaje de éxito apropiado de la librería.

Rubén: Siento curiosidad, ¿qué tipo de rol tiene Jason Devlin en el desarrollo? De verdad, siento curiosidad. Quizás el tiene buenas técnicas de programación o scripting, o quizás no tiene tiempo para tanto y sólo está como consejero y testeo, etc, o quizás se va a quedar en Orange River por mucho tiempo y unos cuantos proyectos. Siento curiosidad por cuántos buenos autores de IF sois capaces, tanto TextFyre como Orange River de robar a la comunidad... :)

Rubin: Para este proyecto, Jason está más como consejero y testeo. Hay muchísimos asuntos, como puedes imaginar cuando pasamos del texto al 3D — no sólo en la traducción de Vespers, sino en la manera en que un mundo de 3D/IF funciona, y Jason a tenido un rol importante imaginando todo esto. Ocasionalmente nos hemos topado con partes del mundo en 3D que o no estaba incluidas o no estaban descritas en el juego de texto, y Jason nos ayuda en el qué poner ahí o cómo describirlo. Me gustaría que nos diseñase otro juego tras terminar con Vespers, y sería interesante ver lo que él puede diseñar específicamente para un mundo de 3D/IF, no sólo para un mundo de IF. Pero debido a nuestro largo tiempo de desarrollo, yo no me preocuparía de eso de robar muchos autores. ;)

Rubén ¿Podrías darnos una fecha de publicación para la versión 1.0 de Vespers 3D? :)

Rubin: Me encantaría, pero honestamente no tengo ni idea. Desde luego no en poco tiempo, aunque quizás tengamos una versión demo (parte del Día Uno del juego) para este año, si tengo suerte.

Rubén: ¿Tiene "Orange River" algo en mente para cuando Vespers 3D esté terminado? ¿Quizás llevar los límites del sistema más allá de una forma más radical? ¿Algo desarrollado desde guión sólo por tí? ¿O de nuevo portar algúna afortunada obra de IF de la comunidad? O quizás es demasiado pronto para hablar de esto...

Rubin: De momento no tenemos planes específicos, pero sería interesante hacer ambos — portar un juego de IF de éxito (asumiendo que cualquier autor esté interesado) y crear un juego nuevo que quizás pueda tomar ventaja del modelo de mundo en 3D/IF y llevar sus límites más allá, como tu dices. Las películas son un medio muy diferente a los libros, y cada cual tiene su propio conjunto de técnicas y estilos en los que trabajar sólo para ese medio; de forma similar, 3D/IF es muy distinto a IF, y para tener un éxito verdadero en este nuevo medio, necesitamos descubrir nuevas técnicas con las que trabajar, en vez de confiar demasiado en IF pura por si misma.

Aún hay mucho camino antes de que empecemos a mirar nuevos proyectos, pero ciertamente estoy interesado en seguir ambos caminos, y en escuchar que alguien está interesado en ver si juego de IF creado en 3D/IF.

Urbatain: Pues eso es todo Rubes, muchísimas gracias por tu tiempo y por este proyecto tan inspirador.

Rubes: Gracias, aprecio la oportunidad de hablar sobre el proyecto, y estoy encantado de que estés interesado en aprender más sobre él. Espero que se convierta en un juego que a la gente le divierta experimentar.

El Clérigo Urbatain.


Enlaces útiles:
http://monksbrew.blogspot.com/
http://www.greatgamesexperiment.com/game/vespers3d/
http://www.rampantgames.com/articles/IFInterview.html
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9453

1 Mensaje


Seguir la vida del sitio  RSS 2.0: Artículos, Comentarios | Mapa del sitio | SPIP
CC Some rights reserved El contenido está disponible bajo los términos de Atribuir - Compartir bajo la misma licencia 3.0 ó 2.5 de Creative Commons.