Quickpong — разработка сетевой игры на основе фреймворка Twisted

Разработал и запустил на домене quickpong.com ^[1] онлайн версию игры Pong. В игре (by design) реализован только режим мультиплейера, то есть игра идет не против искусственного интеллекта, а против другого человека.

Игра представляет из себя клиент-серверное приложение, серверная часть написана на питоновском фреймворке Twisted ^[2], клиентская — на флэшовом фреймворке FlashPunk ^[3].

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

Два слова об игровом процессе

На игровом поле слева и справа находятся 2 доски, способные перемещаться по вертикали. Каждой из досок управляет человек. Между досками перемещается шарик, отскакивающий от стенок игрового поля и досок. Задача игрока — не допустить попадания шарика за стенку, возле которой находится его доска.

Выбор используемых технологий

При освоении новых технологий и инструментов огромную роль играет наличие грамотной подробной документации. Выбирая серверный фреймворк я рассматривал питоновские Twisted, Tornado и, находящийся у всех на слуху, Node.js.

Исходя из того, что у меня вообще не было опыта разработки подобных приложений, мой выбор пал на Twisted. Для него написан очень подробный вводный курс ^[4], объясняющий азы разработки асинхронных приложений не зависимо от какого-либо фреймворка или языка программирования, а также, разумеется, рассказывающий об использовании самого Twisted. Настоятельно рекомендую этот курс всем желающим постичь основы разработки асинхронных приложений. По ссылке выше вы сможете найти и перевод этого курса на русский язык.

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

Алгоритм взаимодействия клиента и сервера

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

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

Кроме того, хотелось бы избежать мошенничества со стороны клиентов: при желании и умении клиентская swf-ка может быть модифицирована и может передавать на сервер читерские данные.

Таким образом, в первой версии алгоритма я решил действовать так:

1. каждый клиент сам обсчитывает состояние своего игрового мира (положение шарика, своей доски и доски соперника),
2. каждый клиент 20 раз в секунду передает на сервер информацию об изменении положения своей доски и информацию о параметрах шарика (координаты, вектор, скорость) в своем игровом мире,
3. сервер пересылает каждому игроку информацию о положении доски соперника,
4. сервер сам рассчитывает текущее состояние игрового мира и сравнивает его с данными полученными от клиентов (пункт 2). Если есть рассинхрон между состояниями, рассчитанными клиентом и сервером, то сервер принудительно возвращает клиентов в состояние, которое считает правильным.

Алгоритм получился нерабочим. Он мог бы быть рабочим только в случае, если все 3 участника обмена данными имели бы одинаковое состояние. На практике в 100% случаев был рассинхрон и играть было невозможно.

Во второй версии алгоритма я решил избавиться от одного из звеньев — от расчета состояния игрового мира на сервере:

1. каждый клиент по прежнему сам рассчитывал координаты шарика и досок и передавал данные о своем состоянии на сервер,
2. сервер сравнивал состояния клиентов и если они различались, то принудительно возвращал одного из клиентов к состоянию второго.

Этот подход тоже получился нерабочим. Даже клиенты запущенные на двух идентичных машинах рассчитывали состояние игрового мира немного по разному и, несмотря на то, что теперь у меня сравнивалось 2 состояния, а не 3, как в предыдущем случае, все равно состояние одного из клиентов постоянно принудительно изменялось, выглядело это как заметные “скачки” шарика и играть было невозможно.

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

Погуглив я нашел такие вот интересные ссылки:

• stackoverflow.com/questions/1411745/multiplayer-game-synchronization ^[5]
• www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php ^[6]
• www.kirupa.com/forum/showthread.php?297510-Synchronizing-Realtime-Multiplayer-games ^[7]
• developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ^[8]

Алгоритм описанный по последней ссылке и был взят мною для этого проекта. Суть его такова:

