Modelo de juego autónomo Connect con interfaz de usuario basada en Qt

Question

He creado un juego de Scrabble basado en consola simple usando Python. Traté de encapsular el modelo de juego de la E/S tanto como sea posible, lo que significa que creé algunas clases para describir el juego con sus reglas y el estado actual. Básicamente me ocurrió con estas clases:

• LetterSet: Describir las fichas en el juego (puntuación, cantidad total, etc.)
Board
• : Una representación de la Junta con sus azulejos y funciones auxiliry
• Player: una clase virtual para subclase clases reales como ser humano o Bot, tiene un método play() que debe devolver a los jugadores moverse
• Game: Bueno ...

Todo funciona bien con un simple flujo lineal y síncrono con mi aplicación de consola.

Pero resulta que no es tan fácil trasladar este concepto a Qt. He creado todos los widgets necesarios, como un tablero dragable, elementos visuales generales que describen el estado del juego y botones simples como 'Pase', 'Continuar', 'Intercambio'.

El problema es que no estoy seguro de cómo manejar el método play() que puede usar la interfaz Qt que creé para generar un movimiento válido. Eso no es problema para el Bot, que simplemente busca un movimiento sin ninguna interacción.

Mi idea actual es crear un bucle de eventos locales como se describe here y esperar a que los botones para se hace clic en mi método definido en play()Human(Bot). Esto es algo feo, así que me pregunto si hay una mejor manera de hacerlo.

Me gustaría que la lógica principal sea la misma, p. la clase Player sirve un método play() que genera un movimiento y lo devuelve. De esta forma, debería ser posible crear cualquier tipo de Player, como reproductores de red o bots. Esta forma síncrona de hacerlo no funciona muy bien con la forma de hacer señas basada en la señal/ranura de Qt. Espero que alguien haya tenido una buena idea para resolver mi problema.

resumirse así:cómo generar movimiento del Player 's dentro de su método play() y devolverla como un simple move = player.play(game) llamada?

Editar: Una instantánea para tener una idea de lo que estoy hablando: snapshot http://reaktor42.de/~b52/shots/2011-06-26-235749_972x729_scrot.png

Edit2: Esto es bastante antiguo y yo completado la tarea hace unos dos años con éxito. Sin embargo, pensé que podría ser útil para otros si publico el results through github.

Gracias de antemano, Oli

Answer 1

Lo que puede hacer en la función del jugador play es:

1. permitió a los botones y conectarlos a las ranuras (una por acción)
2. Espere hasta que el movimiento del jugador es validar (o cualquier otra razón para dejar de fumar)
3. señales de desconexión a la ranura cuando se ha recibido el jugador mover (o está validado)

Ésta es una manera, pero debe modificar para que se ajuste a su modelo de juego

Answer 2

Mi idea actual es crear un bucle de eventos locales como se describe aquí y esperar a que los botones para se hace clic en el método() definido en Humano (Bot) mi juego. Esto es algo feo, así que me pregunto si hay una mejor manera de hacerlo.

No veo por qué piensas que esto es feo. Así es como funciona prácticamente cualquier programa de GUI: inicia un conjunto de controles (botones, etc.), espera a que el usuario interactúe con los controles, responda a la interacción y repita.

Te recomiendo que tengas un botón para que el jugador pueda enviar su jugada. Hacen clic en eso, se desencadena un evento, el controlador de eventos le dice a su objeto Player que se ha realizado un movimiento y lo pasa al controlador de eventos de la lógica del juego. La lógica del juego verifica si el movimiento es legal (debe colocar el código aquí en lugar de en las clases de GUI), y pasa el control al siguiente objeto Player si el movimiento fue legal.

Answer 3

Creo que tiene razón en que hay una cierta desconexión entre el modelo basado en eventos en un entorno de GUI y el diseño de la aplicación original. Con una aplicación de consola escribes el ciclo de eventos, pero en una aplicación GUI en cualquiera de los marcos que conozco, el framework tiene uno propio.

Haría que el objeto Player envíe su movimiento a través de una señal al objeto del juego. Necesitarás estructurar tu clase base de jugador alrededor de este diseño. No debería ser tan difícil de hacer ya que ya tienes la lógica real resuelta, solo estás volviendo a cablearla un poco.

Tenga en cuenta que sus objetos Player son en realidad solo interfaces entre el juego y el jugador real que podría ser alguien haciendo clic en los botones en la interfaz de usuario, o un jugador remoto a través de una conexión de red. Solo en el caso de un robot, el jugador puede realmente ser ser el jugador, e incluso en ese caso es posible que sea mejor tener objetos separados del motor de estrategia. Pensarlo de esa manera podría ayudar a controlar el diseño.

No tiene que hacerlo de esa manera. Puede solucionarlo, p. por el método que describes, pero no me gustaría perder el tiempo con mis propios bucles de eventos dentro de una aplicación que tiene su propio bucle de eventos GUI. Eso es luchar contra el marco de GUI en lugar de trabajar con él. No es solo Qt que es así, tendrías un problema similar a este en cualquier marco de GUI. Es una manera diferente de pensar en estructurar una aplicación y recomendaría abrazarla.