CAAD

Hemos estado hablando en el canal de textualiza sobre si hay que reconsiderar la validez de la apariencia 'normalizada' de las obras de FI. La frase que quería traer aquí para movilizar y expandir la discución es esta de Pescatillas:



¿Qué opináis vosotros?

Pues por eliminación puede que esa sea la vía, o no, quizá no hay vía

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com

Yo creo que una apariencia personalizada sí que añade mucho atractivo a una aventura, y más si se quiere atraer a nuevos jugadores.

Pero no veo qué relación tiene eso con el uso de intérpretes. La mayoría de los intérpretes modernos tienen bastante flexibilidad respecto a interfaz y gráficos y permiten diseñar una experiencia personalizada. ¿O igual es que sólo estoy entendiendo el comentario parcialmente?

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

La conversación no iba sobre la 'personalización' en el sentido de 'decoración', es decir, no se referían a poner determinados gráficos o fuentes, sino de replantear completamente el modo de interacción con cada obra.

Mi comentario sobre los intérpretes no es una crítica a su tecnología o posibilidades. Todos tenemos claro que son la tecnología idónea para desarrollar aventuras de parser, puesto que llevan años perfeccionandose para eso.
El problema es que todo lo que rodea a estos intérpretes no ha evolucionado apenas, y a día de hoy comparado con cualquier videojuego indie palidece en muchos apartados, y esa es la competencia real.
Para nosotros la idea de una máquina virtual, donde ejecutas un fichero donde has programado una aventura con un lenguaje especial, con gramáticas para parsers y demás es algo que nos seduce per se, porque nos gusta todo lo que rodea al mundillo. Por eso al final aquí nos juntamos sólo los desarrolladores. Pero a un tipo que se baja un juego de Steam todas estas cosas le dan igual, quiere jugar a algo "bueno" y en Steam tiene un catálogo lleno de propuestas de lo más variopinto.
En ese catálogo de Steam (y digo esta tienda por ser la más famosa pero vale para cualquiera) es donde tenemos que competir para llegar al gran público. En Steam nadie espera instalarse un intérprete y abrir un fichero tipo Z como si fuera un Word de la vida para empezar a jugar. Mi novia se dedica al desarrollo de software y le gustan los videojuegos, pero si le hablo de eso hasta ella piensa que es algo demasiado nerd. De la interfaz genérica del intérprete ni hablemos, ella está acostumbrada a trabajar con líneas de comandos pero si ve eso y le dices que es un juego le resulta absurdo, no le atrae lo más mínimo.
Al final, nos parezca fríbolo o no la estética prima sobre el contenido en todos los ámbitos. Una aventura no puede ser algo genérico sobre un intérprete genérico. Debe ser una aplicación única, con una interfaz atrayente y original (y esto va mucho más allá de cambiar un CSS para poner colores y tipos de letra), con una interacción que lo haga divertido, y puede ser parser, CYOA, una mezcla... lo importante es que sea el más adecuado para esa aventura.
Lo que haya detrás de esto técnicamente da igual. Puedes hacer una aventura en Inform 7, meterla en su intérprete, colgarlo online y ponerle una capa de Web Service encima. Luego haces una web con un interfaz 3D acojonante con WebGL para gafas de realidad virtual que tire las órdenes contra ese Web Service. Todo esto da igual, y es perfectamente válido. Simplemente digo que hagas lo que hagas tiene que parecer un producto único y especial, con todos sus apartados bien cohesionados.
Para el CAAD, donde la gran mayoría de usuarios somos programadores de aventuras es perfecto seguir trabajando con intérpretes y hacer Jams y Comps con estas herramientas que nos permiten obtener el fondo que buscamos. Pero esos resultados para mi siempre van a ser prototipos. Para llegar al mercado de jugadores de fuera hay que llevar ese prototipo a algo mucho más profesionalizado.

Hay un hilo eterno en este foro donde se cuestiona si las aventuras de parser están muertas. Yo digo, si JK Rowling escribiera una aventura de parser basada en el universo de Harry Potter, le pusieran una estética como de libro viejo, con ilustraciones hechas a mano en plan cuento, y esto se anunciara por TV en la campaña de navidad, ¿alguien cree que esto no vendería? Mi novia se tiraría a comprarlo como una loca y me diría que le parece mágico poder meter frases abiertas y que el juego responda.
Nosotros no somos JK Rowling ni tenemos una franquicia como Harry Potter entre manos (ni probablemente dinero para hacer una campaña en TV ni juntando los ahorros de todos los que estamos en el foro), pero el resto sí está en nuestras manos. No tenemos el tiempo ni la capacidad artística para hacerlo, pero quizá podemos colaborar con gente que sí lo tenga y nos pueda ayudar.

Me ha quedado una parrafada enorme, pero quería aclarar mi idea por aquí, ya que esto lo solté por el textualiza de forma bastante escueta.

El tema requiere clarificación.

Si la pregunta es si a MÍ me gusta más la interfaz normalizada, te diría que sí. Soy perfectamente capaz de distinguir Zork de Aisle aún siendo absolutamente idéntica la interfaz, los colores, el tipo de letra y el intérprete. Soy capaz de darme cuenta de que son obras absolutamente diferentes como lo soy de afirmar eso mismo entre Macbeth y Esperando a Godot, pese a tener ambas letras negras sobre fondo blanco y un olor a papel que a veces (dicen) es adictivo.

Por otra parte tener mi tipo de letra favorito, con mis colores favoritos, para poder leer todas esas obras, para mí es una ventaja.

Si la pregunta es si se llega a más gente modificando todos esos aspectos, probablemente sea así. Creo que empresas como InkleStudios o Failbetter se plantean eso seriamente y lo hacen. Textos más pequeños, mucha animación, poca o ninguna entrada de texto tipo parser... y pese a eso consiguen elaborar experiencias basadas principalmente en el texto.

Está claro que la FI de parser es muy minoritaria, pero es lo que hay.

Yo no critico la FI de parser. Critico la FI ejecutada desde un intérprete.
No me importa si la entrada es de parser escrito y sale texto, o si es un libro con dos preguntas al final para elegir un camino. Eso da igual y depende de cada juego.
Para mi el problema del intérprete es de accesibilidad. El mismo juego de parser hecho con una interfaz única bien conjuntada con el juego y aportando un extra a la experiencia, en una web propia (o en una app de Android por ejemplo) donde se acceda desde una URL simple con dominio propio del juego (ej: zork.com) donde abras y comiences a jugar me parece un avanze abismal frente a un fichero Z que te descargas y juegas en el intérprete de turno.

Como bien comentas a ti te gusta abrir el juego en tu intéprete y jugarlo con la letra que a ti te va bien para leer. A mi también. Por eso ambos estamos en este foro hablando de esto. Pero lamentablemente creo que nuestros gustos son una rareza, y al público que potencialmente puede consumir FI no le atrae esto.
Por supuesto que no niego que el intérprete sea práctico. Como herramienta para prototipado y para compartir aventuras con la comunidad es ideal. Pero para plantar un juego en Steam donde entre gente que no tiene ni idea de lo que es la FI y empiece a jugar el intérprete y todo lo que conlleva me parece absolutamente contraproducente.
A grandes rasgos, para hacer un juego atractivo y vendible en una tienda popular actual (Steam, Google Play...) necesitas un Detective Land. Algo así siempre será más exitoso y atraerá más público a pesar de que seguramente en máquina Z hay aventuras mucho mejores. Detective Land la jugarán miles de personas, los ficheros Z quedarán en bases de datos como la del CAAD donde las jugaremos nosotros.

Sí, básicamente estamos de acuerdo. Pero todo eso se puede conseguir con intérpretes, poniéndole una capa por encima para que el usuario no se entere de que se trata de un intérprete. Que ejecute un exe, o una app, y ya esté.

El problema es ponerle el cascabel al gato.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)

Concuerdo en que, sin perjuicio de que como habituado a las AC me parece mucho más cómodo usar un intérprete que ejecutar una aplicación específica de una obra, el hecho de explicar a un usuario nuevo que tiene que descargarse un intérprete sobre el que abrir el archivo de la obra lo echa para atrás, máxime si no está habituado a emplear emuladores. Ya hace tiempo se intentan implementar soluciones para encubrir, como sugiere pescatillas, el intérprete de modo que el usuario no se entere de su subyacencia a nivel técnico: instaladores para cada plataforma que copian en una carpeta tanto la obra como el intérprete y crean en ubicaciones relevantes accesos directos para que el intérprete ejecute directamente la obra sin pasar por diálogos intermedios, ejecutables o archivos por lotes que extraído todo en una carpeta llaman al intérprete pasando como argumento la ruta a la obra y, lo más actual, las aventuras jugables en línea con intérpretes que se ejecutan —sin requerir ninguna descarga— directamente en navegadores web.
Ahora bien, me parece que la solución a la falta de público no pasa principalmente por el problema de los intérpretes. Y es que a pesar de que no podemos desconocer que aún hay muchas obras que no funcionan bien con intérpretes en línea y que según en qué navegadores aquéllos tienen limitaciones a la hora de cargar/guardar partidas o gestión de multimedia, en los últimos años se avanzó muchísimo en disponibilizar obras para jugar mediante el navegador (baste ver que las fichas del portal dan enlaces para jugar en línea cuando los hay, que la página principal de éste muestra destacadamente obras con esta capacidad y los tutoriales que en su día elaborara Incanus para colgar obras en Facebook), sin que por ello la afluencia de jugadores nuevo haya aumentado más allá de los primeros días en que algunos de nosotros compartimos algún que otro enlace en nuestros perfiles de redes sociales —o, quienes los frecuentan proactivamente, blogs de literatura.
La solución creo que tenemos que buscarla en los debates que cada tanto se arman sobre cómo «mercadotecnificar» —por decirlo de alguna manera— la ficción interactiva para que sea atractiva pero en relación con los canales de distribución, es decir, no específicamente en relación con si se trata de aplicaciones nativas para cada plataforma o en realidad subyacen intérpretes.

