Jeer
@Jeer
уверенный пользователь

Как пишутся динамические многопользовательные игры на html5?

Добрый день!
Я всегда занимался веб программированием и, как мне кажется, у меня уже мозг повернулся в логику "запрос-ответ". То есть, по сути, я могу сделать любую игру в браузере, но только если она будет ПОШАГОВОЙ.
Когда появился html5, я видел какие-то не сложные скетчи, типа танчиков. И вроде как всё понятно, и уже пришла мысль, что старые консольные игры (денди, сега) теперь смело можно перекладывать на html5. Но все эти игры на одного.
И вот я с ужасом осознал, что у меня даже нет идей как можно делать динамические многопользовательские игры.
Вот пример: есть карта, которая умещается в размер экрана. На ней в центре ваш остров и по карте разбросаны какие-то мобы. Ты можешь отправить корабль за каким-то мобом и он плывёт в реальном времени, допустим, 2 минуты туда и 2 минуты обратно. Пока плывёт ваш корабль, другой игрок может просматривать чужие карты и, если откроет вашу карту, то увидит ваш корабль, который куда-то плывёт.
Мне тут не понятен тайминг, то есть второй игрок при открытии вашей карты должен получить инфу с сервера о том, какой корабль в какой тик вышел из гавани, какая у него скорость. И на втором клиенте рассчитать заново маршрут и отрисовать его? Так получается?
Затем, второй игрок может напасть на ваш флот, у него есть свой корабль и он может выделить ваш корабль и нажать кнопку "напасть", тогда его корабль так же не особо быстро, скажем, плыть минуту, поплывёт наперерез.
Эти действия необходимо опять отправить на сервер и отобразить вам, что на корабль хотят напасть.
Вы можете отменить плавание своего корабля, тогда и корабль противника не сможет за вами гнаться, развернётся и поплывёт назад.
Если бы это была игра на одного, то никаких проблем, но тут же куча таймингов (плюс могут еще быть другие игроки, которые так же будут на это смотреть и которые тоже смогут отправить свои корабли). И как это всё синхронизировать, учитывая, что есть лаги во времени, мне совсем непонятно.
Не так давно я познакомился с ангуляром. Но, повторюсь, у меня даже мыслей нет как это всё начать делать.
Вопрос в том, можно ли такую игру делать на ангуляре (ну или другом клиентском фреймворке)? Возможно ли в принципе? И в какую сторону вообще копать? Будет волшебно, если есть ли какие-нибудь примеры или обучающие сайты именно в этом кллюче?
  • Вопрос задан
  • 1400 просмотров
Решения вопроса 6
StivinKing
@StivinKing
Вот вам пример реализации игры на двоих - ссылка используя Angular и Pusher
Ответ написан
Oniestel
@Oniestel
Если в общих чертах, то всю или почти всю логику игры имеет смысл считать на сервере. Там же всё это дело синхронизировать. Клиент же, в свою очередь, только получает текущее состояние игры с сервера, отрисовывает его и передает на сервер действия пользователя.

Для отрисовки на клиенте лучше всего использовать Canvas/WebGL. Проще это делать с помощью готовых игровых движков или графических библиотек (например Phaser или Pixi.js). Для передачи данных на сервер и обратно в реальном времени, стоит использовать WebSockets.
Ответ написан
saintbyte
@saintbyte
Django developer
webRTC попробуй , там вроде есть вещать данные группам. ВебСокеты вроде прикольно но чет мне кажется медленно.
Ответ написан
SayMAN83
@SayMAN83
Работаю в IT
Это напомнило статью про 3д шутер на bash. Думаю ваша идея не лишена смысла и при должной реализации вполне реализуемая.
Ответ написан
Jeer
@Jeer Автор вопроса
уверенный пользователь
В общем, мне достаточно было просто посмотреть обучающих статей, потыкать примеры, в принципе, разобраться можно, хоть лично у меня с этим возникли сложности.
Подписавшимся могу скинуть пример с планетами, который я разбирал
https://developer.mozilla.org/en-US/docs/Web/API/C...

В целом, технология интересная, но она подходит для игр, которые управляются с клавиатуры. Можно смело перекладывать старые сеговские и дендевские игры. Но меня интересуют именно такие игры, в которых нужно тыкать мышкой, где куча кнопок (на которых при наведении ховеры и тултипы, и легко вешать обработчики). А в этой технологии просчитать куда кликнули мышкой, потом пересчитать координаты, чтобы определить на глазок что за элемент, к которому как-то костыльно прицеплять обработчики... Задачи, скажем так, не тривиальные и решаются бубном и такой-то матерью, что грозит превратить любой проект в болото.
В общем, посмотрю еще движения в svg, а может быть вообще начну пилить на чистом DHTML.
Ответ написан
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
Как правильно написал коллега выше, рисовать в канвасе, данные синхронизировать по вебсокетам, всю логику считать на сервере, тут оптимальнее будет сервер на ноде, т.к. он долгоживущий, в отличии от пыхи.

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

Очень упрощенно это может выглядеть как-то так...
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы