Es un problema de threads y de cómo es la relación entre la interfaz gráfica y el modelo de mundo en AGE.
El tema es que tú estás capturando un evento de ratón, que como todos los eventos, se capturan de forma instantánea en el "event dispatching thread" de Swing. Por otra parte, las cosas que suceden en el mundo (como el hecho de que un jugador se mueva, coja un objeto, etc.) están vinculadas al thread del juego, el "game engine thread", y el mundo sólo se mueve si ese hilo itera, simulando una unidad de tiempo del juego. ¿Y cuándo itera ese hilo? Pues depende, en modo tiempo real una vez cada X tiempo, en modo síncrono cuando un jugador teclea una orden.
El método forceCommand lo que hace es que en la siguiente unidad de tiempo que se simule, se ejecute la orden dada. El problema es que, suponiendo modo síncrono ("turnos"), esa unidad de tiempo no se simula. El thread del juego está parado en una llamada bloqueante esperando por una entrada (por si le quieres echar un ojo, esto es concretamente en obtainCommandFromClient(), en Player.java, líneas 341 y siguientes, que a su vez llama -en el caso del cliente gráfico- a getInput(), en ColoredSwingClient.java, líneas 1420 y siguientes, con un wait en 1432); y hasta que no salga de esa llamada bloqueante no va a interpretar que ha recibido algo.
Vamos, en resumen: AGE tiene un bucle de entrada/salida, en el que se van esperando entradas del jugador, recibiendo, y procesando; y si de golpe tú metes una entrada de la nada porque alguien pulsó el ratón, entras como un elefante en una cacharrería en ese bucle
En concreto, entras en un momento en que AGE está esperando por una entrada, que espera que le llegue de otra manera, y por mucho que le metas un forceCommand(), pues sigue esperando.
¿Hay forma de entrar "bien" y conseguir que te reciba la entrada de inmediato? Sí, por supuesto, sería cosa de hacer lo mismo que hace el cliente cuando el jugador pulsa "enter" tras teclear un comando, que viene a ser lo que hay en SwingEditBoxListener.java, método actionPerformed(), que a su vez llama (en la línea 92) al método setInputString() del cliente (ColoredSwingClient.java, 1534) que hace un notify(). El notify() al cliente es lo que hace que se despierte de la espera y diga "hey, me han pasado un dato, vamos a procesarlo".
Así pues, a grosso modo, lo que tienes que hacer es mandarle un notify() al cliente para que se despierte. Yo creo que con eso,
más o menos, puede funcionar. Pero ojo, que estas cosas de threads son sutiles:
- Tienes que considerar qué va a pasar, y qué quieres que pase, si cuando mandas el notify() el thread NO está en espera (por ejemplo, porque el usuario clickea dos veces muy seguidas y aún no ha dado tiempo a procesar la simulación cuando ya le estás mandando otra orden).
- Esto es para modo "turnos". AGE tiene otro comportamiento distinto si el modo es tiempo real, donde la llamada no es bloqueante y no hay espera. Así que necesitarás algún if para considerar eso.
- Aparte al "puentear" todo el sistema de entrada, estarías "puenteando" cosas como el historial de comandos (que al darle hacia arriba te vayan saliendo las órdenes anteriores), o el sistema de "waitKeyPress" que también interactúa con esos hilos.
- Es muy posible que haya alguna otra sutileza que se me pase a ojo.
Vamos, que me temo que no es sencillo, porque el tema de interfaces gráficos en Java (que al fin y al cabo es lo que estás haciendo si capturas eventos de ratón) es bastante complejo. Yo lo que he hecho con AGE es que un autor de aventuras pueda hacer modelos de mundo tan complejos como quiera sin necesitar pelearse con todas estas cosas, ni saber que existen threads, eventos, llamadas bloqueantes, sincronización, etc. Pero claro, si trabajas contra la propia interfaz añadiéndole eventos... pues ahí ya te sales del entorno y si bien puedes hacer de todo porque cuentas con todas las APIs de interfaces gráficos de Java a tu disposición, también tienes que pelearte con la complejidad de todo eso.
Identificarse
Registrarse
FAQ
Buscar
