SPAC
Portada > Webzine > Sección objetiva > A. técnicos > Tres herramientas que deberíamos tener y no tenemos

Tres herramientas que deberíamos tener y no tenemos

Miércoles 19 de diciembre de 2007

Si queremos que más gente de fuera del mundillo se anime a crear y jugar aventuras, es esencial disponer de buenas herramientas que les faciliten la tarea y se ajusten a sus requisitos. ¿Cuáles son las aplicaciones que más podrían ayudar a popularizar las aventuras de texto, manteniéndonos dentro de lo factible a corto-medio plazo?

Un año más, el mundo de la aventura en español sigue en pie. El ritmo anual de producción de aventuras se mantiene y se han celebrado tres comps. Tenemos nuevas herramientas de creación de aventuras, como I7 y Kenshira. Además, el CAAD está más presente que nunca en internet, con la creación de la WikiCAAD y el florecimiento de los blogs; y SPAC termina el año renovándose y con energías frescas.

Creo, por lo tanto, que el balance de este año se puede considerar enormemente positivo, más que el de los años anteriores... pero, a pesar de todo, no basta. Porque lo cierto es que, si bien se han hecho muchísimas cosas, seguimos siendo más o menos los mismos de siempre. Los novatos llegan con cuentagotas, y muchos de ellos no encuentran suficiente aliciente en nuestra comunidad como para quedarse y contribuir. Si uno cuenta cuántos somos, casi parece un milagro que podamos mantener wikis, blogs, comps, foros, canales, premios y fanzines, y hasta producir alguna que otra aventura. Lo cierto es que mantenemos todo eso porque contamos con algunas personas que valen su peso en oro, y que parecen poder atender a múltiples cosas a la vez cual hidras de múltiples cabezas. Y esa situación, aunque esté bien a corto plazo, resulta un tanto inquietante si uno piensa en el futuro. ¿Qué pasaría si dos o tres personas de las más activas abandonaran la comunidad? ¿Podríamos seguir sacándolo todo adelante, o habría que empezar a echar el cierre a alguno de nuestros medios de comunicación y difusión, y aceptar el comienzo de una decadencia tal vez irreversible?

Yo personalmente creo que esa decadencia no está próxima, y al CAAD todavía le queda cuerda para rato. Sin embargo, eso no quiere decir que debamos confiarnos y descuidarlo; porque mientras nuestra comunidad siga siendo pequeña, el riesgo de que se diluya siempre estará ahí. Así pues, debería ser un objetivo prioritario para el CAAD el captar más gente, hacer que la comunidad crezca y se haga más fuerte. Y en este objetivo, por desgracia, la evolución de estos dos últimos años no es para tirar cohetes. Ganamos la suficiente gente para ir sobreviviendo, cubrir ausencias y mantener el ritmo, pero poca más.

Habrá quien piense que esta dificultad para que el CAAD crezca se debe a la poca adecuación de las aventuras de texto a los gustos del ciudadano del siglo XXI. Ante esto no puedo sino discrepar: si bien es obvio que las aventuras nunca podrán ser un fenómeno de masas o "mainstream"; en un mundo donde hay miles de personas que leen libros, que juegan a refritos de arcades de los 80 en las pantallas de sus móviles, o que compran cosas como "Hotel Dusk", no veo por qué la aventura de texto no iba a tener su nicho.

Yo siempre he opinado que el verdadero motivo por el que el CAAD no crece lo que debería es más bien la infraestructura, es decir, las herramientas de que disponemos. Hace un par de semanas entraba el enésimo usuario desencantado en el foro, preguntando si había alguna herramienta nueva y sencilla para la creación de aventuras, y afirmando incluso que en caso contrario se pondría a programar directamente en java o javascript. Leyendo declaraciones como ésa, es difícil no pensar que tenemos un problema de falta de herramientas y que estamos perdiendo potenciales usuarios por ello. Otro dato apuntando a lo mismo aparecía hace meses en los newsgroups de la aventura inglesa. Se anunciaba la muerte de la comunidad aventurera alemana, y como presunta causa se apuntaba a la aparición de Inform 7 en el panorama inglés. Reconstrucción forense de los hechos: los creadores alemanes habían probado y preferido la nueva herramienta y, al no estar disponible en su lengua, habían pasado a crear aventuras en inglés.

