Соедините автономную игровую модель с пользовательским интерфейсом на основе Qt

Question

Я создал простую консольную игру Scrabble с использованием Python.Я попытался максимально инкапсулировать игровую модель из ввода-вывода, то есть создал несколько классов, чтобы описать игру с ее правилами и текущим состоянием.В основном я придумал эти классы:

• LetterSet: для описания фишек в игре (счет, общее количество и т. Д.)
• Board: представлениедоска с ее тайлами и вспомогательными функциями
• Player: виртуальный класс для подкласса реальных классов, таких как человек или бот, получил один метод play(), который должен возвращать ход игрока
• Game: Ну ...

Все отлично работает, используя простой линейный и синхронный поток с моим консольным приложением.

Но оказывается, что перенести эту концепцию не так простоQt.Я создал все необходимые виджеты, такие как доска для перетаскивания, общие визуальные элементы, описывающие состояние игры, и простые кнопки, такие как «Пропустить», «Продолжить», «Обмен».

Проблема в том, что я неконечно, как обработать метод play(), который может использовать созданный мною интерфейс Qt для создания правильного хода.Это не проблема для Bot, который просто ищет движение без какого-либо взаимодействия.

Моя текущая идея состоит в том, чтобы создать локальный цикл событий, как описано здесь , и ждать кнопокчтобы получить щелчок в моем play() методе, определенном в Human(Bot).Это довольно уродливо, поэтому мне интересно, есть ли лучший способ сделать это.

Я бы хотел, чтобы основная логика была такой же, например, класс Player обслуживает метод play(), который генерируетпереместить и вернуть его.Таким образом, можно создать любой тип Player, например, сетевых игроков или ботов.Этот синхронный способ сделать это не очень хорошо работает с основанным на Qt сигналом / слотом.Надеюсь, у кого-то есть хорошая идея, чтобы решить мою проблему.

Подведем итог: Как сгенерировать ход Player внутри его метода play() и вернуть его как простойmove = player.play(game) позвоните?

Редактировать: Снимок, чтобы понять, о чем я говорю: снимок http://reaktor42.de/~b52/shots/2011-06-26-235749_972x729_scrot.png

Edit2: Это довольно старо, и я успешно выполнил задание около двух лет назад.Тем не менее я подумал, что это может быть полезно для других, если я опубликую результаты через github .

Заранее спасибо, Оли

Answer 1

Что вы можете сделать в проигрывателе play Функция:

1. Включены кнопки и подключены их к слотам (по одному на действие)
2. Подождите, пока игрок не начнет двигатьсяvalidate (или любая другая причина для выхода)
3. Отключение сигналов в слот, когда ход игрока получен (или проверен)

Это один из способов, но вы должны изменить его наподходит для вашей модели игры

Answer 2

Я думаю, вы правы, что есть некоторая разница между моделью, основанной на событиях, в среде графического интерфейса пользователя и вашим первоначальным дизайном приложения.В консольном приложении вы пишете цикл обработки событий, но в приложении с графическим интерфейсом в любой из известных мне фреймворков у фреймворка есть свой собственный.

Я бы хотел, чтобы объект Player отправлял свое движение через сигналк игровому объекту.Вам нужно будет структурировать свой базовый класс Player вокруг этого дизайна.Это не должно быть так сложно сделать, так как у вас уже есть действительная логика, вы просто перемонтируете ее немного.

Обратите внимание, что ваши объекты Player на самом деле являются просто интерфейсами между игройи фактический проигрыватель, который может быть кем-то, нажимающим кнопки в пользовательском интерфейсе, или удаленным проигрывателем по сетевому соединению.Только в случае с ботом объект игрока может фактически быть игроком, и даже в этом случае вам лучше всего иметь отдельные объекты движка стратегии.Думая об этом таким образом, вы можете получить контроль над дизайном.

Вам не нужно делать это таким образом.Вы можете обойти это, например, описанным вами методом, но я бы не хотел возиться с моими собственными циклами событий внутри приложения, которое имеет собственный цикл событий GUI.Это борьба против структуры GUI, а не работа с ней.Это не просто Qt, у вас будет проблема, похожая на эту в любой среде графического интерфейса.Это другой способ думать о структурировании приложения, и я бы порекомендовал принять его.

Answer 3

Моя текущая идея - создать локальный цикл событий, как описано здесь, и ждать нажатия кнопок в моем методе play (), определенном в Human (Bot). Это некрасиво, поэтому мне интересно, есть ли лучший способ сделать это.

Я не понимаю, почему вы думаете, что это ужасно. Вот как работает практически любая программа с графическим интерфейсом: инициализируйте набор элементов управления (кнопки и т. Д.), Дождитесь, пока пользователь будет взаимодействовать с элементами управления, откликнитесь на взаимодействие и повторите.

Я бы порекомендовал вам кнопку, чтобы игрок мог отправить свой ход. Они нажимают на это, событие запускается, обработчик события сообщает вашему Player объекту, что был сделан ход, и передает его обработчику события логики игры. Логика игры проверяет, является ли ход допустимым (вы должны поместить код здесь, а не в классах GUI), и передает управление следующему объекту Player, если ход был законным.