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