Y es que, en algo tan complejo como la creación de aventuras, el disponer de una herramienta adecuada a las necesidades de cada tipo de usuario es fundamental, y el elenco disponible en español es, por el momento, francamente limitado. Hasta hace un año, la elección estaba entre Superglús e InformATE. El primero se basa en un modelo de programación de bajo nivel traído directamente de los años 70-80, que puede estar bien para quien esté familiarizado con los sistemas de esas épocas; pero difícilmente puede satisfacer a un programador del siglo XXI. El segundo se basa en programación orientada a objetos, un modelo más moderno y más adecuado a las aventuras; pero a estas alturas de la década de los ceros ya empieza a adquirir también un tinte añejo. En un mundo en el que en las empresas se programan aplicaciones basándose en frameworks, uniendo componentes entre sí, aprovechando arquitecturas preconcebidas con patrones de diseño que dan lo más difícil hecho, haciendo en suma mucha configuración (en XML y apoyándose en herramientas específicas) y poca programación; ya empieza a parecer anacrónico el necesitar escribir cientos o miles de líneas de código para hacer algo tan uniforme y estandarizable como una aventura de complejidad normal. En la comunidad inglesa se han dado cuenta y han aparecido con una solución bajo el brazo: Inform 7, con un nuevo paradigma basado en reglas y haciendo énfasis en el uso de un IDE. Es una solución que puede gustar o no, que tiene sus ventajas y sus inconvenientes; pero es una solución del siglo XXI, y a mucha gente de la comunidad inglesa le parece magnífica. ¿A cuánta gente de la comunidad hispana le parece magnífica la herramienta que usa, y cuánta la considera simplemente la menos mala de entre las que hay?

Creo que, si consiguiésemos poner a funcionar una serie de herramientas modernas y dinámicas -no sólo para la creación de aventuras, sino también para otros aspectos, como su descarga y ejecución- lograríamos ilusionar a muchos de los novatos que hoy no se entusiasman, y hacer que la comunidad creciese. Claro que, obviamente, las herramientas no se crean solas, y ése es el problema: probablemente seamos tan pocos porque no tenemos herramientas atractivas; pero también es cierto que no tenemos herramientas atractivas porque somos pocos para crearlas. Pero, abstrayéndome de este "pequeño" detalle, voy a proponer una lista de las tres principales herramientas que no tenemos y que deberíamos tener. Creo que todas ellas podrían contribuir a ilusionar a los novatos y hacernos crecer, y que además son cosas alcanzables, que se podrían crear incluso con los escasos recursos de que disponemos. Aquí van:

3. Inform 7 totalmente en español : La versión 7 de Inform supone un cambio de paradigma con respecto a las anteriores, y proporciona una posible solución al problema de los que quieren crear aventuras pero son alérgicos a los lenguajes de programación. Gracias a los esfuerzos de un grupo de CAADeros, Inform 7 ya se puede utilizar para crear aventuras en español. Sin embargo, y por desgracia, el lenguaje natural que se usa para escribirlas es, por el momento, una mezcla de palabras españolas e inglesas... con lo cual de "natural" tiene poco, perdiéndose una de las principales ventajas del Inform 7 original. Si se consiguiera que el IDE de Inform 7 aceptara entradas totalmente en español, tendríamos una herramienta capaz de atraer a mucha gente que hoy no se anima a crear aventuras.

2. Herramienta gráfica de creación de aventuras : Basta hojear los foros, listas y fanzines de los últimos años para comprobar que ésta es una de las grandes demandas sin oferta de la comunidad. A mucha gente le gustaría disponer de una herramienta donde se pudiese dibujar un esquema de un mapa, con sus distintos objetos, y generar una aventura a partir de él. Visual Sintac lo hacía; pero cayó en los abismos del olvido. El AGE vendrá con una herramienta así, pero mejor aún sería tener una capaz de trabajar con cualquier lenguaje, sin estar ligada a un sistema de creación determinado. Algo así también serviría para atraer a más gente al mundillo.