Dejando a un lado por un momento la captación de público nuevo, me parece oportuno señalar por qué prefiero intérpretes con interfaz normalizada. Es lícito que éstos permitan que cada autor especifique la configuración predeterminada de su obra, pero también lo es que un usuario tenga preferencias y configure el intérprete para que no tenga en cuenta las que fijó el autor. A veces, más que una preferencia, llega a ser necesidad. Por ejemplo, desde un punto de vista de accesibilidad, como usuario ciego hay ciertos intérpretes que me dan la tranquilidad de que cualquier juego que ejecute en tales intérpretes me leerán, pues así lo configuré, el texto con la voz SAPI 5 que me gusta para jugar aventuras; hay asimismo usuarios a los que, aun sin ninguna discapacidad, les resulta cómodo jugar todo con determinado tipo y tamaño de fuente.

Fernando, estoy escribiendo una mini aventura en C y SDL. ¿Qué debo tener en cuenta para poderse usar con un lector de pantalla?.

_________________
---
KMBR! http://www.aliensuavito.com @lecambre

Hay librerías en los So (p. ej. UIA y MSAA en Windows) para enviar información a herramientas de accesibilidad y una específica de código abierto —no sé de quién— que acomoda la salida según el lector de pantalla activo, y para NVDA NV Access tiene disponible una API para comunicarse directamente con el lector NVDA desde una aplicación.
De todas maneras, puedes evitar ahondar en estas cosas si procuras que la salida y el campo de entrada de órdenes sean controles diferentes entre los que puede tabularse y navegarse, especialmente por la salida, con comandos de navegación de texto estándar, esencialmente las flechas. Al tabular al cuadro de la salida luego de dar una orden puedes elegir entre situar el cursor al principio del resultado de la última orden, dejarlo donde estaba antes tal como hace AGE cuando se activa el modo lector de pantalla o, la que considero peor idea, desplazarlo al final tal como hacía AGE irremisiblemente cuando no existía el modo mencionado y aún hace por defecto. La última opción es una mala idea porque, al no saber el jugador a priori de cuántas líneas consta la salida de la última orden, no puede mecanizar la cantidad de veces que debe pulsar la flecha hacia arriba y ello le quita velocidad.
En relación al búfer de texto, además, algunos jugadores agradecerán que brindaras un comando u opción para borrar la pantalla, sobre todo si juegan con el eco de pantalla de JAWS en Todo, puesto que no es muy fino para manejar la desaparición natural de texto por scroll. Esta configuración de eco de pantalla distinta de la predeterminada está más bien prevista para algún valor cuyo cambio es preciso supervisar pero no se anuncia automáticamente por no estar resaltado, no ser barra de progreso, alerta…, pero como muchos usuarios no entienden esta circunstancia conviene dar apoyo a este modo también. Luego será gusto tuyo si pones o no un diálogo que permita revisar salida que ya se ha borrado pero, si lo pones, asegúrate de que se pueda cerrar con ESCAPE o, al menos, tenga un botón Cerrar activable con BARRA ESPACIADORA una vez se tabule al mismo.

Supongo que para acciones como guardar/cargar y otros metacomandos, además de permitir escribirlas, pondrás una barra de herramientas para acceder rápidamente a las más importantes con el mouse. Si es el caso, sobre todo si no programaste que se puedan escribir, añádeles teclas rápidas (p. ej. CTRL+G/CTRL+S para guardar), da la posibilidad de mover el foco a la barra de herramientas con F6 y recorrerla con flechas izquierda y derecha, o pon menús estándar a los que puede accederse con la tecla ALT. Desde un punto de vista de accesibilidad siempre se aconseja que los elementos de barras de herramientas estén también en menús usables con el teclado sin necesidad de técnicas de simulación del mouse ni navegación por la jerarquía de objetos que ofrecen los lectores de pantalla, pero hay que ver cómo encaja una barra de menús tradicional en la estética de una aventura, sobre todo si ésta no tiene para pasar entre ventana y pantalla completa… Y hablando de la pantalla completa, si incluyes la posibilidad de cambiar a este diseño no olvides ponerle de tecla rápida de alternancia F11 o ALT+ENTER, que son las dos que según el caso suelen verse en la mayoría de programas y hasta juegos.

¿Tendrá la aventura mapas en pantalla, palabras clave en las descripciones, panel de inventario a un costado y/o barra de estado con puntuación u otras estadísticas? Como en esto cada aventura es un mundo, para efectuar recomendaciones conviene saber qué tendrá y dónde.