Connect autonomous game model with Qt based UI

I've created a simple console based Scrabble game using Python. I tried to encapsulate the game model from the I/O as much as possible, meaning I created a few classes to describe the game with its rules and the current state. Basically I came up with these classes:

• LetterSet: To describe the tiles in the game (score, total amount, etc.)
• Board: A representation of the Board with its tiles and auxiliry functions
• Player: A virtual class to subclass real Classes like Human or Bot, got one method play() which should return the players move
• Game: Well ...

Everything works fine using a simple linear and synchronous flow with my console app.

But it turns out that its not that easy to port this concept to Qt. I've created all neccessary widgets like a Dragable 开发者_Python百科board, general visual elements describing the game state and simple buttons like 'Pass', 'Continue', 'Exchange'.

The problem is, that I'm not sure how to handle the play() method which may use the Qt interface I created to generate a valid move. That's no problem for the Bot though, which simply searches a move without any interaction.

My current idea is to create a local event loop like described here and to wait for the buttons to get clicked in my play() method defined in Human(Bot). This is kinda ugly so I'm wondering if there is a better way to do it.

I would like the main logic to be the same e.g. the Player class serves a play() method which generates a move and returns it. This way it should be possible to create any type of Player's, like network players or bots. This synchronous way of doing it doesn't work very well with Qt's based signal/slot way of doing things. Hope someone got a neat idea to solve my problem.

Summarized: How to generate the Player's move inside its play() method and returning it like a simple move = player.play(game) call?

Edit: A snapshot to get an idea of what I'm talking about:

_{(source: b52 at reaktor42.de)}

Edit2: This is rather old and I completed the assignment about two years ago successfully. Nevertheless I thought it might be useful for others if I publish the results through github.

Thanks in advance, Oli

What you can do in the Player play function is:

1. Enabled the buttons and connect them to slots (one per action)
2. Wait until the player move is validate (or any other reason to quit)
3. Disconnect signals to slot when the player move has been received (or is validated)

This is one way but you should modify it to fit your game model

My current idea is to create a local event loop like described here and to wait for the buttons to get clicked in my play() method defined in Human(Bot). This is kinda ugly so I'm wondering if there is a better way to do it.

I don't see why you think this is ugly. This is how practically any GUI program works: initialise a set of controls (buttons, etc), wait for the user to interact with the controls, respond to the interaction, and repeat.

I'd recommend you have a button for the player to submit their move. They click that, an event fires, the event handler tells your Player object that a move has been made and it passes it to the game logic event handler. The game logic checks whether the move is legal (you should put the code here rather than in the GUI classes), and passes control to the next Player object if the move was legal.

I think you're right that there's a bit of a disconnect between the event based model in a GUI environment and your original application design. With a console app you write the event loop, but in a GUI app in any of the frameworks I know, the framework has one of it's own.

I'd have the Player object send it's move via a signal to the game object. You would need to structure your base Player class around this design. It shouldn't all that hard to do as you've already got the actual logic worked out, you're just re-wiring it a bit.

Note that your Player objects are actually just interfaces between the game and the actual player which might be someone clicking buttons in the UI, or a remote player over a network connection. Only in the case of a bot can the player object actually be the player, and even in that case you might be best off having separate strategy engine objects. Thinking about it that way might help get a grip on the design.

You don't have to do it that way. You can work around it e.g. by the method you describe, but I wouldn't want to mess around with my own event loops inside an application that has it's own GUI event loop. That's fighting against the GUI framework rather than working with it. It's not just Qt that's like this, you'd have an issue similar to this in any GUI framework. It's a different way to think about structuring an application and I'd recommend embracing it.