1. все расчеты ведутся только на сервере. Клиенты передают на сервер дельты изменений своего состояния, в моем случае это изменение положения доски относительно предыдущей передачи данных.
2. Сервер рассчитывает положения досок (подавляя возможный читеринг со стороны клиента) и шарика и передает сформированный дата-фрейм клиентам.
3. Клиенты рендерят полученные дата-фреймы, в моем случае, с запозданием на 3 фрейма. Это важный момент. Данные от сервера клиенту приходят неравномерно, например, из-за проблем с сетью клиент может получить данные о новом положении шарика не через положенные 50 мс, а через 60-70 мс. То есть может случиться так, что последний дата-фрейм уже отрендерен, а новый еще не пришел. В такой ситуации у клиента не будет данных для отрисовки шарика и, в моем случае, шарик просто остановится ожидая получение новой порции данных. Для того чтобы предотвратить такие ситуации клиент отрисовывает данные с запозданием на 3 дата-фрейма, что дает некоторый запас, благодаря которому даже если данные от сервера не получены вовремя у клиента будет что рендерить. Неприятная сторона этого алгоритма — заметная задержка между действием пользователя (нажатие кнопок на клавиатуре) и отображением изменений на экране. Есть методы устранения этой задержки, но конкретно в этом случае я решил не усложнять клиент.

Реализация

Исходники сервера и клиента я выложил на Гитхабе:

• github.com/romka/quickpong ^[9],
• github.com/romka/quickpong_flash_client ^[10].

На этой схеме: quickpong.com/images/quickpong.png ^[11] показана логика взаимодействия клиента и сервера.

С точки зрения реализации сервера все достаточно прозрачно. На 10080 порту стартует реактор (event loop), в котором работает серверная фабрика — класс QuickpongServerFactory ^[12]. При инициализации фабрики создается экземпляр класса Quickpong ^[13], который содержит всю логику по взаимодействию сервера с клиентом.

При подключении нового клиента фабрика вызывает метод buildProtocol ^[14] и создает для каждого присоединившегося клиента экземпляр класса QuickpongProtocol ^[15], созданный объект передается в Quickpong. Таким образом, объект класса Quickpong имеет доступ ко всем присоединившимся клиентам и может выполнять с ними необходимую работу: объединять в пары, обсчитывать состояние игрового мира и т.д.

Объект класса QuickpongProtocol содержит только методы для получения и передачи данных от/к клиенту.

С реализацией клиента тоже всё просто, единственным интересным моментом было следующее. Используя FlashPunk я могу задать частоту обновления картинки (FPS), при этом FlashPunk может гарантировать, что он отрисует N кадров в секунду, но не может гарантировать того, что каждый кадр будет отрисован за 1/N секунды. То есть при FPS 50 в идеальном случае каждый кадр должен отрисовываться за 20 мс, в реальном случае один кадр может быть отрисован за 15 мс, а другой за 25 мс. Если шарик двигается с постоянной скоростью, например 10 пикселов в секунду, и отрисовка каждого дата-фрейма сопадает с отрисовкой кадра ФлэшПанком, то шарик будет двигаться неравномерно, рывками, так как в одном случае он переместится на 10 пикселов за 15 мс, а в другом за 25.

Эту особенность пришлось учесть в клиенте ^[16] и перед отрисовкой кадра я проверяю сколько времени прошло с момента отрисовки предыдущего кадра, на основании этого я определяю рендерить дата-фрейм полностью или частично.

Тестирование и мониторинг

Самый интересный для меня вопрос — сколько игроков онлайн сможет выдержать этот сервер? Для теста я написал на питоне небольшой клиент ^[17], который эмулировал действия человека.

Тест проводил на виртуальной машине, под которую выделено 1 ядро Intel® Xeon® CPU E31275 @ 3.40GHz.

Средствами того же Twisted я повесил на 10082 порт веб-сервер, который выводит через запятую число юзеров онлайн и число активных игр. На основе этой информации, а также при помощи питоновской библиотеки psutil ^[18] и связки rrdtool ^[19] + py-rrdtool ^[20] я написал скрипты ^[21], которые выводят информацию о текущем числе пользователей онлайн и потребляемых ресурсах в удобоваримом виде: quickpong.com/stats.html ^[22] (картинки обновляются раз в минуту).

При 5000 (5 тысяч) игроков программа отъедает около 100 Мб оперативной памяти, грузит CPU в среднем на 30-40%.

Roadmap

Идеи, которые остались нереализованными:

• html5-клиент,
• усложнение игрового процесса благодаря изменению угла отскока от доски, в зависимости от точки соприкосновения шарика и доски,
• введение режима игры вчетвером, по одной доске на каждой стороне игрового поля :)),
• реализация алгоритма lag compensation,
• исправление мелких багов.

На данный момент я потерял интерес к развитию этого проекта, возможно мои наработки покажутся кому-нибудь познавательными или интересными, по этому я выложил все исходники на Гитхаб:

• github.com/romka/quickpong ^[9],
• github.com/romka/quickpong_flash_client ^[10].

Автор: rrromka

Источник ^[23]