Comments 13
А всё равно лагает, ракетка не плавно а рывками двигается как моя, так и соперника.
+10
Да, клиент несовершенен. Если нажать тильду, то можно будет увидеть отладочную информацию и положение доски, там где она должна находиться по мнению клиента. Эта доска двигается плавно. При желании можно допилить клиента так, чтобы движения досок были более плавными.
+1
немного лагает
опять желтый победил :)
опять желтый победил :)
0
Пока в игре побеждает тот, у кого меньше лагает, либо тот, кто к лагам лучше приноровился. А в целом понравилось, если хочется немного отвлечь мозг, то самое оно.
0
Как часто статистика обновляется? Пока что там голяк!
0
Еще можно в мультиплеер добавить бота, чтобы не ждать когда кто-то еще присоеденится к игре. Например если за 10-20 секунд реальный юзер не появился, то подставляем бота (но не говорим об этом пользователю).
0
Хотелось бы увидеть более подробное описание протокола — что используется в качестве транспорта? голый TCP? как осуществляется фрагментация сообщений? было бы разумно использовать какие-нибудь WebSockets + JSON для этого. С HTML5 это будет работать хорошо, а вот насчет флеша не знаю.
0
Формат обмена данными
Серевер клиенту при инициализации (первый пакет)
При инициализации игры сервер передает клиенту массив с данными:
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
Серевер клиенту при инициализации (первый пакет)
При инициализации игры сервер передает клиенту массив с данными:
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
+3
что используется в качестве транспорта? голый TCP?
Да, голый TCP.
как осуществляется фрагментация сообщений?
Каждый дата-фрейм это преобразованный в JSON-массив с данными, описание массива в соседнем комментарии.
было бы разумно использовать какие-нибудь WebSockets + JSON для этого
Согласен, но сейчас у меня нет возможности допилить еще и HTML5-клиент. Для того и выложил на гитхабе, чтобы желающие смогли усовешенствовать клиент :)
Да, голый TCP.
как осуществляется фрагментация сообщений?
Каждый дата-фрейм это преобразованный в JSON-массив с данными, описание массива в соседнем комментарии.
было бы разумно использовать какие-нибудь WebSockets + JSON для этого
Согласен, но сейчас у меня нет возможности допилить еще и HTML5-клиент. Для того и выложил на гитхабе, чтобы желающие смогли усовешенствовать клиент :)
+2
2 номер отправленного фрейма. Нужен чтобы сервер не обрабатывал дважды один и тот же фрейм.
А почему клиент может один фрейм два раза отправить?
Фрейм это «Клиент серверу во время игры»?
Интересный пост для начала изучения проблем гем дева, python и Twisted:) по разбираюсь.
0
Sign up to leave a comment.
Quickpong — разработка сетевой игры на основе фреймворка Twisted