SPAC Número #10
Octubre -
2001
Editor: El Clérigo Urbatain <ruberalbert@bigfoot.com>
Maquetación: Dhan <dhan@interlap.com.ar>
Colaboraciones de: Emily Short, Baltasar García.
Web de SPAC http://usuarios.tripod.es/Urbatain/SPAC/
Artículos:
Meditaciones
del Gurú número 4: 'Simulacionismo en la Ficción Interactiva',
por Emily Short.
Comentarios:
'Tokland' de Ángel Ros Campillo (comentado por Urbatain).
'Masquerade' de Kathleen M. Fischer (por Baltasar García).
'Rameses' de Stephen Bond (por Baltasar García).
Soluciones:
'Masquerade' por Baltasar García.
'Rameses' por Baltasar García.
Por fin llegó el número raquítico que predije. Esto es debido a la nanocomp2 que me ha hecho gastar mis energías en 'Por la Necedad Humana' y dormirme en los laureles los dias posteriores. Pero parece ser que vosotros también habeis dormido agusto, asi que este es el precio que hay que pagar. XD Por lo menos me he currado una pedazo de traducción de unos escritos de Emily Short que tienen mucho que decir sobre simulación en la aventura; cosa que me interesa mucho.
Más
carencias de este número es la sección de KRAC que falta ya por
2 meses consecutivos :-(; bueno, mejor que se curre una buena para el mes que
viene en vez de darnos algo escueto y rápido para este; El Fisgón
qué en su segundo capítulo ya se ha quedado sin nada que decir;
y un Especial de la Nanocomp2 que no lo busques porque no está XD, que
me habría gustado darle un homenajillo pero que quedará para el
próximo fanzine que ya estará todo el pescao vendido y habrá
más chicha para escribir. Al menos la IF competition ya ha cerrado el
plazo de entrega de aventuras, y cuando leais esto ya podreis descargarlas.
Yo realmente estoy emocionadete por ver como progresa allí 'Olvido Mortal',
y por ver las últimas creaciones de ciertos aventureros angloparlantes
(si es que concursan). Aunque yo prefiero esperarme a que esté todo votado
y decidido, pues no tengo el cuerpo para jugar 68 aventuras en inglés,
y asi tirarme para algunas de las
top ten de la tabla.
Pero no hay que olvidar que este es el momento, THE TIME IS NOW, como dirían los ingleses, es el momento de ponernos las pilas, de seguir con el buen tirón que nos ha dado la nanocomp y de programar esas joyitas que tenemos en el tintero para fin de año para que puedan participar en los premios hispanos del 2001 (tengo que hacer la lista.... XD) y que empeceis a donar premios pa las categorías.
Yo ya estoy afilando mi
lápiz, ¿y tu?
El Clérigo Urbatain.
¡Material
de La Aventura Original 2!
Juanjo Muñoz Falcó ha dado
el visto bueno para liberar toda la info existente sobre el proyecto AO2. Al
parecer JSJ ya llevaba 6 años con todo eso en el disco duro y por fin lo ha
subido a la web de caad. Además, Juanjo parece bastante entusiasmado con la
idea de que alguien continue ese proyecto y quizás se huela la presencia
de un concurso para ello. Seguiremos informando...
Memorias
de un hobbit en inform y glulx
JSJ ha hecho un remake de su "Memorias de un Hobbit"usando PAWSEZ
a codigo Z (sin graficos) y código glulx (con graficos):
http://www.iespana.es/jsj/castillo/index.htm
Aventura
Gráfica sobre 'La Abadía del Crimen':
Aventura
Gráfica sobre 'La Abadía del Crimen':
Jordi Pérez, el autor del creador de aventuras gráficas Hermes
anuncia el inicio del desarrollo
de una aventura gráfica basada en el popular juego español de
los años 80 'La Abadía del crimen'. Más información
en su web: http://personal.readysoft.es/coding/hermes/
Adventuregames.about
cerrará
Stephen Granade ha anunciado que la About.com ha despedido 300 sitios incluyendo
el suyo sobre aventuras. Asi que ya podeis borrar si teneis enlazados: http://adventuregames.about.com
y
http://interactfiction.about.com
Fuente
de Adventure 440
Para aquellos que les interese la historia de las versiones de Adventure (la
aventura original
original original de verdad) pueden pillar el fuente completo y perfectamente
funcional de la
versión que tiene 440 puntos en:
http://www.mipmip.demon.co.uk/adv/adv440.html
Shattered
Memory
Este es el nombre con el
que concursa Andrés Viedma alias Akbarr en la IF Competition de este
año. Más info en su web: http://www.terra.es/personal/a_viedma/
¡Suerte Akbarr!
Breves
Conferencia completa de Scott Adams:
http://www.uwec.edu/jerzdg/orr/articles/if/adams/
SPAG 26:
El fanzine inglés papá de SPAC va por el número 26, pilladlo
en:
http://www.sparkynet.com/spag/backissues/SPAG26
Concursos:
Concurso
de aventuras gráficas de DivNet:
http://divnet.divsite.net/graficas/bases.htm
La revista electrónica DivNet, ha sabido tomar el relevo y la responsabilidad
que El Paraiso de la Aventura no supo llevar a buen puerto. Con unos plazos
más realistas que la catástrofe anterior, doy por seguro que será
un éxito: El plazo de recepción de ficheros terminara el día
1 de Febrero del 2002 y los resultados se harán públicos el día
15 de Marzo del 2002. Aun queda muuucho tiempo, asi que a currar quienes tengan
inquietudes gráficas.
NANOCOMP2:
http://pagina.de/nanocomp2
Ya están todas las nanos disponibles a descarga y para votación,
un total de 23 nanos que jugar. La fecha tope para enviar los votos y los comentarios
es el 26 de octubre a las 12 de la noche, que cae en viernes . Estos votos se
envían o a la lista de caad o a la de adventura. Si tienes problemas
con el redirector, prueba esta:
http://www.fortunecity.es/consola/secretos/333/bases.html
IF
Competition 2001:
La IF Competition de este año, el concurso más importante de aventuras
breves de la comunidad internacional de IF, ya está cerrado, podéis
bajar los juegos a concurso en:
http://www.textfire.com/comp01/
A partir del día 1 de octubre, que es cuando los juegos son puestos a
descargar, comienza la fase de juzgar y votar, pudiendo hacerlo hasta el día
15 de noviembre.
Premios
a la Aventura en Español 2001:
http://usuarios.tripod.es/Urbatain/SPAC/premios2001/
Ya podeis ver las bases y organización que este fanzine lleva estos oscars
de la aventura. Recordad que para entrar a "concurso" hay que publicar
un juego antes del 31 de diciembre a las 12 de la noche.
Help wanted!!!
Necesitamos tus artículos para seguir adelante. Esta será una
noticia constante en todos los números ;), ya que el día que no
tenga material suficiente, sacaré un número esquelético
y me retiraré de la edición de fanzines :_( . Si juegas a una
aventura, toma notas, luego las juntas y me lo mandas. Ya tenemos un comentario.
O una solución, o una opinión, o un artículo técnico
sobre programación de aventuras o sobre IA, o técnicas de juego
o mapeado para novatos, o técnicas de tanteado de parsers, etc. Todo
será bienvenido.
Para mandar tus colaboraciones, a mi emilio personal de urgencia: Urbatain@lycos.es
Gracias...
Este mes no
hay fisgoneos... ¡¡¡Manda los tuyos!!! ¡¡¡Colabora!!!
Meditación del Gurú número 4: 'Simulacionismo en la Ficción Interactiva', por Emily Watson
Por
qué molestarse: un pequeño manifiesto.
La discusión sobre simulacionismo en la Ficción Interactiva ha tendido a enfoncarse en la mimesis (representar la realidad con tanta precisión como sea posible en el mundo del juego) y en la calidad de la interacción de un mundo simulado donde habría montones de cosas con las que jugar. Es cierto que a mi me gusta el desafío de implementar las cosas profundamente, y además me gusta un juguete bien construido, pero no creo que eso signifique que las ventajas de la simulación terminen aqui.
No estoy muy interesada en el tipo de juego que consiste principalmente en una serie de puzzles con una única solución. En lo que estoy más interesada es en construir un sistema: un mundo de un juego que se sienta completo, donde haya un número de reglas de interacción o habilidades que el jugador puede usar para manipular el entorno. Asi que en lugar de puzzles, exáctamente, hay problemas que pueden ser resueltos de varias maneras. Asi que la 'simulación como juego' es lo opuesto a 'simulación como juguete'.
'Simulación como historia' es algo un poco espinoso, pienso, pues una de las cosas que la simulación hace es dar un amplio rango de opciones al jugador; es difícil encarrilar la historia si el jugador se dedica a meter cosas en un microondas y reventarlas. Pero aqui, hay ciertos aspectos que hay que tener en cuenta.
Uno: simular algo no quiere decir simularlo todo. Galatea es una profunda simulación en el sentido de que la conversación con PNJ (personaje no jugador) está extensamente trabajada; pero es muy superficial en el sentido de que no puedes ver lo que llevas, y mucho menos hacer cosas hediondas con el soporte físico. El enfoque es importante.
Dos: poner poder en las manos del jugador puede conducir a interesantes posibilidades en contar una historia con multiples lineas o ramas de guión. Si hay una historia en progreso, pero con varias formas de ir hacia adelante debido a la amplitud del mundo simulado, las fases finales del juego pueden cambiar sutilmente para reflejar los cambios hechos por el jugador. Y eso mola. En mi opinión.
Desiderátum
para una Librería de Simulación Física.
Lo que sigue es una descripción
de caminos simulacionistas para poner en práctica. Algunos yo ya los
he conseguido o he implementado en parte en alguno de mis juegos o experimentos
(Señalados con (SI), o
eventualmente remito al código fuente). Trato de tocar tres puntos con
esto:
a) cómo tratarías con este tipo de simulación;
b) por qué sería interesante hacerlo; y
c) qué inconvenientes hay, ya sean técnicos o desde la perspectiva
del jugador.
Tamaño,
capacidad, densidad, peso y forma.
Una de las formas más simples de simulacionismo sería añadir límites restrictivos de capacidad. Extender esto para proveer a todos los objetos volumen/peso/densidad daría cuenta de problemas como la flotabilidad (¿una cosa flota o se hunde?). Es un sistema simple de diseñar, pero tiene unos cuantos inconvenientes. Uno es que un buen trabajo del estilo requiere un mejor soporte numérico del que Inform hasta ahora proporciona. El segundo es que actualmente no es útil para la mayoría de los puzzles, los cuales (generalmente) tienden a encenderse en propiedades menos precisas de los objetos. El tercero es que puede ser intensamente tedioso para jugar, ya que habría constantes problemas moviendo los objetos de un lado para otro. Y un cuarto (¿dije unos cuantos? quise decir muchos) es que sería difícil de escribir, porque habría un montón de formas a rellenar para describir los objetos. Además, algunos puzzles que funcionan según exactas propiedades físicas requieren una demasiado exacta descripción física.
Asi que no estoy diciendo
que sea una mala idea enteramente; el resultado podría ser ciertamente
interesante bajo las circunstancias correctas. Pero un sistema de este tipo
gastaría probablemente intensívamente memoria y tiempo de escribir
(escribir los objetos, es decir; el código base no sería particularmente
difícil con toda probabilidad, pienso que consideraría más
complejo si uno empieza a tomar cosas como la forma de los objetos). La aplicación
de este tipo de sistema tendría más sentido, pienso, probablemente,
en un estrecho entorno de juego pequeño donde el uso y abuso de estas
propiedades de los
objetos sería la meta principal del juego.
Una reducida versión de esto simplemente para marcar las cosas con formas y tamaños más generales (tamaños de 1 a 4, por ejemplo, para un rango de tamaños que pueden ser manipilados por un humano, y formas tales como plano, con forma de piedra, etc). Asi es como trabaja Metamorphoses ftp://ftp.ifarchive.org/if-archive/games/zcode/metamorp.z5 parece queha sido bastante adecuado.
Código fuente de
'Fractured Metamorphoses' http://emshort.home.mindspring.com/metaexam.inf.txt,
ejemplos de clases de materiales.
Librería de cerraduras: http://emshort.home.mindspring.com/locksmith.h.txt necesaria en Metamorphoses.
Sentidos
y descripción.
Este tipo de cosas es más una cuestión de generación de prosa que de hacer un juego más colorido e interesante, aunque puedo imaginar puzzles entorno a esto, donde el truco consista en tener o crear una fuente de luz de la justa intensidad y coloración para una meta en particular.
Luz de diferente intensidad o color. (SI) Podría ser, por ejemplo, luz lo suficientemente brillante para ver pero no tan brillante como para permitir leer. O luz de diferentes colores. Una rutina maestra buscaría la fuente más fuerte de luz de la habitación, que afectaría la descripción de los objetos. Portando una linterna en la habitación daría una diferente descripción que llevando un candil o abriendo una ventana durante la luz del día. También sería interesante hacer contenedores translúcidos o coloreados que reducirían pero no iluminarían la intensidad de una luz emitida desde dentro.
Sonidos. (SI) Objetos golpeados entre si por sacudidas o por cerrar algo de golpe deberían producir los sonidos apropiados. Esto requiere identificar los materiales en cuestión y hacer la generación de la prosa.
Cronometraje.
Una pregunta en simulación es cómo quieres tratar el tiempo. Un turno puede ser considerado una unidad de tiempo que siempre tendrá la misma longitud (ej: un minuto), o la longitud de tiempo que lleva en finalizar la acción.
Fuego cronometrado. (SI)
>QUEMAR comienza el proceso de que un objeto arda, pero eso estará
ardiendo todo el tiempo que sea necesario. Que dependerá de la sustancia
de que el objeto está hecha, y su tamaño. Varias cuestiones surgen
entonces. Una es que el jugador debería dejar el objeto en algún
momento
(si lo lleva consigo) porque sería consumido si se empeña en seguir
cogiéndolo. Otro es que la llama puede propagarse a otros objetos; y
una tercera es que un fuego puede ser interrumpido antes de que termine (Ver
fuego interrumpido, más abajo).
Desde el punto de vista
técnico, el reto aqui es que pronto tendremos numerosos cronómetros
y demonios trabajando a la vez, especialmente si la llama se propaga o el jugador
es particularmente pirómano. Problemas de parseado y de desambiguación
vienen si al jugador se le ocurre hablar de "llamas" o "fuego"
(ej: tengo doce objetos diferentes ardiendo en la habitación y el jugador
pone >ECHA AGUA SOBRE FUEGO). Si la propagación es permitida, de nuevo
hay que tener cuidado determinando qué es lo que debe de arder
(objetos en contacto físico con el objeto ardiente, si son inflamables,
si no son el propio jugador o la propia habitación, etc).
Calentando y enfriando,
Asociado con el anterior, y probablemente, como el anterior, requeriría
cronómetros y demonios, la cuenta del tiempo pasado y la cuenta de la
cantidad de calor o frío comunicado al poner un objeto en un fuego o
en un congelador. Más complicado sería rastrear cosas como la
energía térmica del completo objeto y conseguir que sea termodinámicamente
exacto, pero de nuevo esto requeriría figurar quién está
tocando a quién, cuanto tiempo, y... arf. Siento que este tipo de cosas
no serán ampliamente útiles,
pero podría sería bueno tratar objetos que han estado recientemente
en contacto con el fuego como demasiado calientes para cogerlos, por ejemplo.
Disparadores y explosivos. Esto es realmente divertido pero muy peligroso, porque contra más poder pones en las manos del jugador para destrozar todo el entorno más problemas tendrás controlando lo que finalmente pasará (y prevenir de que vuele algo que necesitará más tarde). Mira lo que digo sobre destrucción en general.
Destrucción
y Restos.
Cualquier tipo de acción destructiva es inherentemente peligrosa de permitir, porque una vez que el jugador empieza a destruir el mundo del juego, las cosas empiezan a volverse locas.
Fuego interrumpido. (SI)
Soplar o echar agua sobre algo ardiendo lo apagará. Esto es chungo pues
entonces tendrás una cosa parcialmente achicharrada con la que tratar:
debe de ser descrita en la forma en que se quede, en su estado parcial teniendo
en cuenta los aspectos de simulación de peso; quizás su carbonización
tenga que convertirlo en una herramienta para escribir o marcar (ver olores
y manchas, más abajo). Todo esto puede ser ignorado si no tienes fuego
cronometrado. (Por ejemplo, si quemar algo transcurre completamente en un sólo
turno, entonces no hay momento en el que el jugador pueda intervenir, y el
enredo es evitado).
Rompibles (Ej: cristal). (SI) Objetos frágiles pueden ser hechos pedazos. Esto es bastante fácil de hacer, y aqui pienso que hay que distinguir entre >DEJAR (dejar un objeto cuidadosamente) y >LANZAR (destruir el objeto en el proceso de deshacerse de él). (Ver Metamorphoses).
Cortar. (SI) Cuchillos puedes cortar diferentes materiales. 'The Last Sonnet of Marie Antoinette' (Juego: http://www.plover.net/~emily/marie.z5 Código fuente: http://emshort.home.mindspring.com/later.inf.txt) tiene esta característica, y también ilustra diferentes resultado al cortar algo (el objeto es destruido enteramente; el objeto es abierto; el objeto es reducido en tamaño y deja fragmentos en el suelo; el objeto es reducido en tamaño y además produce objetos en rebanadas).
Hablando en general, el
truco real aqui, más que crear objetos dinámicamente, es decidir
cual será el resultado al cortar. Para contenedores que están
cerrados, cortar haría un agujero equivalente a suministrarlos permanentemente
abiertos; para cosas que no sean abribles, cortar divide el objeto, haciendo
una nueva pieza que será del mismo material, pero un trozo del bloque
viejo. Puedo también imaginar herramientas para cavar que crearían
hoyos o huecos en la superficie de un objeto que los convertiría en contenedores...
Idealmente uno quizás desearía permitir al jugador especificar cómo quiere cortar el objeto, pero esto nos llevaría a un barrizal sintáctico.
División
y Mezcla.
Dividir y mezclar líquidos. Esto requiere, de nuevo, contenedores con una capacidad conocida. Además requiere la creación de un nuevo objeto, o algo por el estilo, para simular las partes separadas, y seguir la pista de los diferentes componentes de la mezcla, si quieres hacer recetas o algo por el estilo. De nuevo esto es un poco fastidioso si no tienes acceso a numeros flotantes (Inform...) pero de algún modo podrás vivir con ello.
El problema real que he tenido en este campo de batalla hasta ahora es distinguir entre dos otrora idénticos líquidos en contenedores separados. Lo qué me gustaría es que el juego desambiguase preguntando, "¿A cual te refieres, el vino en la copa verde o el vino en la copa roja?" Pero no he podido producir este resultado eficazmente. (Nota: John Calagioia me ha mandado gentilmente un código que puede resolver mis problemas. He tenido una agenda ajetreada, pero quizás la solución ahora descansa en mi mano... [risa demoníaca])
Marcas,
Señales y Grabaciones.
Ahora esto, que creo, tiene un gran potencial, pero hasta el momento está inexplorado.
Humo. (SI) Quemar algo demasiado tiempo produce humo en la vecindad. Esto no es particularmente difícil de programar (para nada. Ver la pequeña cantidad de código en 'The Last Sonnet of Marie Antoinette' http://emshort.home.mindspring.com/later.inf.txt No estoy segura de lo útil que pueda resultar, quizás marcar el camino por un laberinto es una posibilidad, y un PNJ irritante y asmático podría ser otra.
Carbón. (SI) Quemar
algo dentro o sobre la superficie de un cristal produce manchas de carbón.
(De nuevo ver 'The Last Sonnet of Marie Antoinette' http://emshort.home.mindspring.com/later.inf.txt:
intenta quemar la caja de madera con la vela, entonces examina los objetos que
aparecen en el proceso). Lo divertido de esto es que permite al jugador cambiar
la transparencia (o en las apropiadas cirscunstancias, la translucidez) de un
objeto, con frotar/limpiar/pulir se consigue el efecto contrario, asi que no
cambia el estado del juego de forma irreversible, y se combina pulcramente con
otras posibilidades.
Olores y manchas. (SI) Fluidos salpicando, derramados, o de otra manera aplicados pueden transferir olores y manchas a los objetos.
Papel de calco, escritura, dibujar; cámaras.(SI) La posibilidad de hacer frotamientos de una superficie para transferir la textura o escritura debajo (como está modelada en Peacock ftp://ftp.ifarchive.org/if-archive/games/zcode/Peacock.z5
Cámaras de áudio y vídeo. Otro aspecto de nuevo de la simulación de grsbaciones de áudio y vídeo es que tienen que responder con precisión a los eventos del entorno. Varicella y The City, además de otros, toman este problema, pero de la forma (imagino) de codificar un número de posibilidades que ocurren en la vecindad del objeto. Una verdadera aproximación simulacionista (donde se podría colocar una grabación donde se quisiese y tener una precisa grabación de sonido o de la vista del entorno) requeriría reglas de paso de sentidos en un orden medianamente bien construido, esto es, por ejemplo, pongo mi cámara espía en un estante, 'vería' todo lo que pasa, pero si la pongo en una caja, tan sólo 'escucharía', y la imagen de video sólo captaría oscuridad. Grandes dolores de cabeza hay aqui. Aún no los he tratado.
Objetos
generales y Multiplicidad.
Multitudes y colecciones.(SI) Dondequiera que tengas un gran número de objetos, querrás permitir al jugador el inspeccionar el grupo como un todo, pero también identificar y examinar miembros individuales, quizás buscar atentamente por una cosa específica o quizás meramente hojear. La librería en 'Pytho's Mask': ftp://ftp.ifarchive.org/if-archive/games/mini-comps/smoochie/pytho.z8 es uno de mis intentos para tratar con este problema: puedes mirar todos los libros en general, y esto conducirá tu atención semi-aleatoriamente a algunos específicos que conseguirás ver, en los que podrás examinar más profundamente. Esto requiere un montón de contenidos que codificar (puesto que tienes que escribir todos los subobjetos), pero es un poco más realista, creo, que tener un objeto general libros del cual no puedes inspeccionar ninguno de sus componentes individuales. Tu kilometraje puede variar de un extremo a otro.
Eslabones
y Corbatas.
La cuerda definitiva. Este
es uno de los temas que han recibido tanta atención que parece sin sentido
enumerar la variedad de desafíos asociados con ello. Antes que nada,
una cuerda tiene dos extremos, así que hay que recordar el estado de
cada uno (y desambiguar entre ambos cuando el jugador los referencie, por supuesto).
Luego está el atributo de objetos al cual podrá atarse la cuerda;
la posibilidad de cortar la cuerda por la mitad, haciendo multiples cuerdas
de nuevas longitudes; el problema de usar una cuerda como un fusible o conector,
o atarla a algo e irlo arrastrando por el otro extremo, o atar ambos extremos,
etc, etc, etc.
Últimamente pienso que la parte más delicada de todo esto es la
desambiguación, por ejemplo, figurar que quiere decir exactamente el
jugador cuando dice >ATAR CUERDA A X (¿qué cabo? Desataremos
algo que ya estaba atado, si ambos lados están en uso?) Es todo bastante
grotesco, francamente.
Manejo
Sofisticado del Espacio.
Continuidad del espacio. Ni en Inform ni en TADS, por supuesto, mantienen realmente cuenta de las relaciones físicas entre lugares. Pero, ¿No sería permitir al jugador crear nuevas conexiones entre lugares haciendo boquetes en las paredes, o cavando en el suelo? Esto requeriría, naturalmente, que el juego modele la localización relativa de las cosas, y donde haya un muro que toca a otro que en algún momento quizás se pueda pasar a través de él. Este modelo debe tener en cuenta cosas como el paso de sentidos (si cada dirección indica a) donde está la localidad adyacente si es que la hay y b) como un muro está en medio, entonces el juego debe de saber el cómo podrás mirar en dicha localidad adyacente (a través de una ventana, por ejemplo), o escuchar las cosas que suceden en ella).
He tratado de manejar esto en cierto grado en Marble Madness ftp://ftp.ifarchive.org/if-archive/games/mini-comps/arcade/arcade.zip, donde es posible rodar desde una habitación hasta otra sin emitir la orden >IR, pero esto no implica ninguna programación avanzada.
Emily Short. (emshort@mindspring.com)
Traducción por Urbatain.
Puedes encontrar el texto original en su página web personal:
http://emshort.home.mindspring.com/index.htm
Así como sus fantásticos juegos y códigos fuentes sobre
simulación.
CLAVES PARA LA FICHA Y PUNTUAR EN LOS REVIEWS
NOMBRE: Jabato
AUTOR: Aventuras AD
EMAIL: ???
FECHA: mes xxxxx 1989
PARSER: DAAD
SOPORTE: PC - SPECTRUM - AMIGA
DISPONIBILIDAD: Abandonaware
URL: No disponible.
TIPO: Basado en el comic.
Cuando mandes comentarios para las reviews, puedes poner SI QUIERES un puntaje valorando la aventura considerando una escala del 1 al 10, según tus apreciaciones.
Tokland
NOMBRE:
Tokland
AUTOR: Ángel Ros Campillo
EMAIL: campillo@ctv.es
FECHA: 30/11/2000
PARSER: InformatE
SOPORTE: Multiplataforma
DISPONIBILIDAD: Freeware
URL: ftp://ftp.ifarchive.org/if-archive/games/zcode/tokland.zip
TIPO: Fiesta de puzzles
ATENCIÓN: Este juego es orientado a puzzles. Este juego es bastante difícil. Yo fui su tester.
¿Orientado a puzzles?
Completamente, desde el inicio hasta el fin. Afortunadamente son más
o menos lógicos y tienen su razón de ser, pues el juego está
basado en el libro "El Misterio de la Isla de Tokland" de Joan
Manuel Gisbert del cual sólo toma el argumento y el nombre, lo demás
no tiene nada que ver, así que no esperes ver una copia del mismo paso
a paso.
La historia cuenta, que
la compañía propietaria de la Isla de Tokland, ha convocado el
concurso más importante de todos los tiempos que consiste en resolver
un enigma múltiple. El concursante que consiga la hazaña recibirá
5 millones de dólares. Este juego es la primera parte de la historia,
que consiste en pasar las pruebas de selección de concursantes. El objetivo
es tan simple como conseguir el salvoconducto para acceder al enigma en si,
la dificultad es que pondrán a prueba tanto tus conocimientos, como tu
inteligencia y entereza. El protagonista es un periodista que motivado por la
curiosidad y para hacer un reportaje para la revista en que trabaja, ha conseguido
una oportunidad de presentarse a la selección de concursantes.
Después de volar hasta la isla y de intercambiar saludos, es conducido
hasta un baño para asearse, sin saber, que en ese momento justo, las
pruebas para lograr el salvoconducto, han empezado.
Asi que, como ya habréis intuido, el juego es la primera parte de otro que aún no ha sido creado. El autor está en ello ahora mismo.
La literatura del juego es correcta, más que correcta, su autor gusta de lo políticamente correcto, y asi se nota en la rectitud de los textos, aunque alguna errata en la ortografía se puede encontrar, pues él es ciego y aunque es un máquina con la ortografía, es inevitable cometer gazapos tecleando de "oido". Incluso ha sido revisado varias veces (por mi ;), yo he sido el tester oficial), pero los errores que puedan haber quedado no creo que supongan ningún problema para jugar al 100%.
La jugabilidad es, a pesar de la dificultad elevada, muy aceptable, pues una de mis mayores labores como tester usual es fastidiar a los autores para hacerlo todo lo más lógico e interactivo y jugable posible. Las gramáticas de las acciones están muy bien construidas y algunos puzzles o entornos están muy bien construidos en cuanto a la programación, y aunque no hay maneras alternativas de resolver los puzzles, jamás se puede dar el caso de un problema de 'síndrome de la palabra exacta'.
Otro aviso: En el juego hay un sólo PNJ (sin considerar animales y alimañas) con el que es imprescindible interactuar para avanzar en las primeras pantallas.Otro aviso: Este juego requiere examinarlo todo, todo, todo. por encima, por debajo, por detrás, tiene muchas cosas escondidas y es posible quedarse estancado sin posibilidad de ganar y que el jugador no lo sepa. Se debe grabar a cada paso.
Por otra parte, contiene puzzles muy clásicos, incluso algunos códigos sacados directamente del DM4 o documentate, como por ejemplo: el abismo con tablón endeble. Y es que, es el primer juego del autor, y fue aprendiendo inform sobre la marcha, aplicando lo que aprendía a su juego (buena filosofía ;)). Algunas situaciones están subyugadas a los puzzles, resultando irreales y poco lógicas desde el punto de vista simulacionista, pero esto no quiere decir que sea algo negativo, simplemente, su autor gusta de incluir problemas de lógica populares en sus juegos (Sólo hay que ver su posterior creación Celos para la nanocomp2; y nos promete que en Tokland 2 meterá más intensamente este tipo de puzzles). En concreto me refiero a cierto sótano que es el núcleo del juego y que hay que analizar en profundidad para poder avanzar.
¿Y los puzzles son
buenos? ¡Deberían!, si es intensivo en puzzles... Sí lo
son, todos contienen ese factor frustración-eureka que deja tan buen
sabor de boca. Aunque en este aspecto también puede haber opiniones enfrentadas,
ya que muchos de ellos son de busqueda de objetos escondidos, abrir cierta puerta
con cierta llave, etc etc, todo está escondido inicialmente en este juego.
Al principio el juego
es muy cerrado, dejandonos nada más empezar atascados en 3 o 4 habitaciones,
con 3 cajas misteriosas que deben ser abiertas para
poder avanzar, las 3 con acertijos típicos de conocimientos, muy simples
y a la vez muy gratificantes (si te gusta este tipo de juegos, claro). Pero
después el juego se abre, dandonos una amplio abanico de problemas a
la vez, que nos dejarán atascado y con unas cuantas zonas posibles donde
explorar.
Afortunadamente estas no
lo son tanto y la posibilidad de lugares queda reducido a 4 o 5, y ello nos
permitirá concentrarnos en los objetos y en los obstáculos y asi
lograr la solución para resolverlos. Pero, ¡je je je!, el
juego realmente tiene mala leche, para complicar la tarea hay varios objetos
"red herrings" (inservibles), incluso puzzles "red herrings",
me atrevería a decir, de por medio que nos desorientarán. Por
otro lado... hay un puzzle que es simplemente maravilloso, bastante ingenioso
y muy gratificante, del tipo que gritas: "¡eureka!", mientras
se te erizan los pelos de la piel, casi comparable al gran puzzle de "Spider
and Web"
de Andrew Plotkin (No recuerdo un puzzle de este calibre en una española).
Una pena no poder hablar mucho de él, sólo decir que hay que resolver
el vacío: el jugador se encuentra ante un vacío sin poder avanzar,
un momento de gran frustración, y la solución está ahí,
increíble y maravillosa como ella sola. Este gran puzzle supone un pistoletazo
para ver que estamos cerca del final del juego, a partir de aquí, nuestra
pericia habrá aumentado bastantes puntos, así que los puzzles
finales no serán de gran problema e iremos, sin duda, directos hacia
el final del juego, un final sobrio, teniendo en cuenta que es el principio
de la segunda parte.
En resumen, es un gran juego, si te gusta quebrarte la cabeza, pasarás una buena temporada con él. Hay un fichero de ayuda junto con el zip del juego por si llegas a desesperarte, pero si eso no es suficiente, siempre queda los emails que tanto Ángel Ros o yo estaremos gustosos de responder a cualquier duda. También dispone de cierta AYUDA dentro del juego, pero se limita a decir un consejo en cierta localidad... es muy rudimentaria pero a veces conviene usarla y no te reventará ningún puzzle.
¿Se nota que soy el tester? ;). Es broma. Si opino que es un juego bueno es porque ya me lo pareció antes de testearlo a fondo (yo no testeo nada si no está finalizado y es acabable). El juego en general es muy correcto, pero quizás os parezca desfasado respecto a la producción que se ve en la comunidad IF inglesa y americana o a las últimas tendencias, pero eso no debe restar puntos a la calidad global del juego. Es más, yo mismo estoy un poco cansado de juegos breves o sin puzzles, muy interesantes del lado de la "innovación", o de la historia, pero no dejan el mismo sabor de boca que un buen clásico repleto de puzzles buenos. Esto hizo que considerase a Tokland como un rayo de luz en la oscuridad: un juego más o menos largo, dificil y con puzzles lógicos. ¡Que más se puede pedir!
Urbatain
Masquerade.
NOMBRE:
Masquerade
AUTOR: Kathleen M. Fischer
EMAIL: mfischer5@aol.com
FECHA: septiembre 2000
PARSER: Inform
SOPORTE: Multiplataforma
DISPONIBILIDAD: Freeware
URL: ftp://ftp.ifarchive.org/if-archive/games/z-code/Mask.z5
TEMATICA: época
SINOPSIS:
Tomas el papel de Amelia, una joven que desearía haber nacido hombre
para poder así llevar la compañía que heredó de
su padre.
ARGUMENTO y JUGABILIDAD:
Amelia necesita urgentemente inversores para su empresa, que está realmente
cerca de la bancarrota. Sin embargo, se verá constantemente perjudicada
por el hecho de mujer. La aventura comienza con un puzzle
relativamente fácil de resolver, en el que Amelia tiene que entrar en
un club reservado sólo para hombres, para pedirle a su tío que
se haga cargo de la empresa, ya que los inversores no confíarán
en la firma de una mujer. La única forma de interactuar con los personajes
es mediante el comando "talk to" que la autora ha abreviado con "t
<personaje>". Sin embargo, es bastante confuso el hecho de que cuando
introduces este comando, no puedes elegir lo que vas a decir, sino que lo que
la autora ha pensado adecuado para el desarrollo de la historia. Por tanto,
nuestra principal forma de variar en lo posible el devenir del argumento será
responder sí o no a lo largo del juego a las preguntas que nos hagan.
COMENTARIO:
Participó en la IF competition del 2000 quedando en la octava posición.
Se nota muchas veces que la historia es estrictamente lineal, sin embargo algunas
respuestas que demos pueden variar ligeramente el argumento, actuando de atajo
hacia el siguiente hito en el argumento. Por ejemplo, en el primer puzzle puedes
evitar que despidan a Simon, pero eso no variará el resto de la historia.
El hecho de no poder elegir qué decir a cada momento es muchas veces
frustrante.
El problema se soluciona a medias al final, en el que como la misma autora comenta, puedes elegir entre doce posibles conclusiones. Esto está bien, pero no es más que un espejismo. Por supuesto, el construir aventuras no lineales es muy difícil (es un reto abierto), el problema es que de no ser por las posibilidades de elección al final, la aventura se parecería mucho a una de las aventuras de Adam Cadre estilo Fotopía, en las que lo que hagas no tiene el más mínimo interés, pues el hilo del argumento es fijo. Por supuesto, aquí nos encontramos con los gustos personales de cada uno.
La historia está fantásticamente bien contada, y la linearidad no es demasiado escandalosa la mayor parte de las veces. El vocabulario es un tanto "suntuoso", y me ha obligado a buscar muchas plabras en el diccionario. El autor es una mujer, y eso se nota en el hecho de que en muchos momentos, nos parecerá (a mí me lo pareció, al menos) que estamos viviendo algún momento de una novela rosa. Como nota curiosa, el final preferido del autor (que además puntúa el doble) es el más romántico posible de todos (en algunos momentos, se echa de menos el no poder introducir 'say to ethan "get lost!"' o algo parecido).
Baltasar García.
Rameses.
NOMBRE:
Rameses
AUTOR: Stephen
Bond
EMAIL: ¿?¿?
FECHA: septiembre
2000
SOPORTE: multiplataforma
DISPONIBILIDAD: freeware,
inglés
URL: ftp://ftp.ifarchive.org/if-archive/games/zcode/rameses.z5
TIPO: costumbrista
SINOPSIS:
Ramses es un joven tímido, sin personalidad, a quién debemos ayudar
en su primera cita con chicas.
ARGUMENTO Y JUGABILIDAD:
Ramses está en una edad ciertamente difícil. Todo son problemas
para él, en internado en el que vive. Es un chico tímido, como
el mismo dice, sin personalidad, sin amigos, que ansía "su libertad",
encontrarse a sí mismo, vamos. Nosotros debemos ayudarle a conseguir
su objetivo, desde primera hora del día en que va a tener su primera
cita con chicas, hasta la misma cita. La aventura es muy entretenida, aunque
eso sí, está en perfecto inglés. La forma de dialogar con
los otros PNJ's es mediante "talk to", apareciendo entonces la típica
lista de cosas que decir. Es fácil avanzar en la aventura y el argumento
invita a llegar hasta el final, te mantiene colgado.
COMENTARIO:
Participó en la 2000 Interactive Fiction Competition quedando en la posición
13. El argumento en sí es muy bueno. Sólo tiene una pega, que
desde mi punto de de vista "mata" la aventura. Que es fijo. Es decir,
hay muy poca aventura en esta aventura. Al poco de empezar a jugar en esta aventura,
te das cuenta que no eres más
que un mero lector. Poco importa lo que hagas, las aventuras/desventuras de
nuestro protagonista seguirán un curso invariable. Definitivamente, no
es una aventura para jugar más de una vez (eso seguro).
El colmo es cuando intentas elegir una determinada frase a la hora de hablar con otro personaje que debería cambiar o al menos afectar el rumbo de la aventura: la solución para mantener un guión inamovible es que el protagonista nos obsequia con un "Oh, my god, I can't say that!" o parecido, de forma que nuestra acción se limita muchas veces a entrar una y otra vez el comando 'wait'. Hay aventureros a los que les gusta este tipo de aventuras: para ellos creo que esta aventura está muy bien cuidada, redactada en un estilo ágil, interesante.
En mi caso particular,
el argumento me ha gustado, pero la aventura me ha
dejado un tanto ... frustrado ...
Baltasar García.
El puzzle "más difícil" sin duda es el que nos encontraremos al principio del juego. Consiste en como colarse en el club de hombres, siendo una mujer. La solución, después de hablar con Simon, consiste en ponerse un sombrero y un abrigo que encontrarás en un sofá. Entonces, vete hacia el norte y Simon te dejará pasar. Eso sí, probablemente no evitarás que le despidan. El resto de los puzzles son evidentes y sólo hablando con los personajes adivinarás qué hacer en cada momento.
Baltasar García.
Como ya he dicho en el
comentario de Rameses, muchas veces el desarrollo de la aventura se limita a
que introduzcas 'wait' de vez en cuando. Los pocos "puzzles" que te
encontrarás podrás resolverlos de forma muy lógica.
Por la mañana:
wake up
wait
wait...
eat breakfast
talk to ferdia
wait ...
En la habitación, antes de la cita:
talk to paddy
x paintings
x paintings
x paintings
talk to wayne
open wardrobe
x clothes
get clothes
drop uniform
wear clothes
[sales a la calle automáticamente]
En la calle:
east
east
[automático hasta el café PJ]
talk to alice
wait
wait...
get up
wait
wait
jump into water
east
kiss claire
kiss claire
[automático hasta el final]
Baltasar García.
