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

[datacompboy]

А всё равно лагает, ракетка не плавно а рывками двигается как моя, так и соперника.

[rrromka]

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

[zuix]

немного лагает
опять желтый победил :)

[DiveSlip]

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

[WaveCut]

Как часто статистика обновляется? Пока что там голяк!

[rrromka]

Статистика обновляется раз в минуту. Попробуйте Ctrl+R нажать, возможно в браузере картинка закешировалась.

[SovGVD]

Еще можно в мультиплеер добавить бота, чтобы не ждать когда кто-то еще присоеденится к игре. Например если за 10-20 секунд реальный юзер не появился, то подставляем бота (но не говорим об этом пользователю).

[zerodivisi0n]

Хотелось бы увидеть более подробное описание протокола — что используется в качестве транспорта? голый TCP? как осуществляется фрагментация сообщений? было бы разумно использовать какие-нибудь WebSockets + JSON для этого. С HTML5 это будет работать хорошо, а вот насчет флеша не знаю.

[rrromka]

Формат обмена данными

Серевер клиенту при инициализации (первый пакет)

При инициализации игры сервер передает клиенту массив с данными:
0 'left or right'
1 координаты шарика по оси Х;
2 координаты шарика по оси У;
3 дельта шарика по оси Х по отношению к предыдущему дата фрейму;
4 дельта шарика по оси Y по отношению к предыдущему дата фрейму;
5 счет левого игрока;
6 счет правого игрока;
7 координата У левой доски;
8 координата У правой доски;
9 дельта У левой доски;
10 дельта У правой доски;
11 номер «дата фрейма» (не номер отрендеренного флешом кадра, а номер передачи данных);
12 клиент добавляет к этому массиву время, за которое кадр должен быть отрендерен (1 / число дата фреймов в секунду)

Серевер клиенту во время игрового процесса

При игре сервер передает клиенту аналогичные данные, для сохранения совместимости с данными инициализации первый элемент передается пустым:
0 ''
1 координаты шарика по оси Х;
2 координаты шарика по оси У;
3 дельта шарика по оси Х по отношению к предыдущему дата фрейму;
4 дельта шарика по оси Y по отношению к предыдущему дата фрейму;
5 счет левого игрока;
6 счет правого игрока;
7 координата У левой доски;
8 координата У правой доски;
9 дельта У левой доски;
10 дельта У правой доски;
11 номер «дата фрейма» (не номер отрендеренного флешом кадра, а номер передачи данных);
12 клиент добавляет к этому массиву время, за которое кадр должен быть отрендерен (1 / число дата фреймов в секунду)

Клиент серверу во время игры

0 'left or right'
1 изменение положения своей доски
2 номер отправленного фрейма. Нужен чтобы сервер не обрабатывал дважды один и тот же фрейм.

Перед отправкой данных и клиент, и сервер конвертируют их в JSON и в таком виде передают. Вот тут код отвечающий за передачу данных сервером:
github.com/romka/quickpong/blob/master/quickpong/quickpong.py#L179
github.com/romka/quickpong/blob/master/quickpong/protocol.py#L72

[rrromka]

что используется в качестве транспорта? голый TCP?

Да, голый TCP.

как осуществляется фрагментация сообщений?

Каждый дата-фрейм это преобразованный в JSON-массив с данными, описание массива в соседнем комментарии.

было бы разумно использовать какие-нибудь WebSockets + JSON для этого

Согласен, но сейчас у меня нет возможности допилить еще и HTML5-клиент. Для того и выложил на гитхабе, чтобы желающие смогли усовешенствовать клиент :)

[zerodivisi0n]

Спасибо! Это я ожидал увидеть в статье.

[Cupper]

2 номер отправленного фрейма. Нужен чтобы сервер не обрабатывал дважды один и тот же фрейм.

А почему клиент может один фрейм два раза отправить?

Фрейм это «Клиент серверу во время игры»?

Интересный пост для начала изучения проблем гем дева, python и Twisted:) по разбираюсь.

[rrromka]

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