CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 25 Jun 2017 15:04

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 3 mensajes ] 
Autor Mensaje
NotaPublicado: 20 Jul 2013 15:01 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1853
Viene de viewtopic.php?p=66255#p66255

Al-Khwarizmi escribió:
La forma normal de jugar una aventura sin gráficos es mediante los clientes normales de AGE, para ello el autor de la aventura tiene que dar la opción de desactivar los gráficos. Lo que he de pensar es si dar una opción ya en el propio AGE para que el jugador pueda desactivarlos aunque el autor no proporcione la opción. El motivo por el que AGE no tiene eso ahora mismo es que no es obvio determinar qué es lo que se debe desactivar exactamente de manera que funcione en cualquier aventura (si el autor declara un frame - un marco donde se puede dibujar - ¿eso no debería ejecutarse en el modo no gráfico? ¿Y si está usando el marco para otra cosa que no sea dibujar, por ejemplo para hacer de margen o incluso para poner texto auxiliar?) Por eso (y no por ser un vago) es que por el momento pongo la pelota en el tejado del autor en estas cosas, porque el autor es el que va a saber qué aspecto debe tener su aventura con y sin gráficos, y cuáles son exactamente las cosas que no hay que ejecutar en modo sin gráficos.


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.

Código:
if ( theClient instanceof MultimediaInputOutputClient ) && theClient.isGraphicsEnabled() )


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)


Arriba
 Perfil  
 
NotaPublicado: 20 Jul 2013 17:27 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5265
Ubicación: Coruña
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)


Arriba
 Perfil  
 
NotaPublicado: 21 Jul 2013 09:17 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5265
Ubicación: Coruña
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)


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 3 mensajes ] 

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM