Метка: udp

Дурак по сети на Python: часть 4 – GUI

Кажется, что прошла вечность, но я все-таки довел до ума код игры в Дурака по сети, добавив в него поддержку GUI. В этой статье я затрону основные моменты, которые мне показались интересны во время разработки или вызвали некоторые трудности, дабы дать ответ, как эти трудности преодолеть. Короче, получился мини-гайд траблшутинга для Kivy.

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

Кстати, весь код по-прежнему находится в репозитории на Github.

Библиотека для GUI

Для графического интерфейса я выбрал библиотеку Kivy. Сейчас она модна и активно развивается. Меня подкупила прежде всего возможность легко собрать приложения под мобильные устройства, включая Андроид, что я и осуществил в итоге. Установка проста до безобразия.

pip isntall Kivy==1.11.1

Но! С этим вы сможете запускать приложение только на компьютере. Чтобы собрать и запустить на телефоне потребуется еще несколько действий и минут ожидания. Но об этом в конце статьи.

Структура проекта

Структура папок и файлов проекта
Файлы проекта

Начнем со структуры файлов исходного кода. Точка входа значится в файле main.py. Кстати, если его назвать иначе, то можете столкнуться с проблемами сборки под мобилки, лучше назовите его именно так.

main.py подключает модуль net_game.py, где описана сетевая модель игры (класс DurakNetGame). Этот класс обеспечивает сетевое взаимодействие двух клиентов во время игры, также различает, чей сейчас ход, какой клиент победил и тому подобное. Короче, сопоставляет сетевые сущности игровым. А еще он делает проверки на допустимость тех или иных действий. Например, отбивающийся игрок не может сказать «Бито!», так и атакующий не может призвать взять карты, пока другой сам не примет это решение. Класс использует для хранения и обработки игрового состояния другой класс: DurakSerialized из serialization.py.

DurakSerialized в свою очередь наследован от класса Durak, добавив к нему слой функциональности по сохранению игрового состояния в формат JSON и по обратной загрузке в полей класса из JSON строки.

Durak из durak.py занимается исключительно игровой логикой и хранением состояния игры, беспристрастно относительно того, какого именно из клиентов сейчас ход. В нем просто есть понятия «атакующий игрок» и «отбивающийся игрок». Этот класс содержит правила, по которым карты раздаются игрокам, кладутся на стол, бьют друг друга и тому подобное. Он определяет методы атаки, защиты и завершения хода (бито или взял карты, если не побил). В этом класс много полезных свойств для анализа игровой ситуации.

discovery_protocol.py был описан ранее, он занимается поиском соперников по UDP в локальной сети. Он пользуется Networking из network.py – оберткой над сокетами, как впрочем и DurakNetGame также использует пару Networking (пара портов – вынужденная мера для сетевого взаимодействия двух клиентов на одной машине).

durak.kv – разметка виджетов для GUI в Kivy в формате, похожим на YAML. Описывает разные элементы игры, такие как параметры карт, размер шрифта, фон. Он НЕ определяет взаиморасположение элементов на экране, так как все это определяется программно системой анимации, как которую сделать средствами kv-файла, я даже отдаленно не могу вообразить. Зато я придумал супер-простую и эффективную систему для произвольных плавных анимаций, которая и контроллирует положение карт и их вращение. Эта система в файле gui/animation.py.

Файл gui/game_layout.py как раз содержит целевые положения и повороты для всех элементов игры, а именно положения карт в руках игрока и соперника, положение карт на столе, колоду и козырь. Еще он обеспечивает некоторые много-этапные анимации, такие как раздача нескольких карт подряд или разлет карт в стороны в конце матча.

В gui/card.py лежит класс Card, описывающий виджет игральной карты и ее свойства. А в классе, gui/gm_label.py – класс для информационных надписей и ошибок.

main.kv

Файл типа «kv» похож по формату на YAML, но отличается от него в деталях. Он содержит разметку для GUI проекта и определяет свойства графических элементов. Он даже может содержать кусочки Python-кода для обработчиков событий и условного форматирования. Первым делом, мы указываем версию Kivy, для которой написан файл. Также мы можем импортировать нужные символы из основного Python-кода. Все это делается через комментарии:

#:kivy 1.11.1
#:import SPADES durak.SPADES
#:import HEARTS durak.HEARTS
#:import DIAMS durak.DIAMS
#:import CLUBS durak.CLUBS

На верхнем уровне у меня идут описания классов для виджетов, они представляют собой имена классов в треугольных скобках. Соответсвенно, каждый виджет-экземпляр будет иметь свойства, описанные для него в kv-файле после его загрузки. Если название идет без <>, то это значит непосредственное создание виджета, как дочернего элемента.

Например, класс MainLayout (главная наша раскладка игры), наследован от FloatLayout (раскладка, на которой положения всех элементов свободны и задаются программистом, на не вычисляются движком, как в других раскладках). На любом из созданных MainLayout будет создан виджет GameMessageLabel как дочерний элемент. А еще там будет GameButton и так далее.

<MainLayout@FloatLayout>:
  GameMessageLabel:
    id: game_label
    pos: 0, self.width * 0.26
  GameButton:
    text: 'Бито!'
    id: finish_turn_button
    pos_hint: {"center_x":0.33,"center_y":0.32}
    on_press: app.on_finish_button()

А вот и первый код в свойстве on_press: вызывается app.on_finish_button() при нажатии на кнопку. Переменная app автоматически соответствует экземпляру класса приложения DurakFloatApp. Еще есть полезные заранее связанные переменные: self здесь отвечала бы за доступ к этому экземпляру GameButton, а root – к корневому классу описания – MainLayout.

Взглянем на описание класса виджета карты – Card.

<Card>:
  font_name: 'resources/Arial.ttf'
  halign: 'center'
  font_size: '32dp'
  width: '64dp'
  height: '120dp'
  size_hint: None, None

Размер карт я указал в абсолютных величинах. Он зависит только от разрешения экрана (dp = density pixel). Также мне потребовалось скачать и положить в папку ресурсов обыкновенный шрифт Arial, потому что встроенный шрифт даже на последней версии Андроид не поддерживал значки игральных карт ♠♥♣♦ (вот сюрприз в 2020 году!)

Не забывайте снабжать проект всеми нужными шрифтами, особенно если используете редкие символы!

Мне хотелось, чтобы карты имели красивые закругленные углы, поэтому я нашел в одном из старых проектов текстуру с закругленными углами и тенями, добавил ее в проект. Однако, он по размеру не подходил под задуманный размер карты. Поэтому здесь мы применим технику 9-патч, то есть 2 горизонтальными и 2 вертикальными линиями текстура режется на 9 частей, уголки и края остаются без изменений, а белая серединка растягивается до нужных размеров, чтобы с целиком спрайт был величиной как раз с игральную карту.

9-патч для карт
9-patch нарезка.

В Kivy эта техника уже встроена и включается очень просто через параметр border, что содержит кортеж с отступами (порядок их не помню, здесь у нас с каждого края до линии разреза отступы равные – 24 пикселя).

  background_normal: 'resources/rounded_corners.png'
  background_down: 'resources/rounded_corners.png'
  border: (24, 24, 24, 24)

Вот еще пример кода в kv-файле: условный дизайн. Меняю цвет карты, если она выделена (при выборе карты на столе, чтобы покрыть). И меняю прозрачность, если она в состоянии нажатия мышью или пальцем. Каждый раз, когда root.selected меняется, выражение для root.selected будет пересчитано.

  background_color: (1, 1, 1, 1) if not root.selected else (0.9, 0.9, 0.9, 1)
  opacity: 1 if root.state == 'normal' else .8

Внимание! Здесь переменная root уже относится к классу Card, а не к MainLayout.

С поворотом игральной карты оказалось немного интереснее. Оказывается, в Kivy нет свойства с названием rotation, поэтому пришлось колхозить его через матрицы. Перед отрисовкой (блок canvas.before) мы сохраняем старую матрицу в стек, домножаем ее на матрицу поворота, рисуем объект и после (в блоке canvas.after:) восстанавливаем прежнюю матрицу из стека. Вот так это делается:

 canvas.before:
    PushMatrix
    Rotate:
      angle: self.rotation
      origin: self.center
  canvas.after:
    PopMatrix

Еще откровением для меня стал тот факт, что параметры pos_hint и size_hint задаются в долях от единицы (0.2 – это 20% полной ширины, например). А width, height и pos – уже в абсолютных единицах, например, пикселях.

По разметке все, теперь к основному коду.

Конфигурация окна

Вы могли бы заменить в самом верху main.py код вида:

from kivy.config import Config
from util import debug_start

debug_start()

Config.set('graphics', 'width', '480')
Config.set('graphics', 'height', '640')
Config.set('graphics', 'resizable', False)

Здесь мы указываем примерные размеры окна, чтобы на компьютере игра тоже открывалась в портретной ориентации, как и на телефоне, где, понятное дело, размер окна приложения задан размером экрана. А еще мы запрещаем изменять размер окна.

Функция debug_start():

def debug_start():
    import os
    from kivy.config import Config

    x = os.environ.get('x', 50)
    y = os.environ.get('y', 50)

    Config.set('graphics', 'position', 'custom')
    Config.set('graphics', 'left', x)
    Config.set('graphics', 'top', y)

Она задает положение окна при запуске на компьютере и нужна только для отладки. Положение окна читается из переменных среды. Дело в том, что у меня есть скрипт run_two.sh, который запускает сразу два экземпляра игры на одном компьютере (игра то многопользовательская!) и располагает их бок о бок:

#!/usr/bin/env sh
x=50 python main.py &
x=550 python main.py,
Бок о бок два клиента
Бок о бок два клиента

Удобно тестировать и отлаживать проект таким образом!

Загрузка

Вообще в Kivy kv-файл должен загружаться автоматически. Фреймворк ищет файл в папке проекта с названием, совпадающим с именем класса приложения и загружает его. Однако, я столкнулся с проблемой, что на Andorid этого не происходит! Я убедился, что файл добавляется в APK, но Kivy не может его найти и загрузить. Долго бился на этой проблемой, но не найдя решения в интернете, решил пойти в лоб и загрузить kv-файл вручную во время исполнения метода build. Еще прошлось для этого создать пустой класс для MainLayout, так как метод должен вернуть сконструированный корневой виджет приложения.

class MainLayout(FloatLayout):
    ...

class DurakFloatApp(App):  
  def build(self):
        Builder.load_file('durak.kv')
        return MainLayout()

Kivy и многопоточность

Глюки многопоточности

Обработка GUI занимает все рабочее время основного потока игры, и этот поток нельзя блокировать, так как интерфейс тоже заморозится. Поэтому, чтобы ожидать сообщений из сети я создаю отдельный поток. Решение с потоками – не единственное, и вероятно, не самое элегантное, но достаточно простое для реализации и понимания. Однако, и здесь мне встретились подводные камни. При получении пакета из сети сетевая подсистема должна вызвать некоторые изменения в GUI. Поначалу я просто вызывал методы Kivy из дополнительного сетевого потока, что привело к регулярным графическим глюкам, которые вы можете видеть на скриншоте.

Все изменения в графическом интерфейсе должны делаться из главного потока.

Да, и это не смотря даже на GIL! Дело в том, что контекст графической библиотеки OpenGL издревле очень не любит, когда его трогают из чужого потока; это приводит к случайным и иногда сложно-уловимым визуальным глюкам.

Как это исправить? Воспользоваться декоратором mainthread, который поставит при вызове оригинальной функции поставит ее выполнение в следующий тик главного цикла приложения в главном потоке. 

В итоге я просто снабдил этим декоратором все методы, которые могут быть вызваны из чужого потока, и глюки полностью испарились. Вот пример – DiscoveryProtocol в отдельном потоке ищет соперника, а когда находит – вызывает событие on_found_peer, которое должно начать матч и раздать карты.

from kivy.clock import mainthread

class DurakFloatApp(App):
 ...
   @mainthread  # <--- (!)
    def on_found_peer(self, addr, peer_id):
        print(f'Найден соперник {peer_id}@{addr}')
        # делать что-то с GUI!
    ...
    self.discovery = DiscoveryProtocol(self.my_pid, PORT_NO)
    self.discovery.run_in_background(self.on_found_peer)

class DiscoveryProtocol:
    def run_in_background(self, callback: callable):
        def await_with_callback():
            results = self.run()
            callback(*results)
        threading.Thread(target=await_with_callback, daemon=True).start()

Система анимации

Разработку интерфейса я начал со стандартных раскладок, используя BoxLayout, StackLayout и подобные инструменты. Вид игры выходил скучно и топорно, как вы можете заменить на скриншоте из предыдущего поста. На мои вопросы не находилось никаких ответов. Об анимациях даже не приходилось и думать в таком положении вещей, ибо Layout берут на себя контроль над положением и размером виджетов. Вот так выглядела игра в первой редакции:

Плохой дизайн игры.
Не привлекательно. Правда ведь?

Как давнего игродела, меня это совершенно не устраивало, и я решил радикально все переделать. Все игровые объекты будут располагаться на FloatLayout, который дает программисту полный контроль над положением и размерами виджетов. Далее я начертил на бумаге чертеж, где вычислил координаты каждой карты на экране. Например, карты текущего игрока располагаются на дуге окружности радиусом в 0.9 от ширины экрана и центром ниже нижней кромки экрана. Угловые границы дуги: от -30º до 30º относительно вертикали. Также, добавил вращение карт путем матричных преобразований, дабы карты выстраивались в традиционный веер.

Очень действенный прием, на самом деле. Если сходу не получается написать геометрический код, начертите все на бумаге и прилежно выведите все формулы, а потом дословно перенесите их в код – с первого раза заработает, как следует.

Чертеж на бумаге

Далее каждый виджет карты я наделил атрибутами target_position и target_rotation – это позиция и угол поворота, куда стремиться карта со временем. Задал такой периодический интервал обновления:

Clock.schedule_interval(self.update, 1.0 / 60.0)

Условно каждый кадр (1/60 долю секунды), реальное положение pos карты становится чуть ближе к ее целевому положению target_position. Аналогично с поворотом. Движение получается экспоненциально затухающим: чем ближе карта к цели, тем она медленнее к ней движется, поэтому анимации получились вполне естественные и приятные.

Код, отвечающий за анимации:

EXP_ATT = 5.0  # регулирует скорость

def update(self, dt):
    df = self.EXP_ATT * dt
    for child in self.root.children:
        if hasattr(child, 'target_position'):
            x, y = child.pos
            # компенсируем положение точки, смещая ее из нижнего левого угла в середину виджета
            x += child.size[0] / 2
            y += child.size[1] / 2
            tx, ty = child.target_position
            if fast_dist(x, y, tx, ty) >= 0.1:
                x += (tx - x) * df
                y += (ty - y) * df
                # возвращаем обратно из середины точку к углу
                child.pos = (x - child.size[0] / 2, y - child.size[1] / 2)
        if hasattr(child, 'target_rotation'):
            tr, r = child.target_rotation, child.rotation
            if abs(tr - r) >= 0.1:
                child.rotation += (tr - r) * df

Видео анимаций:

Все целевые положения карт определяются методами в gui/game_layout.py. К примеру, карты в руке расположены по дуге (веером). Положение карты и ее поворот зависят от количества карт в руке и номера карты, считая с 0 слева направо.

class GameLayout:
    def pos_of_hand(self, i, n, is_my):
        r = 0.9 * self.width
        cx = self.width * 0.5
        cy = -0.8 * r if is_my else self.height + 0.8 * r

        d_ang = 10
        max_ang = min(30, d_ang * n / 2)
        min_ang = -max_ang

        ang = min_ang + (max_ang - min_ang) / (n + 1) * (i + 1)
        ang_r = ang / 180 * pi
        m = 1 if is_my else -1
        return cx + r * sin(ang_r), cy + m * r * cos(ang_r), -m * ang

Использование:

    def update_cards_in_hand(self, is_my, real_cards):
        """ Сортирует карты в руке игрока или соперника сообразно порядку в игре
        После сортировки устанавливаются для каждой карты ее позиция и поворот"""
        # реальный порядок карт в руке задается внутри класса Durak, нам при сортировке карт в руке нужно его соблюсти
        n = len(real_cards)
        for i, card in enumerate(real_cards):
            wcard = self.card2widget.get(card, None)
            if wcard:
                wcard.bring_to_front()  # чтобы каждая следующая была поверх предыдущей
                wcard.set_animated_targets(*self.pos_of_hand(i, n, is_my))

class Card:
    ...
    def set_animated_targets(self, x, y, ang):
        self.target_position = x, y
        self.target_rotation = ang

    def bring_to_front(self):
        parent = self.parent
        parent.remove_widget(self)
        parent.add_widget(self)

Метод bring_to_front переносит виджет карты на передний план, удаляя ее от родителя и вновь добавляя ее поверх прочих виджетов. Методов для управление z-order (порядком отрисовки) виджетов в Kivy я не нашел, пришлось изобретать из синей изоленты…

Текст на картах

Еще один затык произошел к текстом на карте. Я то думал, что текст на метке (Label) должен обновляться реактивно при изменении параметров, если такое поведение задано в kv-файле. Например, если карта открывается, то знак вопроса должен превратиться в масть и достоинство карты. Но этого не происходит автоматически, хотя вот для цвета кнопок это работает нормально. Поэтому в итоге пришлось создать метод, обновляющий текст на карте и привязать его события обновления (self.bind) некоторых переменных. Вдруг кому пригодится такое знание. Код:

class Card(Button):
    nominal = StringProperty()
    suit = StringProperty()
    opened = BooleanProperty(True)
    selected = BooleanProperty(False)
    counter = NumericProperty(-1)

    def update_text(self, *_):
        if self.counter >= 0:
            self.text = str(int(self.counter))
            self.color = (0, 0, 0, 1)
        elif not self.opened:
            self.text = '?'
            self.color = (0, 0.5, 0, 1)
        else:
            s, n = self.suit, self.nominal
            self.text = f'{s}{n}\n\n{n}{s}'
            self.color = (0.8, 0, 0, 1) if self.suit in (DIAMS, HEARTS) else (0, 0, 0, 1)

    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.bind(counter=self.update_text)  # <-- Привязка здесь
        self.bind(opened=self.update_text)

Обновление игрового состояния

Когда один из игроков совершает действие (например, ходит картой), он должен уведомить другого по сети. Изначально я планировал посылать целиком состояние игры, но тогда бы возникла необходимость сравнивать прошлое и новое состояния и на основе их различий перемещать карты. Это не очень тривиально для реализации и отладки. Почему бы просто не снабжать игровое состояние напрямую информацией о том, что изменилось? Так и сделал, модифицировав durak.py. При каждом действии добавляю его описание словарем в last_update:

# при атаке кодируем изменение: 
self.last_update = {
            'action': UpdateAction.ATTACK,
            'card': card,
            'player': self.attacker_index
        }

Декодирование self.game.state.last_update на принимающем клиенте в файле main.py (код сокращен):

@mainthread
    def on_game_state_update(self, *_):
        ...
            up = self.game.state.last_update
            action = up.get('action')
            if action == UpdateAction.ATTACK:
                card = up['card']
                self.layout.put_card_to_field(card)
            elif action == UpdateAction.DEFEND:
                att_card = up['attacking_card']
                def_card = up['defending_card']
                self.layout.put_card_to_field(def_card, att_card)
            elif action == UpdateAction.FINISH_TURN:
                ...
            self.update_hands()
            self.toggle_buttons()
            self.display_whose_turn(delay=0)

Сборка на Андроид

Вам потребуется дополнительная подготовка. Надеюсь, у вас Linux или macOS? Можно ли собрать из-под Windows, я не знаю. Еще недавно было нельзя. По крайней мере вы можете просто установить виртуальную машину с образом Linux, например, Ubuntu и продолжить сборку с виртуалки.

Для сборки нам потребуется buildozer.

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

wget https://github.com/HeaTTheatR/KivyMD-data/raw/master/install-kivy-buildozer-dependencies.sh

chmod +x install-kivy-buildozer-dependencies.sh

./install-kivy-buildozer-dependencies.sh

Если что-то не получается, загляните сюда, возможно, каких-то еще вещей не хватает и придется их доустановить.

Настройки Бульдозер для сборки игры я уже произвел. Они лежат в файле buildozer.spec. Основные настройки, которые я изменил:

  • Название игры: title = Durak UDP
  • Положение файлов, там же, где и этот файл: source.dir = .
  • Имя пакета: package.name = durak_kivy_lan
  • Префикс пакета: package.domain = ru.tirinox
  • Расширения файлов, включаемых в пакет: source.include_exts = py,png,jpg,kv,atlas,ttf
  • Ориентация – портретная: orientation = portrait
  • Полный экран: fullscreen = 1
  • Обязательно! Разрешение на доступ к сети: android.permissions = INTERNET

Подключите устройство по USB к компьютеру. Включите режим для разработчиков. В меню настроек разработчика включите режим отладки по USB. Когда, телефон спросит подтвердить, доверяете ли вы этому компьютеру, согласитесь. Иногда это окно не выходит, если вы при подключении кабеля выбрали «Только Зарядка», правильный выбор – «Передача файлов».

Теперь выполните из папки проекта команду:

 buildozer android debug deploy run

Она соберет проект и запустит его на подключенном смартфоне!

Дурак уже на телефоне

Вот так это выглядит у меня.

Заключение

На этом, пожалуй, все. Наверное, нет смысла разбирать весь остальной код по косточкам, он не особо интересен.

В итоге Kivy показался мне достаточно интересным и удобным фреймворком, но в нем очень много неясных моментов. Имеется довольно скудная документация и недостаточность примеров. Поэтому подобными статьями попытаюсь чуть-чуть улучшить ситуацию, решая проблемы при создании реальных приложений. Разработчикам Kivy и для Kivy – респект и удачи на вашем пути!

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

Спасибо за чтение! Буду рад вашим звездочкам на Github.

Предыдущие части:

Специально для канала @pyway. Подписывайтесь на мой канал в Телеграм @pyway  

Дурак по сети на Python: часть 3 – игра

В части 2 я привел способ обнаружения соперника в локальной сети. Как только двое игроков нашли друг друга, они могут начать игру, обмениваясь UDP пакетами напрямую, т.е. посылая их непосредственно по IP адресу и нужному порту.

Да, номера портов вы выбираете сами. Старайтесь выбирать порты так, чтобы они не перекрывались с существующими сервисами (список популярных портов). Порты 0-1023 системные, их вы не займете просто так без особых прав. Берите любые порты из диапазона 1024-49151, лучше ближе к концу, так меньше вероятности конфликтов.

Если для протокола обнаружения нам нужен был только один порт 37020, то для обмена сообщениями между клиентами я возьму 2 порта: 37020 и 37021. Почему два? Потому что мы с вами отлаживаем код обычно на одной машине. А двум программам слушать один и тот же порт на одной машине не получится, даже переиспользуя порт. Сообщения просто будут приходить только на один из клиентов во всех случаях, а второй не получит ничего. Следовательно делатем так: один клиент слушает 37020 и отправляет сообщения на 37021, а другой – наоборот слушает 37021 и отправляет сообщения на 37020. Такая схема будет работать и на одной машине, и на разных машинах.

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

Потоки данных между игроками

Итак, костяк нашей игры будет лежать в модуле main.py:

from render import ConsoleRenderer
from net_game import DurakNetGame
from discovery_protocol import DiscoveryProtocol
from util import rand_id

PORT_NO = 37020
PORT_NO_AUX = 37021

def main():
    my_pid = rand_id()  # создадим себе ID случайно

    discovery = DiscoveryProtocol(my_pid, port_no=PORT_NO)
    print('Сканирую локальную сеть...')
    (remote_addr, _port), remote_pid = discovery.run()
    del discovery

    renderer = ConsoleRenderer()
    game = DurakNetGame(renderer, my_pid, remote_pid, remote_addr, [PORT_NO, PORT_NO_AUX])
    game.start()


if __name__ == '__main__':
    main()

Класс DiscoveryProtocol был описан в части 2, а класс ConsoleRenderer аж в первой части. Мы же сейчас обратимся к классу DurakNetGame, код которого я поместил в файл net_game.py.

Класс требует ID локального игрока, а также только что найденные ID удаленного игрока и его IP адрес в сети. Еще ему нужна пара номеров портов для коммуникации.

Так как у каждого есть свой ID и это просто числа, то мы выбираем того, кто ходит первый просто сравнивая эти числа: у кого меньше, тот и первый, а другой про себя решит точно также, что он второй. Аналогично идет выбор портов. Если я первый (мой ID меньше твоего), то слушаю, допустим, порт 37020. Другой клиент также совершенно однозначно решит, слушать порт 37021, сравнив свой ID с моим и поняв, что он больше. Вот такой элементарный алгоритм консенсуса. Так инициализируется класс сетевой игры:

class DurakNetGame:
    def __init__(self, renderer: GameRenderer, my_id, remote_id, remote_addr, ports):
        self._renderer = renderer

        self._game = DurakSerialized()  # геймплей

        self._my_id = int(my_id)
        self._remote_id = int(remote_id)
        self._remote_addr = remote_addr

        # проверка на адекватность ID
        assert self._my_id != 0 and self._remote_id != 0 and self._my_id != self._remote_id

        # кто ходит первый выбираем просто сравнивая ID (они же случайные)!
        me_first = self._my_id < self._remote_id
        # мой индекс 0 если я первый, и 1 иначе. у соперника наоборот
        self._my_index = 0 if me_first else 1

        # две сетевых примочки на разны портах
        network1 = Networking(port_no=ports[0])
        network2 = Networking(port_no=ports[1])

        # кто слушает какой порт выбираем также на базе сравнения ID как чисел
        self._receiver = network1 if me_first else network2
        self._receiver.bind("")

        self._sender = network2 if me_first else network1

Запуск игры (метод start) инициализирует новую игру (если я первый ходящий), и отсылает ее другому игроку, чтобы синхронизировать их состояния.

    def _new_game(self):
        self._game = DurakSerialized()        # игрок с индексом 0 создает игру!
        self._send_game_state()        # и отсылает ее сопернику
        self._renderer.render_game(self._game, self._my_index)

Сериализация состояния игры происходит в классе DurakSerialized – наследнике класса Durak. Она очень простая, почти без ухищрений: просто собираем в словарь разные аспекты игры. Код сериализации находится в файле serialization.py. Пример состояния игры после сериализации:

{'trump': '♦', 'attacker_index': 0, 'deck': [('J', '♠'), ('10', '♦'), ('8', '♣'), ('10', '♠'), ('A', '♦'), ('6', '♣'), ('7', '♣'), ('6', '♠'), ('Q', '♥'), ('J', '♣'), ('K', '♣'), ('6', '♦'), ('9', '♣'), ('6', '♥'), ('7', '♦'), ('9', '♠'), ('A', '♣'), ('7', '♥'), ('10', '♣'), ('A', '♠'), ('J', '♦'), ('8', '♥'), ('A', '♥'), ('7', '♠')], 'winner': None, 'field': [(('8', '♠'), None), (('8', '♦'), ('Q', '♦'))], 'players': [{'index': 0, 'cards': [('9', '♥'), ('J', '♥'), ('Q', '♠'), ('Q', '♣')]}, {'index': 1, 'cards': [('9', '♦'), ('10', '♥'), ('K', '♠'), ('K', '♥'), ('K', '♦')]}]}

Возвращаясь к запуску сетевой игры, он подразумевает запуск двух вещей: потока чтения и цикла-обработчика ввода пользователя.

    def start(self):
        print(f'Мой ID #{self._my_id}, мой индекс {self._my_index}')
        print(f'Удаленный адрес {self._remote_addr}')
        self._renderer.help()

        if self._my_index == 0:
            # игрок с индексом 0 создает игру!
            self._new_game()

        self._receiver.run_reader_thread(self._on_remote_message)
        self._game_loop()

Первая часть – отдельный поток, который слушает порт на прием. На этот порт приходят сообщения от клиента соперника, содержащие закодированное состояние игры, если оно изменится в результате действий и ходов соперника. Ведь игра в дурака – синхронная: пока я отбиваюсь, ты можешь подкидывать мне еще карт того же достоинства, что уже лежат на столе. В networking.py определен метод запуска потока чтения, который вызывает стороннюю функцию-обработчик callback.

 def run_reader_thread(self, callback):
        """
        Запускает отдельный поток, чтобы получать данные из сокета
        :param callback: функция, которая вызывается, если получены данные
        """
        def reader_job():
            while True:
                data, _ = self.recv_json()
                if data:
                    callback(data)
        # daemon=True, чтобы не зависал, если выйдет основной поток
        threading.Thread(target=reader_job, daemon=True).start()

Обработка сообщений от соперника идет в DurakNetGame и включают в себя обновление состояния игры локально и его отрисовку в терминале. Соперник еще может прислать сообщение, что он покидает игру, тогда мы тоже выйдем из программы.

    def _on_remote_message(self, data):
        action = data['action']
        if action == 'state':
            self._game = DurakSerialized(data['state'])  # обновить остояние
            print('Пришел ход от соперника!')
            self._renderer.render_game(self._game, self._my_index)
        elif action == 'quit':
            print('Соперник вышел!')
            exit(0)

Вторая ключевая вещь игры – это бесконечный цикл, который читает пользовательский ввод с клавиатуры и обрабатывает его. Если я походил, отбился или еще что-то сделал, тогда я обновляю состояние игры у себя и отсылаю его копию другому игроку, чтобы тот отобразил изменения у себя на экране.

    def _game_loop(self):
        while True:
            q = input('Ваш ход (q = выход)? ')

            parts = q.lower().split(' ')
            if not parts:
                continue

            command = parts[0]

            good_move = False  # флаг, удачный ли был ход после ввода команды
            g = self._game
            try:
                if command == 'f':
                    good_move = self._handle_finish()
                elif command == 'a' and g.attacker_index == self._my_index:
                    good_move = self._handle_attack(parts)
                elif command == 'd' and g.attacker_index != self._my_index:
                    good_move = self._handle_defence(parts)
                elif command == 'q':
                    print('Вы вышли из игры!')
                    self._send_quit()
                    break
                else:
                    print('Неизвестная команда.')
            except IndexError:
                print('ОШИБКА! Неверный выбор карты')
            except ValueError:
                print('Введите число через пробел после команды')

            if good_move:
                # если ход удачный, пошлем копию состояния игры 
                self._send_game_state()
                self._renderer.render_game(g, self._my_index)

                # проверка на окончание игры (если есть победитель, в g.winner - этог индекс)
                if g.winner is not None:
                    outcome = 'Вы победили!' if g.winner == self._my_index else 'Вы проиграли!'
                    print(f'Игра окончена! {outcome}')
                    break

Как и в случае локальной игры из первой части, мы читает строку с клавиатуры, где первый символ команда, а второй через пробел – опциональный аргумент. Команды будут такие:

  • f – завершить ход (сказав «Бито!» или забрав карты, зависит от того, кто вызвал команду)
  • a 2 – атакующий ход (аргумент – номер карты, с которой ходить или подбросить)
  • d 1 – защитный ход (аргумент – номер карты, которой отбиться). Если выбор карты для покрытия неоднозначен, то спросим пользователя о том, какую именно карту следует отбить.
  • q – выход из игры, уведомив соперника, чтобы тот тоже завершил цикл и вышел из программы.
    def _game_loop(self):
        while True:
            q = input('Ваш ход (q = выход)? ')

            parts = q.lower().split(' ')
            if not parts:
                continue

            command = parts[0]

            good_move = False  # флаг, удачный ли был ход после ввода команды
            g = self._game
            try:
                if command == 'f':
                    good_move = self._handle_finish()
                elif command == 'a' and g.attacker_index == self._my_index:
                    good_move = self._handle_attack(parts)
                elif command == 'd' and g.attacker_index != self._my_index:
                    good_move = self._handle_defence(parts)
                elif command == 'q':
                    print('Вы вышли из игры!')
                    self._send_quit()
                    break
                else:
                    print('Неизвестная команда.')
            except IndexError:
                print('ОШИБКА! Неверный выбор карты')
            except ValueError:
                print('Введите число через пробел после команды')

            if good_move:
                # если ход удачный, пошлем копию состояния игры
                self._send_game_state()
                self._renderer.render_game(g, self._my_index)

                # проверка на окончание игры (если есть победитель, в g.winner - этог индекс)
                if g.winner is not None:
                    outcome = 'Вы победили!' if g.winner == self._my_index else 'Вы проиграли!'
                    print(f'Игра окончена! {outcome}')
                    break

Если в результате ввода состоялся удачный ход (по правилам игры, не было исключений), то состояние игры локально обновиться. А мы будем обязаны уведомить об этом другую сторону. Код отправки сообщений:

    def _send_game_state(self):
        self._sender.send_json({
            'action': 'state',
            'state': self._game.serialized()
        }, self._remote_addr)

    def _send_quit(self):
        self._sender.send_json({
            'action': 'quit'
        }, self._remote_addr)

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

Атака. Атаковать, как понятно, можно только в свой ход. Возвращает True, если атака успешна, иными словами, если игрок сходил с одной из правильных карт (нельзя подкинуть десятку, если на столе только, например, семерки, валеты и дамы).

    def _handle_attack(self, parts):
        g = self._game
        index = int(parts[1]) - 1
        card = g.current_player.cards[index]
        if not g.attack(card):
            print('ОШИБКА! Вы не можете ходить этой картой!')
            return False
        else:
            return True

Защита возможна только в ход соперника. Защищающийся выбирает карту, игра ищет варианты, которыми он может отбиться именно этой картой. Если вариантов несколько, будет спрошено, что он конкретно имеет в виду. Возвращает True, если успешно отбился одной картой, но это еще не значит, что ход завершен. Вот код метода:

    def _handle_defence(self, parts):
        g = self._game
        index = int(parts[1]) - 1
        new_card = g.opponent_player.cards[index]
        if g.field:
            variants = g.defend_variants(new_card)

            print(f'variants {variants} - {new_card}')
            if len(variants) == 1:
                def_index = variants[0]
            elif len(variants) >= 2:
                max_pos = len(g.field)
                def_index = int(input(f'Какую позицию отбить {new_card} (1-{max_pos})? ')) - 1
            else:
                print('Вам придется взять карты!')
                return False

            old_card = list(g.field.keys())[def_index]
            if not g.defend(old_card, new_card):
                print('ОШИБКА! Нельзя так отбиться!')
            else:
                return True
        else:
            print('Пока нечего отбивать!')
            return False

Завершение хода. Если защищающийся игрок не отбил все карты, то завершение хода вынудит его забрать со стола все карты себе в руку. Ход не переходит. Если же он успешно отбился, то завершение хода – это «Бито!», ход перейдет, а все карты со стола уйдут из игры в стопку «бито».

    def _handle_finish(self, my_turn):
        g = self._game
        if g.field:
            if my_turn and g.any_unbeaten_cards:
                print('Не можете вынудить соперника взять карты!')
                return False
            elif not my_turn and not g.any_unbeaten_cards:
                print('Только атакующий может сказать "Бито!"')
                return False
            else:
                r = g.finish_turn()
                if r == g.GAME_OVER:
                    r_str = 'игра окончена!'
                elif r == g.TOOK_CARDS:
                    r_str = 'взяли карты.'
                else:
                    r_str = 'бито.'
                print(f'Ход завершен: {r_str}')
                return True
        else:
            print('Пока ход не сделал, чтобы его завершить!')
            return False

Вот и весь код игры! Теперь можно запустить пару клиентов игры на одном или разных компьютерах и играть в дурака!

Напомню, что весь код в репозитории на Github. Ставьте звездочки, мне будет очень приятно.

Надеюсь, вам понравилось. Может быть прикрутим к игре графический интерфейс и нормальное управление?

Предыдущие части:

Специально для канала @pyway. Подписывайтесь на мой канал в Телеграм @pyway 👈 

Дурак по сети на Python: часть 2 – обнаружение

Надеюсь, вы уже ознакомились с частью 1.

Мем про TCP и UDP

В этой части мы начнем реализовывать сетевые взаимодействия. Обычно в статьях по сетевому программированию нам предлагают использовать клиент-серверную модель по протоколу TCP. Тут кроется пара неудобств. Во-первых, разделение код на клиентский и серверный. Во-вторых, необходимость клиентам узнавать адрес сервера. В масштабах локальной WiFi сети для небольших игрушек – лишняя трата времени и неудобства. Почему бы нам не позволить клиентам самим находить друг друга? Это не так сложно.

Начнем с того, что у каждой машины в сети есть свой IP адрес из четырех чисел 0-255. В локальной сети обычно (но не всегда) адреса имеют вид 192.168.1.X, где X – разный для разных устройств в сети.

Подключенные устройства в вашем роутере.
Подключенные устройства в вашем роутере.

Один из вариантов, который я нашел в сети, предлагал нам просканировать диапазон адресов 192.168.1.1 — 192.168.1.254 и попытаться подключиться к каждому из них. Это вариант меня не устроил, потому что такой брут-форс выполняется долго, да и вообще метод топорный. В моем методе не придется узнавать даже свой IP.

Будем работать по протоколу UPD, обмениваясь датаграммами (короткими сообщениями). Это простой протокол. UDP отличается от TCP тем, что не требует устанавливать соединение, однако в UDP нет гарантий доставки сообщений (получатель не отправляет отправителю подтверждение получения данных), как следствие не гарантирован порядок получения сообщений.

Метафора UDP против TCP

Отправитель просто отправляет данные в сеть либо конкретной машине или на всю подсеть (broadcast), и будь, что будет. Кто-то может принять эти данные, либо они вообще могут потеряться. Чтобы различать разные прикладные приложения, используют номер порта (число до 65535). Потенциальный получатель просто начинает слушать свой порт, вдруг кто-то на него отправит данные.

Казалось бы, протокол UDP ненадежен, однако, UPD работает быстрее, чем TCP, так как не тратится время на подтверждения при обмене. UPD подходит неплохо для игр, стримминга, телефонии и тому подобного. А еще он отлично подойдет для наших целей обнаружения.

Я знаю отличную шутку про UDP, но боюсь, она до вас не дойдет!

С просторов Интернета…

Как только клиент игры запустится, он начнет переодически отправлять широковещательные UDP пакеты в сеть (с пометкой discovery), авось кто услышит. Но и сам начинает сразу после отправки слушать, не пришел ли ему ответ (5 секунд). Затем снова оправляет запрос.

В тоже время какой-то другой клиент сети, который уже ищет соперника, получает от него выше-указанное сообщение discovery и отвечает просьбой прекратить сканирование (stop_scan), после чего останавливает сканирование сети. Клиент получивший stop_scan проверяет, его ли идентификатор в нем указан. Если да, то он также останавливает сканирование.

Оба клиента теперь знают адреса друг друга и готовы начать обмениваться пакетами напрямую между собой уже в рамках игровой сессии. Задача обнаружения выполнена.

Мой протокол

Класс сети

Начнем писать код с класса сети Networking (по ссылке полный код класса). Он абстрагирует создание и настройку UDP сокета, обмен данными через него (кодирование и декодирование данных в JSON).

Импортирует стандартный модуль socket. Создание сокета:

import socket
...
class Networking:
    ...
    @classmethod
    def get_socket(cls, broadcast=False, timeout=TIME_OUT):
        sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
        # чтобы на одной машине можно было слушать тотже порт
        sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
        if broadcast:
            sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
        sock.settimeout(timeout)
        return sock

Отправку данных совершить очень просто. Кодируем данные в JSON, потом в байты, потом посылаем через сокет на указанный адрес и порт:

    def send_json(self, j, to):
        data = bytes(json.dumps(j), 'utf-8')
        return self._socket.sendto(data, (to, self.port_no))

Широковещательная отправка отличается только тем, что получатель будет to="<broadcast>":

  def send_json_broadcast(self, j):
        return self.send_json(j, "<broadcast>")

