Как работают многопользовательские real-time приложения в canvas?

Question

[Eng_ru]

Я играл раньше в браузерные игры, где на одной карте (локации) отображались сразу несколько игроков и их передвижения по этой карте (например, игра по типу чашки Петре - agar.io). Но тогда я не знал, что такое canvas, и не задумывался, как вообще реализованы такие вещи.
И вот недавно впервые встретился с разработкой на канвасе. Хочу понять, как же на нём реализуют многопользовательские онлайн приложения?

Я так понимаю, что в функции отрисовки requestAnimationFrame, в которой и рисуется новое положение игрока X, например, смещается на 1 пиксель, отправляется post-запрос на сервер с id игрока и новыми координатами его расположения (смещение на 1px). Эти данные сохраняются и рассылаются всем остальным игрокам, находящимся на той же карте, и у них на картах игрок X отрисовывается на только что полученных координатах. Так? И так происходит по несколько десятков раз в секунду (по частоте вызова requestAnimationFrame)?

Comments

[Ярослав Иванов]

Да

[Пашенька]

На POST- запросах это будет слайд-шоу. Веб-сокеты ответ.

[Eng_ru]

Спасибо за ответы!

Answer 1

[xmoonlight]

Есть минимум 4 асинхронных(параллельно обрабатываются!) цикла получения данных.
1. Сигнал синхронизации: "стук сердца" (heart-beat).
2. Локальный: только расчёты.
3. Визуализация/Рендеринг: FPS.
4. Сетевой обмен данными: мультиплеер.

Всё считается отдельно и независимо друг от друга!
Самый главный - это синхросигнал (п.1).

НО! Также, есть допуски у всех уровней, что ниже, которые устанавливают допустимые критерии оптимизации и поддерживают корректную синхронизацию и античит.

Все на сервере делаем на нативных сокетах!
И, чтобы НЕ гонять лишний трафик в JSON-формате через WebSocket, советую использовать websockify или engine.io (от разработчиков socket.io).

Дальше - апроксимация движения объектов и лаги... Это будет ещё интереснее)))

Comments

[Robur]

Что такое нативные сокеты в браузере?

[xmoonlight]

Robur, tcp/udp с помощью ws-враппера или с двубайтовым заголовком.
Главное - не текст гонять в JSON.

[Robur]

xmoonlight, ws давно умеет передавать настоящие бинарные данные. Хоть протобаф по нему гоняйте.

А есть пример что вы подразумеваете под "tcp/udp с помощью ws-враппера"?

[xmoonlight]

Robur, в ответе, я добавил линки.

[Robur]

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

[xmoonlight]

Robur, Ну, пока - так.. Хотя есть в эксперементальном режиме у хрома реальные raw tcp и udp. Но я не тестил.

Answer 2

[historydev]

Как обычный чат, веб-сокет

Comments

[Eng_ru]

Тут меня больше интересовало, в requestAnimationFrame ли отправляется инфа о новых координатах, т.е. прям покадрово или раз в секунду?) С чатом-то понятно - по кнопке Отправить идёт запрос.

[Пашенька]

Eng_ru, если работа движка игры способна укладываться(а она должна) в 16мс, то да, иначе плавность игры будет страдать.

[Eng_ru]

like-a-boss, извините за нубский, наверное, вопрос, просто я студент ещё, реальной практики у меня 0, для таких вещей используют как раз Redis?

[Пашенька]

Eng_ru, redis - это хранилище для быстрого доступа. Не обязательно, можно и средствами языка создавать массивы/объекты, которые так же будут жить в оперативной памяти, а без прокладки в виде редиски, можно ещё быстрее к ним доступ иметь.
В целом, для таких задач нужно использовать наиболее быстрые решения и работу в цикле requestAnimationFrame сводить к минимуму, кешируя всё, что можно закешировать.

[Eng_ru]

like-a-boss, спасибо за развёрнутый ответ!

[xmoonlight]

Eng_ru, Владимир, like-a-boss, нет.... Все гораздо сложнее...

[historydev]

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

[xmoonlight]

Владимир, ну это пошаговая... А так - да.