CAAD

Viene de viewtopic.php?p=66255#p66255



Parece razonable, aunque se me ocurre la posibilidad de informar al cliente de AGE sobre los marcos involucrados en los gráficos y tal. Pero, de momento, centrémonos en que el autor se encargue del asunto, porque lo otro requeriría un cambio algo más profundo.

La opción actual es que el autor proporcione un comando extra (el típico gráficos sí/no) en el propio juego, pero se me antoja un tanto incoherente dada la filosofía de los clientes actuales de AGE, que proporcionan opciones en el menú para sonido y efectos de texto. Da la impresión de que la opción sobre gráficos encajaría perfectamente a su lado

Lo ideal sería tener ambas posibilidades sincronizadas, pero esto también requiere su estudio.

En la API actual existe, en el objeto del jugador, getIO().isGraphicsEnabled(), que intuyo está ahí precisamente para reflejar el estado de la supuesta opción y que ha de tenerse en cuenta siempre según la documentación sobre imágenes.



Pero como durante la partida es posible que el jugador desee alternar, necesitaríamos un "evento" que indique que la configuración del cliente ha cambiado, algo como aPlayer.onGraphicsSwitch(boolean nuevo_estado_del_switch). Creo que debería llamarse únicamente cuando cambie el switch (para evitar llamadas fantasma, tipo "ha cambiado de true a true", que compliquen el asunto).

No sé cómo de factile sería, sobre todo teniendo en cuenta que podría ocurrir en cualquier momento (en especial durante un pulsa-tecla).

Serviría para que el autor destruya o recree la parte gráfica. Al recrearla, el autor volvería a cargar la imagen correspondiente al momento actual del juego, lo que obliga a llevar un control sobre las imágenes que se han ido no-mostrando (nótese que AGE no se limita al concepto "imagen por localidad").

Nosotros tenemos la cuestión gráfica centralizada (mediante funciones de apoyo) y creo que no sería problema conocer el estado a recrear, pero es dependiente de la forma en que la aventura usa los gráficos. Creo que se podría proporcionar una librería, para el caso más básico, basada en nuestras funciones, pero posiblemente no valdría para casos más complejos (más de un gráfico/frame, o gráficos superpuestos, etc...).

0.01 (ideas al vuelo)

Suena bien la idea. Ahora mismo el método isGraphicsEnabled() en la práctica se comporta como algo estático (o sea, en cheapAGE o en telnet/IRC se devuelve siempre false, en los clientes gráficos se devuelve siempre true, y no cambia a lo largo de la ejecución de la aventura); pero por supuesto sería lógico que al implementar una opción de "gráficos on/off" su valor pudiese cambiar, es algo que ya tenía pensado que se pudiera hacer (por eso lo implementé como un método y no con una constante o similar). En la documentación ya se recomienda llamarlo siempre que se muestra un gráfico (y no por ejemplo llamarlo una sola vez al principio de la aventura y guardar el valor), y lo mismo he recomendado yo siempre a todo el que me ha preguntado, así que en principio eso no debería ser traumático para las aventuras ya existentes si se han programado bien.

La posible dificultad que veo es que el evento que indica si el estado ha cambiado tendría que venir del hilo de la interfaz gráfica ("event dispatch thread" de Swing), mientras que todo el resto de lo que se hace en BeanShell en AGE se ejecuta en el "game engine thread". Esto no es que suponga ningún problema técnico, lo malo es que hasta ahora el programador de aventuras en AGE vive en un mundo monothread y no tiene que preocuparse nunca de asuntos de sincronización, y con este cambio tendría que salir de esa burbuja. Por ejemplo, tendría que tener cuidado al acceder a objetos del mundo desde ese evento, porque también puede acceder a ellos el "game engine thread". El mundo monothread siempre es mucho más cómodo y feliz que el fiero y hostil mundo multithread, y no quiero que el programador de aventuras en AGE tenga que meterse en el jardín de aprender threads, porque añadiría muchísima complejidad a crear aventuras (a estas alturas de la película, no las domino del todo ni yo...) Igual lo que habría que buscar es unas reglas sencillas para este caso sobre lo que no se debe hacer para evitar problemas, y ponerlas en la documentación.

Edit: probablemente esto que digo es evitable haciendo que el evento no se lance inmediatamente al cambiar la opción del menú, sino que se espere al próximo "tick" (update) del mundo. En ese caso, el evento se podría ejecutar en el "game engine thread", el thread "de siempre". El inconveniente es que entonces el efecto de cambiar la opción no sería inmediato (tendría lugar al teclear el siguiente comando). ¿Os parece que es una limitación razonable, o que es importante que la opción lance el evento al momento para que su efecto pueda ser inmediato?

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

Otra posibilidad sería que la opción predeterminada en el AGE desactivara tanto gráficos como frames (quitando también, por lo tanto, posibles frames creados para otros fines, como formar un margen, mostrar el inventario o cosas así). En vez de "activar/desactivar gráficos", podría llamarse de otra forma ("activar/desactivar gráficos y frames", etc.)

El inconveniente es que en algunas aventuras esto podría no ser adecuado o suficiente (porque queremos desactivar un frame que sea propiamente gráfico, pero no tocar otros), pero en última instancia, en ese caso el autor siempre seguiría teniendo la posibilidad de implementar la opción manualmente con un comando, independientemente de la que provea AGE.

Hay que pensar cuál de las posibilidades es más adecuada.

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