С прием все несколько хитрее. Сначала надо сделать bind (привязаться к порту для получения на него сообщений). Теперь сетевой стэк будет знать, что именно наша программа должна получать данные, пришедшие на компьютер именно на этот порт.

    def bind(self, to=""):
        """
        Привязаться к порту, то есть начать слушать с него сообщения
        После bind можно вызывать recv_json
        :param to: интерфейс ("" - любой)
        """
        self._socket.bind((to, self.port_no))

Затем мы вызываем на сокете recvfrom. Если есть данные, то декодируем JSON, а если не дождались (у меня стоит тайм-аут 1 секунду), то возвращаем None.

  def recv_json(self):
        try:
            # получить датаграмму и адрес из сокета
            data, addr = self._socket.recvfrom(self.BUFFER_SIZE)
            # декодируем в юникод и загружаем из JSON
            return json.loads(data.decode('utf-8', errors='ignore'), encoding='utf-8'), addr
        except json.JSONDecodeError:
            logging.error(f'JSONDecodeError!')
        except socket.timeout:
            pass  # ничего не пришло
        return None, None

Учтите! На наш сокет могут приходить также сообщения от чужих программ или от наших же клиентов игры, но в другом состоянии. А еще broadcast пакеты приходят также и обратно себе на клиент. Их надо фильтровать. Поэтому добавим метод, который несколько раз в течение определенного времени (5 секунд, допустим) будет получать из сокета данные и передавать их на проверку внешней функции predicate, которая вернет False, если это чужие данные и True, если данные подходят для текущего состояния игры. Сам метод recv_json_until вернет данные и адрес, с которого они пришли.

    def recv_json_until(self, predicate, timeout):
        t0 = time.monotonic()
        while time.monotonic() < t0 + timeout:
            data, addr = self.recv_json()
            if predicate(data):
                return data, addr
        return None, None

Discovery Protocol

Мы готовы реализовать протокол по обнаружению других клиентов, ждущих начала игры.

import random
import network
import logging

class DiscoveryProtocol:
    A_DISCOVERY = 'discovery'
    A_STOP_SCAN = 'stop_scan'

    def __init__(self, pid, port_no):
        assert pid
        self._my_pid = pid
        self._network = network.Networking(port_no, broadcast=True)
        self._network.bind()

Здесь pid (player ID) – уникальный идентификатор, чтобы отличаться от других игроков. Он создается случайно при запуске игры pid = random.getrandbits(64). Я не стал использовать IP адрес, потому что на одной машине может быть несколько запущенных клиентов (например, во время отладки). Думаю, большинство читателей первый раз будут пробовать запускать два клиента на одной машине, а не на разных.

Также мы создаем в конструкторе класс Networking, настраиваем его на широковещательную отправку и говорим ему также слушать порт.

Формат отправки сообщений будет в виде словаря с ключом action (тип действия). Например:

{
    "action": "discovery",
    "sender": 1234
}

Метод для посылки таких сообщений:

    def _send_action(self, action, data=None):
        data = data or {}
        self._network.send_json_broadcast({'action': action, 'sender': self._my_pid, **data})

Сам процесс сканирования: в бесконечном цикле рассылаем сообщение discovery, и сразу переходим в режим приема. 5 секунд ждем подходящее сообщение от других клиентов. Если оно пришло, то обрабатываем событие и прекращаем сканирование, выходя из цикла. При этом на сообщение discovery мы обязаны ответить stop_scan, чтобы удаленные клиент понял, что он нас нашел и тоже вышел из процесса сканирования.

    def run(self):
        while True:
            logging.info('Scanning...')
            # рассылаем всем сообщение A_DISCOVERY
            self._send_action(self.A_DISCOVERY)

            # ждем приемлемого ответа не более 5 секунд, игнорируя таймауты и неревалентные пакеты
            data, addr = self._network.recv_json_until(self._is_message_for_me, timeout=5.0)

            # если пришло что-то наше
            if data:
                action, sender = data['action'], data['sender']
                # кто-то нам отправил A_DISCOVERY
                if action == self.A_DISCOVERY:
                    # отсылаем ему сообщение остановить сканирование A_STOP_SCAN, указав его PID
                    self._send_action(self.A_STOP_SCAN, {'to_pid': sender})
                elif action == self.A_STOP_SCAN:
                    # если получили сообщение остановить сканирование, нужно выяснить нам ли оно предназначено
                    if data['to_pid'] != self._my_pid:
                        continue  # это не нам; игнорировать!
                return addr, sender

Как понять, что сообщение нужное? В словаре должен быть ключ "action", который принимает значения «discovery» или «stop_scan«, а еще требуем, чтобы pid отправителя был не наш (фильтруем свои же сообщения). Остальные сообщения игнорируются.

 def _is_message_for_me(self, d):
        return d and d.get('action') in [self.A_DISCOVERY, self.A_STOP_SCAN] and d.get('sender') != self._my_pid

Код для тестирования алгоритма обнаружения:

if __name__ == '__main__':
    print('Testing the discovery protocol.')
    pid = random.getrandbits(64)
    print('pid =', pid)
    info = DiscoveryProtocol(pid, 37020).run()
    print("success: ", info)

Полный код класса здесь discovery_protocol.py.

Запустите один клиент. Он будет висеть в состоянии сканирования сети. А теперь запустите второй клиент. Они сразу найдут друг друга:

Testing the discovery protocol.
pid = 8100514396826939414
success:  (('192.168.1.99', 37020), 5614644081426404292)

Примечание. Этот метод обнаружения будет работать, вероятно, только в пределах вашей локальной сети (одного роутера), потому что любой адекватный роутер на стороне провайдера будет резать широковещательные пакеты. Представляете, какой бы спам начался, если бы была возможность рассылать пакеты сразу всем устройствам, подключенным к Интернет в мире?

На этом все! В следующей части мы реализуем сам сетевой геймплей между клиентами, которые нашли друг друга по этому протоколу.

Специально для канала @pyway. Подписывайтесь на мой канал в Телеграм @pyway 👈