Scripting para aventuras gráficas

[LC0]

Es una pena que el género de las aventuras gráficas haya perdido tanto terreno de aquí a hace unos años, siendo uno que ha tenido siempre bastante aceptación, a mi parecer (sin contar con salidas como el Runaway 2). Por suerte, parece que en la escena indie no es así; ni hace falta que comente cual fue el ganador del ArtFutura del año pasado :P.

Desde hace cierto tiempo me ha picado el gusanillo de hacer algún sistema tipo SCUMM como humilde granito de arena. Y que mejor que aprovechar el tirón de los lenguajes de script actuales para ello.

Tengo dos proyectos comenzados al respecto, uno bastante adelantado y otro parado a la espera de retomarlo. Los dos son motores de lógica para hacer aventuras gráficas que tengan una estructura casi similar (sin llegar a tener porque ser mutuamente compatibles, ya que espero que quede algo más refinado el último que el primero, sin contar con la diferencia de la naturaleza de los tipos de aventura hacia los que los motores están orientados).

El último es , básicamente, una biblioteca hecha en C++ para Python, usando Irrlicht de fondo (para aventuras en 3D).  Está parado desde que me encontré ciertas dificultades para exportar a B3D con herramientas que no son de pago (sí, soy un matao para estas cosas, y más últimamente :P) para empezar a probar el añadido de objetos interactivos en los escenarios.

El primero es para aventuras en 2D, y es una biblioteca en Python para Python. Creo que está bastante avanzado, quedando por hacer:

-Dibujado por capas espaciales estableciendo un orden Z.
-Salvaguardado de partidas (por serialización no debería reportar mayores problemas para implementar).
-Embellecimiento de la interfaz, cuyos elementos son visualmente bastante feos (las acciones aplicables a un objeto se muestran en un menú desplegable gris con texto color negro y fuente tipo sans-serif).
-Factoría de interfaces, para poder programar nuevas y acoplarlas al sistema según se desee (esto, en cierta medida, englobaría el TODO-entry anterior).
-Refinamiento de las funciones aplicables al mundo (según demanda).

La idea para las dos es bastante fácil. Una aventura se compone de, básicamente:

-Un diccionario de variables de estado (por ejemplo, del tipo

caer_bien_a_tendero = "true", numero_repeticiones_conversacion_guarda = "5").
-Una lista de escenarios.
-Una lista de objetos, con un diccionario cuya clave sea el texto de la función a ejecutar tras pulsarla  (y el texto de una frase en una conversación) y una función a ejecutar, con la lista de acciones a realizar dado el evento. Esto incluye también a los objetos del inventario (la única diferencia, obviamente, residirá en que no pertenecen a un escenario).
[/list]

Un grupo de acciones se inserta en una cola. Hasta que la última acción del grupo termine de ejecutarse o pase un tiempo especificado, no se ejecutará el siguiente grupo. Esto es lo que hacen los eventos asociados a las acciones, añadir a la cola grupos de acciones.

No pongo ningún pantallazo porque los gráficos de la prueba son, como mínimo, horribles. Como pequeña descripción: Un bicho rosa dentro de un quiosco de información turística en un vertedero, y una máquina detrás que parece sacada del cerebro de Gaudí. Todo con dibujos renderizados con cel-shading  (hale, ya está xD).

Las diferencias del motor 3D, sin contar con las de programación (otro lenguaje y biblioteca gráfica), estriban en la naturaleza tridimensional del asunto. Hay que añadir movimientos de cámara, y esto escribirlo en un script es difícil, por lo que habría que meter como complemento un editor de escenarios (cosa que, claro está, tampoco vendría mal al motor 2D, o como mínimo un editor de grafos para los caminos del objeto protagonista u otros objetos).

[Loover]

Aventuras salen cada mes al mercado más de las que crees, echa un vistazo por meses a  http://www.aventuraycia.com/ y algunas con muy buena calidad.

Ahora bien, en el mercado actual, no se consumen tan bien como en la "época dorada" de Sierra y Lucas Arts. Los tiempos cambian, los gustos también.

En cuanto a tu proyecto... bueno, ya hay muchos "parsers" de aventuras gráficas. Pero si lo haces desde un punto de vista didáctico y por entretenimiento, pues adelante.

Pinta bien las cosas que has comentado, ya enseñarás cosillas :D

[kaworu]

no es solo q cambien los tiempos y los gustos, sino que el avance del 3D no le hizo ningún favor a juegos horribles como el monkey island 4....yo creo que aun está un poco por explotar bien el 3D con aventuras gráficas, pero muchos de los juegos que más recuerdo de mi infáncia son aventuras y yo no duraría en volver a jugarlas.
Ejemplo: Double Trouble o Monkey Island 3 (dráscula de peke jugué a una demo y me encantó, no era española? xD)

[bnl]

Yo tambien estoy haciendo algo similar.

Vete comentando la evolucion de los proyectos, es un tema interesante.

Saludos

[LC0]

En cuanto a tu proyecto... bueno, ya hay muchos "parsers" de aventuras gráficas. Pero si lo haces desde un punto de vista didáctico y por entretenimiento, pues adelante.

Ya... Alguien estaba haciendo el PyScumm. Aparte de otros parsers que pululan por ahí y que ya están más que maduros. Como tu insinuas, lo hago porque me entró el gusanillo, simplemente. Si en algún momento me viene alguna otra idea cuyo factor gusanillo sea mayor,  entonces es probable que  El Mulo manipule mis sentimientos sobre estos proyectos :P.

bnl, si entonces estás haciendo otro motorcillo, ya entiendo porque ese entusiasmo en la verificación de inclusión de puntos en polígonos irregulares :). El tema de las áreas de movimiento lo tengo simplificado por el momento, con aras de ampliarlo también en un futuro, pero con áreas rectangulares para simplificar cálculos. De momento, los objetos se ciñen a puntos en el grafo.  A la hora de trazar un camino, de esta forma, el objeto se dirigirá primero al centro del rectángulo (que coincidirá con un punto del grafo), y después seleccionará los destinos con una especie de variante del A*.

Bueno, me estoy enrollando demasiado, ya iré contando más cosas y mostrando pedazos de código.