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

 Добрый день!  

Я всегда занимался веб программированием и, как мне кажется, у меня уже мозг повернулся в логику "запрос-ответ". То есть, по сути, я могу сделать любую игру в браузере, но только если она будет ПОШАГОВОЙ.  

Когда появился html5, я видел какие-то не сложные скетчи, типа танчиков. И вроде как всё понятно, и уже пришла мысль, что старые консольные игры (денди, сега) теперь смело можно перекладывать на html5. Но все эти игры на одного.  

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

Вот пример: есть карта, которая умещается в размер экрана. На ней в центре ваш остров и по карте разбросаны какие-то мобы. Ты можешь отправить корабль за каким-то мобом и он плывёт в реальном времени, допустим, 2 минуты туда и 2 минуты обратно. Пока плывёт ваш корабль, другой игрок может просматривать чужие карты и, если откроет вашу карту, то увидит ваш корабль, который куда-то плывёт.  

Мне тут не понятен тайминг, то есть второй игрок при открытии вашей карты должен получить инфу с сервера о том, какой корабль в какой тик вышел из гавани, какая у него скорость. И на втором клиенте рассчитать заново маршрут и отрисовать его? Так получается?  

Затем, второй игрок может напасть на ваш флот, у него есть свой корабль и он может выделить ваш корабль и нажать кнопку "напасть", тогда его корабль так же не особо быстро, скажем, плыть минуту, поплывёт наперерез.  

Эти действия необходимо опять отправить на сервер и отобразить вам, что на корабль хотят напасть.  

Вы можете отменить плавание своего корабля, тогда и корабль противника не сможет за вами гнаться, развернётся и поплывёт назад.  

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

Не так давно я познакомился с ангуляром. Но, повторюсь, у меня даже мыслей нет как это всё начать делать.  

Вопрос в том, можно ли такую игру делать на ангуляре (ну или другом клиентском фреймворке)? Возможно ли в принципе? И в какую сторону вообще копать? Будет волшебно, если есть ли какие-нибудь примеры или обучающие сайты именно в этом кллюче? 

 Вот вам пример реализации игры на двоих - [ссылка](https://pusher.com/tutorials/game-angular/) используя [Angular](https://angular.io/) и [Pusher](https://pusher.com/) 

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

Для отрисовки на клиенте лучше всего использовать [Canvas/WebGL](https://developer.mozilla.org/ru/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL). Проще это делать с помощью готовых игровых движков или графических библиотек (например [Phaser](http://phaser.io/) или [Pixi.js](http://www.pixijs.com/)). Для передачи данных на сервер и обратно в реальном времени, стоит использовать [WebSockets](https://developer.mozilla.org/ru/docs/WebSockets). 

 webRTC попробуй , там вроде есть вещать данные группам. ВебСокеты вроде прикольно но чет мне кажется медленно. 

 Это напомнило статью про 3д шутер на bash. Думаю ваша идея не лишена смысла и при должной реализации вполне реализуемая. 

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

Подписавшимся могу скинуть пример с планетами, который я разбирал  

[https://developer.mozilla.org/en-US/docs/Web/API/C...](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations)  
  

В целом, технология интересная, но она подходит для игр, которые управляются с клавиатуры. Можно смело перекладывать старые сеговские и дендевские игры. Но меня интересуют именно такие игры, в которых нужно тыкать мышкой, где куча кнопок (на которых при наведении ховеры и тултипы, и легко вешать обработчики). А в этой технологии просчитать куда кликнули мышкой, потом пересчитать координаты, чтобы определить на глазок что за элемент, к которому как-то костыльно прицеплять обработчики... Задачи, скажем так, не тривиальные и решаются бубном и такой-то матерью, что грозит превратить любой проект в болото.  

В общем, посмотрю еще движения в svg, а может быть вообще начну пилить на чистом DHTML. 

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

Выглядеть это может следующим образом:  

1) клиент открывает соединение с сервером по вебсокетам  

2) на сервере создается сущность под клиента  

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

4) если на клиенте происходит какое-либо действие, то уже клиент шлет серверу данные, и на сервере отрабатывает коллбек, который меняет стейт, и эти изменения при следующем обсчете мира обрабатываются, далее см. п. 3, так все участники получают апдейты  

5) при этом чтобы не было лагов, действия пользователя на клиенте рендерятся сразу, а потом перерендериваются в зависимости от того что пришлет в ответ сервер, т.к. там будут проверки, чтобы пользователи не читерили (должны отсекаться невозможные/ошибочные действия)  
  

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