Как пишутся динамические многопользовательные игры на html5?
Добрый день!
Я всегда занимался веб программированием и, как мне кажется, у меня уже мозг повернулся в логику "запрос-ответ". То есть, по сути, я могу сделать любую игру в браузере, но только если она будет ПОШАГОВОЙ.
Когда появился html5, я видел какие-то не сложные скетчи, типа танчиков. И вроде как всё понятно, и уже пришла мысль, что старые консольные игры (денди, сега) теперь смело можно перекладывать на html5. Но все эти игры на одного.
И вот я с ужасом осознал, что у меня даже нет идей как можно делать динамические многопользовательские игры.
Вот пример: есть карта, которая умещается в размер экрана. На ней в центре ваш остров и по карте разбросаны какие-то мобы. Ты можешь отправить корабль за каким-то мобом и он плывёт в реальном времени, допустим, 2 минуты туда и 2 минуты обратно. Пока плывёт ваш корабль, другой игрок может просматривать чужие карты и, если откроет вашу карту, то увидит ваш корабль, который куда-то плывёт.
Мне тут не понятен тайминг, то есть второй игрок при открытии вашей карты должен получить инфу с сервера о том, какой корабль в какой тик вышел из гавани, какая у него скорость. И на втором клиенте рассчитать заново маршрут и отрисовать его? Так получается?
Затем, второй игрок может напасть на ваш флот, у него есть свой корабль и он может выделить ваш корабль и нажать кнопку "напасть", тогда его корабль так же не особо быстро, скажем, плыть минуту, поплывёт наперерез.
Эти действия необходимо опять отправить на сервер и отобразить вам, что на корабль хотят напасть.
Вы можете отменить плавание своего корабля, тогда и корабль противника не сможет за вами гнаться, развернётся и поплывёт назад.
Если бы это была игра на одного, то никаких проблем, но тут же куча таймингов (плюс могут еще быть другие игроки, которые так же будут на это смотреть и которые тоже смогут отправить свои корабли). И как это всё синхронизировать, учитывая, что есть лаги во времени, мне совсем непонятно.
Не так давно я познакомился с ангуляром. Но, повторюсь, у меня даже мыслей нет как это всё начать делать.
Вопрос в том, можно ли такую игру делать на ангуляре (ну или другом клиентском фреймворке)? Возможно ли в принципе? И в какую сторону вообще копать? Будет волшебно, если есть ли какие-нибудь примеры или обучающие сайты именно в этом кллюче?
Привет, спасибо за участие!
Это пример пошаговой игры, я такое умею делать.
Меня интересует именно динамика. Даже не такая сложная типа стратегии или рпг в реальном времени, а тут урезанная, есть всего две кнопки "напасть" и "отменить". Но пока первый игрок в процессе, второй может вклиниться в этот процесс, вот именно это.
Виктор П., От простого к сложному. Играми я, конечно, не занимался, но по существу, взяв во внимание данную простую игру, можно даже на её основе написать сложную.
В этой игре есть только, как вы говорите, 2 действия "напасть" и "отменить". При нажатии первым игроком на любую из них, второй получает результат от первого игрока. Значит мы можем пойти дальше и сделать отправку каких-либо данных на сервер в фоновом режиме. Так же увеличим кол-во игроков и вот уже все кто зашел на страницу первого игрока получают изменившиеся данные по web-сокетам. Главное понимать и не делать слишком много ненужных изменений. То же самое передвижение корабля можно сделать следующим образом. При переходе на страницу игрока получить его координаты, выставить визуально корабыль на данное место, а дальнейшее передвижение вести по заданному алгоритму, пока, по какой-то причине, с сервера не придут новые координаты, к примеру если игрок воспользовался каким-нибудь бустом.
Но пока первый игрок в процессе, второй может вклиниться в этот процесс, вот именно это.
Имеем ту же самую логику, только теперь более двустороннюю. А именно, если игроки могут делать что-либо одновременно, то при взаимодействии с чем-либо, к примеру с сундуком, на сервер отправляется n-информация, которая отсылается всем слушателям (к примеру, кто находится на этой же карте) и данных игроков сундук так же становится открытым
Если в общих чертах, то всю или почти всю логику игры имеет смысл считать на сервере. Там же всё это дело синхронизировать. Клиент же, в свою очередь, только получает текущее состояние игры с сервера, отрисовывает его и передает на сервер действия пользователя.
Для отрисовки на клиенте лучше всего использовать Canvas/WebGL. Проще это делать с помощью готовых игровых движков или графических библиотек (например Phaser или Pixi.js). Для передачи данных на сервер и обратно в реальном времени, стоит использовать WebSockets.
В общем, мне достаточно было просто посмотреть обучающих статей, потыкать примеры, в принципе, разобраться можно, хоть лично у меня с этим возникли сложности.
Подписавшимся могу скинуть пример с планетами, который я разбирал https://developer.mozilla.org/en-US/docs/Web/API/C...
В целом, технология интересная, но она подходит для игр, которые управляются с клавиатуры. Можно смело перекладывать старые сеговские и дендевские игры. Но меня интересуют именно такие игры, в которых нужно тыкать мышкой, где куча кнопок (на которых при наведении ховеры и тултипы, и легко вешать обработчики). А в этой технологии просчитать куда кликнули мышкой, потом пересчитать координаты, чтобы определить на глазок что за элемент, к которому как-то костыльно прицеплять обработчики... Задачи, скажем так, не тривиальные и решаются бубном и такой-то матерью, что грозит превратить любой проект в болото.
В общем, посмотрю еще движения в svg, а может быть вообще начну пилить на чистом DHTML.
Александр Маджугин, С элементами управления прокатит, то есть посыл такой, что будет html меню и под ним простыня с графикой, не надо даже задвигать одно на другое. Но если мы возьмем какую-нибудь пошаговую игру, да вот например, герои 3 карта боя. Отрисовать поле шестигранников не сложно. Расставить на нём каких-то существ, ну тоже не сложно. А дальше взаимодействие какое, есть активный персонаж, он может куда-то перейти и кого-то ударить. И можно мышкой нажимать кнопки, например, посмотреть расширенное инфо по какому-то персонажу. Ничто не мешает задвинуть на отрисованные персонажи html элементы, но тогда пропадает вообще смысл канваса. Они перемещаются по всей карте, нужно отслеживание координат мыши, потом определение над какими элементами курсор, потом привязка возможных действий, это столько геммора, что жуть берёт. Есть всякие примеры, типа дублируем канвас, делаем его прозрачным, на него дублируем персонажей, выдаём каждому свой id, парсим id в определённый цвет. И уже по этому цвету определяем куда мы нажали. Остаётся еще куча нетривиальных действий как это хранить и прилеплять обработчики. Кстати, при наложений персонажей будет наложение цветов.
Если у вас есть примеры реализации подобных игр, буду признателен. Не просто, есть игра "name", там так сделано, а пример как это делается, я буду крайне признателен. Пока я вижу, что канвас не для таких игр.
А, понятно теперь.
Ну так эту всю фигню вам должен предоставить движок. Иначе свихнетесь.
Если не используете никакие движки - надо хотя бы навелосипедить какой-то свой примитив.
Ну я пробовал PointJS правда сейчас он то ли переименовался, то ли влился в другой проект... Но сам факт - такие вещи должен предоставлять движок. Т.е. он просто должен генерировать события при клике в области объекта. Вам не надо следить за этими вещами.
Движок - это хорошо ) просто во всех "рекламных" роликах говорится, что канвас - вот прям супер-пупер решение. И под все платформы надо завернуть, и всё делается буквально пара строчек кода. Типа "я за вечер на коленке написал игру".
А тут оказывается, что простые действия нужно либо колхозить самому, либо использовать чужие движки, то есть одного канваса + пара строк js недостаточно. Никакой волшебной магии-то и нет )
В общем, спасибо вам за участие, я пока отложу канвас в сторонку, может когда-нибудь к нему вернусь )
Как правильно написал коллега выше, рисовать в канвасе, данные синхронизировать по вебсокетам, всю логику считать на сервере, тут оптимальнее будет сервер на ноде, т.к. он долгоживущий, в отличии от пыхи.
Выглядеть это может следующим образом:
1) клиент открывает соединение с сервером по вебсокетам
2) на сервере создается сущность под клиента
3) на сервере бесконечный цикл обсчета мира, после обсчета обновленные данные рассылаются клиентам, висящим на вебсокетах, у них, в свою очередь, отрабатывают коллбеки в каждый момент, когда сервер им что-то присылает
4) если на клиенте происходит какое-либо действие, то уже клиент шлет серверу данные, и на сервере отрабатывает коллбек, который меняет стейт, и эти изменения при следующем обсчете мира обрабатываются, далее см. п. 3, так все участники получают апдейты
5) при этом чтобы не было лагов, действия пользователя на клиенте рендерятся сразу, а потом перерендериваются в зависимости от того что пришлет в ответ сервер, т.к. там будут проверки, чтобы пользователи не читерили (должны отсекаться невозможные/ошибочные действия)