1. Programa organizador (front-end) para la descarga y ejecución de aventuras : Es algo que se ha propuesto en el foro, incluso más de una vez; pero nunca ha pasado de ahí, y creo que se le debería prestar más atención. En mi opinión, si se hiciera realmente bien sería tal vez la herramienta que más capacidad de atraer gente tendría. En esta internet gargantuesca en la que siempre tenemos un millón de alternativas de ocio esperándonos en cada esquina, pretender que un usuario se descargue un zip, lo descomprima, se lea un documento, baje otro programa (intérprete) y lea también su correspondiente documento para jugar una aventura es simplemente pretender demasiado. En la comunidad inglesa parece que se han dado cuenta y han sacado IFDB, donde se puede jugar a gran cantidad de aventuras con un click. Sin embargo, un programa que sacara una lista de aventuras y permitiese ver información, jugarlas y bajarlas sería todavía mejor; y técnicamente parece menos difícil de crear que el resto de herramientas deseadas de esta lista.

Creo que sería un gran avance para la comunidad que en el año 2008 viésemos bien implementada alguna de estas herramientas (y si es más de una, mejor). Que así sea.

20 Comentarios

  • Tres herramientas que deberíamos tener y no tenemos

    25 de diciembre de 2007 13:40, por Akbarr

    O sea, que esto es... ¡tu carta a los Reyes Magos!

    Menos mal que AGE, que como todos sabemos está al caer, va a resolver los tres deseos de un tirón... ;-)

    • Tres herramientas que deberíamos tener y no tenemos 27 de diciembre de 2007 04:53, por Grendelkhan

      Creo que hace falta un programa que se pueda descargar la gente y con el que se pueda jugar a todo lo que vaya saliendo en el CAAD, es decir, que se auto-actualizara cada vez que se ejecuta.

      Por ejemplo, dicho programa podría tener un motor que buscara directamente en las descargas del CAAD para ver si hay algo nuevo, y que una vez lo encuentre lo descargue al programa para poder jugar directamente. Así la gente no tiene que entrar periódicamente al CAAD para ver lo que hay, ni se enfrenta a un zip con un z5 dentro que no sabe lo que es.

      También creo que se debería hacer visualmente atractivo, porque la sociedad actual juzga por la estética. Ignoro si hacer ésto es difícil, pero sería un gran avance para el CAAD, porque multitud de gente podría descargarse éste programa en webs de software tipo Softonic y disponer así de toda una colección de juegos en unos pocos minutos.

      • Tres herramientas que deberíamos tener y no tenemos 28 de diciembre de 2007 04:43, por Al-Khwarizmi

        Sí, en eso que dices es en lo que estaba pensando. La idea es que el programa pueda bajarse aventuras directamente de un servidor, además de ejecutarlas directamente. Esto no excluye lo que dice Sarganar en un comentario sobre el CD aventurero, que se podría hacer simplemente distribuyendo una versión donde las aventuras viniesen "pre-bajadas".

        Yo personalmente no ataría el programa a la sección de descargas del CAAD, ni a WikiCAAD ni a ninguna web así; sino que más bien haría que se bajara una lista de aventuras (con sus metadatos) en XML de una URL configurable. Así, si por algún motivo la wiki o la web del CAAD cambian de formato, el programa seguiría funcionando mientras la lista siguiera ahí. Y esto no es incompatible con que se puedan hacer scripts que rellenen automáticamente la lista a partir de las descargas o la wiki, claro.

      • > Así la gente no tiene que entrar periódicamente al CAAD para ver > lo que hay

        eso me parece un error, el CAAD es mucho mas que la seccion de ficheros

  • Tres herramientas que deberíamos tener y no tenemos

    25 de diciembre de 2007 20:08, por Mel Hython

    En realidad creo que no sería tan difícil tener una buena herramienta que deje contento a mucha gente.

    ¿Qué alternativas hay y cuáles tenemos realmente? Yo creo que a lo largo de los años se han perfilado básicamente tres perfiles de ’deseos’ sobre las herramientas de desarrollos de aventuras:

    - Herramientas de tipo ’Orientación a Objetos’: hay y ha habido muchas de esta clase, en nuestro entorno podemos estar hablando actualmente de InformATE o de INFSP (Inform 6). Esta aproximación me parece sobre todo orientada a programadores. Puede ser usado por literatos pero solo mediante un IDE avanzado que ayude mucho lo que nos lleva a...

    - Herramientas de tipo ’graficos + wizard’: lo que intentó crear Javi hace mucho tiempo con su VS. Supongo que tendríamos que hablar actualmente de ADRIFT. El problema de estas aproximaciones es que al final el escritor está bastante limitado ya que es muy difícil crear una herramienta realmente flexible usando sólo gráficos y wizards.

    - Herramientas de tipo ’orientación a reglas’: hemos tenido en el foro cosas que eran ’pura orientación a reglas’, pero era demasiado complejas de usar, sin embargo algo con un modelo de mundo razonable (y basado en objetos o prototipos) y basado en reglas creo que es realmente lo más sencillo de usar. Esto es Inform 7 pero también, y aquí va la sorpresa, PAWS (Superglus, etc...). ¡Vaya y eso! Pues porque aunque está claro que PAWS en realidad tiene mucho de código máquina, su ’uso’ principal acaba siendo una lista ordenada de reglas del tipo: si el jugador ha tecleado esto, entonces... Lo que en la práctica lo acerca bastante al uso principal que acaba teniendo Inform 7.

    Tal vez la solución ’final’ pase por coger lo mejor de cada aproximación:

    - Un modelo de base orientado a objetos, con la capacidad por parte del programador avanzado de trabajar a este nivel (para crear nuevos gramáticas de reglas -en el lenguaje Inform 7, serían nuevas ’frases’-).

    - Un sistema principal de creación basado en reglas.

    - Un IDE de soporte avanzado que permite crear de forma gráfica o con wizards las reglas más habituales (patrones de reglas).

    Sinceramente opino que el I7 no queda tan lejos de este plan, aunque la opción de usar ’lenguaje natural’ (en inglés) en el código resulta más problemático que ventajoso y necesita aún mejor IDE.

  • Tres herramientas que deberíamos tener y no tenemos

    26 de diciembre de 2007 13:26, por Sarganar

    3. Inform 7 totalmente en español : personalmente he estado haciendo pruebas con un engendro concebido a partir de bison/flex que pre-procesa lo que escribas en Source en español, lo traduce al inglés de I7 y continua con la cadena de compilación. Es una simpática chapuza, pero creo que no podrá avanzarse más hasta que se libere el fuente de I7 y el mismo I7 salga del beta.

    2. Herramienta gráfica de creación de aventuras : Quizás hacer algo con ADRIFT para que hable español sea una buena opción. Claro que es de pago, pero un precio no tan alto.

    1. Programa organizador (front-end) para la descarga y ejecución de aventuras: Y disponer de un CDAventurero con dicho front-end para bajar de una vez. 700Mbs de aventuras son varios años.

    Respecto al IDE de I7, me gustaría que existiera más inteligencia aun. Con un ayudante de sintaxis sensible al contexto que sugiera nombres de reglas y objetos a medida que escribo y me muestre en el instante la ayuda asociada a medida que me fijo en él. Tambien me gustaría inteligencia en la división de paneles, para que el IDE ’detecte’ en qué panel estoy concentrado (izquierdo o derecho) y varíe los anchos de manera automatica. El tiempo de desarrollo bajaria bastante.

    • Tres herramientas que deberíamos tener y no tenemos 28 de diciembre de 2007 04:34, por Al-Khwarizmi

      Lo que decís Mel y tú de Adrift puede ser interesante, pero me parece insuficiente.

      Yo no he usado Adrift; pero tengo entendido por lo que se ha comentado a menudo en el foro que es muy limitado. Eso puede servir para atraer a algún novato a hacer aventuras sencillas; pero cuando quiera dar el salto a algo más complejo que no se pueda hacer con Adrift, la única opción será renunciar a él y empezar con otro sistema desde cero... con lo cual me parece a mí que Adrift en español, aunque pueda ser interesante, no cumpliría los requisitos de esta lista que he hecho.

      El representar las cosas gráficamente desde luego tiene sus limitaciones; pero un sistema gráfico no tiene por qué estar limitado porque puede darte después la opción de programar comportamientos. Lo ideal es que un novato pueda empezar programando aventuras sencillitas (como las de Adrift) de manera totalmente gráfica; pero que si luego quiere profundizar más, pueda clickear en un objeto y asociarle un programilla/script (o bien unas reglas, si el sistema es basado en reglas).

      Como he comentado, el IDE del AGE hace más o menos esto (falta aún el soporte para programar puzzles gráficamente, con lo cual las aventuras hechas sin programar no pueden tener puzzles, pero esto se podría meter). Pero aun así sigue sin parecerme que sea lo mejor para cumplir el requisito. Al fin y al cabo, va a estar asociado al AGE, pero ¿por qué tener que usar un determinado sistema si queremos crear aventuras gráficamente, si total, la estructura de una aventura es igual en todos los sistemas?

      Lo ideal sería un sistema con una arquitectura parecida a la del txtmap, pero en versión gráfica. Es decir, tú creas un grafo de habitaciones y objetos (cosa que tiene más expresividad que una descripción de txtmap), le pones a cada cosa su descripción, nombre y otros datos comunes; y luego puede haber unos plugins para Inform, Superglús, AGE, etc. que generen el código correspondiente. Por supuesto, realmente la arquitectura sería más compleja que la de txtmap porque lo ideal sería que las características específicas de cada lenguaje tuviesen soporte gráfico directo en el IDE en la medida de lo posible (por ejemplo, si en AGE los caminos entre habitaciones tienen descripción y en inform no, el IDE debería dejar poner ese dato en los caminos cuando trabaje con AGE). Pero bueno, es algo que se puede hacer incrementalmente, no tendrían por qué estar todas las extensiones en el primer release.

      Yo reitero por enésima vez que el código del PUCK, el IDE del AGE, es libre bajo licencia BSD por si alguien se anima a usarlo para hacer esto. Yo no lo voy a hacer porque ya veis que ya me cuesta bastante sacar una versión final y usable del propio AGE y no es cosa de que disperse esfuerzos dedicándolos a otros sistemas; pero creo que si alguien quiere emprender un proyecto de este tipo debería al menos echar un vistazo a ese código antes, por si le convence.

      P.D: Lo de que el Adrift sea de pago tampoco lo hace una gran opción para atraer novatos, precisamente. No me imagino a alguien que entre aquí por casualidad, vea que le gusta esto y que sería interesante crear una aventura, y que ya de entrada esté dispuesto a rascarse el bolsillo. Aparte de que no sé si encontraríais muchos desarrolladores para contribuir gratis a un proyecto de pago...

  • Tres herramientas que deberíamos tener y no tenemos

    26 de diciembre de 2007 18:48, por planseldon

    Ya lo he dicho muchas veces, pero bueno: VISUAL INFORM YA!

    Me refiero a un entorno visual mínimo que permita hacer aventuras supersencillas: localidades, objetos, eventos (si tento objeto y hago acción entonces...)

    Se trata de que todo el mundo pueda hacer sus aventurillas, aunque sean totalmente limitadas. Mejor poder hacer aventuras limitadas a no poder hacer aventuras en absoluto (y recordad que no todos tenemos el tiempo, las ganas o el talento de aprender a programar :D

    • Tres herramientas que deberíamos tener y no tenemos 26 de diciembre de 2007 18:50, por planseldon
      Ah, y se me olvidaba: lo bueno de un VISUAL INFORM sería que con la herramienta superbásica se crearía un código z5 (o como se llame) que luego, si algún programador se pica y aprende a programar, podría mejorar introduciéndo código a pelo. Los torpes nos quedaríamos tan contentos con nuestras aventuras sencillas, y os aseguro que más de uno se sorprendería de lo que se puede llegar a hacer con una estructura totalmente simple :D
    • Tres herramientas que deberíamos tener y no tenemos 31 de diciembre de 2007 11:58, por baltasarq

      Hola !

      Todo lo que estáis comentando se podría hacer con un IDE basado en txtMap ... he pensado varias veces cómo se podría hacer, y lo ideal sería tener, efectivamente, algún mapeador gráfico para las localidades y los objetos.

      En cualquier caso, hace falta tiempo para poder hacer eso ... pero tb. es cierto que el código de txtMap es libre y cualquiera puede cogerlo para hacer lo que quiero.

      • Tres herramientas que deberíamos tener y no tenemos 2 de enero de 2008 09:29, por presi

        Lo ideal efectivamente sería hacer un IDE que tuviera como salida el formato TXM de modo que fuera txtMap en última instancia el que generara el código final para las herramientas soportadas.

        Yo creo que el problema no es de índole técnica. El verdadero problema es que los que tienen los conocimientos y la habilidad para llevar a cabo este proyecto son muy pocos en el CAAD, aun dentro de los que somos programadores los que se manejan bien diseñando interfaces gráficas son muy escasos (a mi mismo no se me da muy bien). Por si esto fuera poco está el factor motivación: los que pueden hacerlo realmente no lo necesitan, luego no están motivados, y los que lo necesitarían, aunque estén motivados no tienen los conocimientos para llevarlo a cabo.

        La verdad es que no tiene fácil solución este problema, quizá una vía fuera ampliar horizontes y buscar desarrolladores fuera del CAAD propiamente dicho, recordemos que un IDE de estas características no tendría que ser necesariamente específico para hispanohablantes.

        • La verdad es que yo no veo muy clara la conveniencia de usar txtMap como capa intermedia. Entiendo que txtMap está pensado para trabajar con el tipo de cosas que se pueden representar con texto secuencial. Esta representación en principio es más pobre que un diagrama, y la conversión grafo -> txtMap podría tener pérdida.

          Por ejemplo, no sé hasta qué punto txtMap permite cosas como objetos que están en más de una localidad a la vez (alias puertas), distinción entre caminos unidireccionales y bidireccionales, soporte de contenedores y sus contenidos y cosas así. Dado que la idea de txtMap es trabajar con una especie de "transcript" o "log" de una aventura, y los logs que incluyesen ejemplos de todo esto serían un poco complejos, imagino que no las permite. Estas cosas sí que son sencillas de representar en un grafo, pero si se añadieran estas (y muchas otras) cosas a txtMap seguramente acabaría con una complejidad que no es para lo que está pensado.

          En cualquier caso, el problema grande es lo que ha puntualizado presi.

          • Tres herramientas que deberíamos tener y no tenemos 2 de enero de 2008 12:49, por Al-Khwarizmi
            Ese fui yo, Al-Khwarizmi, que me olvidé de poner el nick. Pardiez.
          • Tres herramientas que deberíamos tener y no tenemos 2 de enero de 2008 13:28, por presi

            Bueno, es que yo estaba hablando del formato TXM de txtMap que es un XML específicio y que txtMap lo acepta tanto de entrada como de salida.

            Si no me equivoco, TXM soporta todo o casi todo lo que comentas, de todas maneras baltasar lo podrá confirmar o desmentir.

            • Tres herramientas que deberíamos tener y no tenemos 2 de enero de 2008 13:34, por Al-Khwarizmi

              Pues sí, nunca me había fijado hasta ahora en el .txm ese (había oído hablar de los ficheros txm pero daba por hecho que eran los transcripts o pseudo-logs de txtmap). En tal caso sí que está bien txtMap como base del IDE, al fin y al cabo si no soporta algunas cosas siempre se podrán añadir a ese formato sin necesidad de complicar el sistema txtMap en sí.

              A ver si hago la opción exportar a txm en el PUCK. :)

              • Tres herramientas que deberíamos tener y no tenemos 10 de enero de 2008 11:48, por baltasarq

                A ver ...

                «Por ejemplo, no sé hasta qué punto txtMap permite cosas como objetos que están en más de una localidad a la vez (alias puertas),»

                Nopes, no hay soporte para eso. Normalmente, yo las puertas las añado después.

                «distinción entre caminos unidireccionales y bidireccionales,»

                Sipis. Una conexión "normal" es bidireccional, mientras que una conexión especificada, como "norte hacia bodega" es unidireccional.

                «soporte de contenedores y sus contenidos y cosas así.»

                No, pero soporta objetos que son llevados por el jugador o no, estáticos o no ...

                «A ver si hago la opción exportar a txm en el PUCK. :)»

                Eso ... molaría mucho. Yokiyoki estaba haciendo algo parecido a PUCK, pero específicamente ligado a txtMAP, llamado Yaifm. Desgraciadamente, parece que está ausente desde ya hace tiempo.

                Web : txtMap — documentación

  • hotel dusk

    10 de enero de 2008 08:27, por urbatain

    ¡Alto ahí! ¿Cómo que leen libros y compran cosas como hotel dusk? Ese juegazo es un buen síntoma de las posibilidades de la ficción interactiva en un dispositivo comercial y portátil, todo un ejemplo a seguir y a mejorar.

    El modelo de mundo es muy limitado eso sí, arrastra problemas de diseño que interfieren en la interactividad, bugs, callejones sin salida por bugs, etc, pero es un pedazo de ficción interactiva, es una historia muy buena con un guión y desarrollo excelentes.

    Creo que deberíamos aprender de esta, hacer historias tan buenas basadas en lo humano, no atajar a lo fácil que es añadir monstruos y fantasmas y mejorar esa interfaz tan coja... claro... los juegos comerciales no tienen modelos de mundos tan buenos como los nuestros, no tienen la experiencia nuestra en interactividad.

    Sería increible trasladar Beyond de Mondi Confinanti a la nintendo DS y ver cómo compite con Hotel Dusk. La historia no le gana, pero la experiencia y el modelo de mundo... ¡je! Estos japoneses...

    • hotel dusk 10 de enero de 2008 15:29, por Mel Hython

      Como casi siempre ultimamente discrepamos abiertamente. Hotel Dusk es un buen juego, pero es una experiencia literaria, y por lo tanto un relato interactivo, francamente malo. Se ve venir, los ritmos son espantoso con escenas que se cruzan, o más bien se acumulan sin sentido de mínima credibilidad, pasan cosas (incluso nada más empezar, como la señora que llega al hotel), que te dejan diciendo ’pero menuda trampa argumental más vanal que me acaban de hacer, ¡manda narices!’.

      Como juego con sus misterios y puzzles está bien, es entretenido, pero la historia, si la llevases al cine, por ejemplo, me parecería muy mala y como novela aún más.

      De todas formas recuerda que a mí hay películas muy del gusto del público y crítica que me parecen incongruentes e insostenibles, como por ejemplo Matrix (la primera), así que tal vez tengo un gusto o una exigencia muy particulares en cuanto a los requisitos de congruencia y credibilidad.

    • hotel dusk 12 de enero de 2008 04:30, por Al-Khwarizmi

      Mi frase ’leen libros, juegan a refritos de arcades de los 80 en las pantallas de sus móviles, o compran cosas como "Hotel Dusk"’ no estaba pensada como una crítica. Yo mismo leo libros y juego al arkanoid en el móvil. Respecto a "Hotel Dusk", lo he probado pero no lo suficiente como para tener una opinión sólida sobre si me gusta o no, así que no voy a entrar a discutirlo.

      Lo que pretendía decir es que a la gente no le importa leer, y que tampoco le importa jugar a juegos que no incluyan las últimas tecnologías. Que la gente ya compra hoy en día muchos productos que tienen bastantes puntos en común con las aventuras, como es el caso de "Hotel Dusk", así que no deberíamos encerrarnos en la actitud de "la gente normal nunca jugará aventuras porque son más raras que un perro verde y no se parecen a lo que la gente busca".

      No eres el primero que ve en mi frase un tono despectivo hacia "Hotel Dusk", aunque no era mi intención que lo hubiese. Pido disculpas si mis limitaciones como escritor han causado este malentendido.


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.