Мультиплеер

другие уроки, мануалы, советы по Construct 2

Сообщение Мультиплеер
» 04 мар 2014, 10:01

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

Оригинал: https://www.scirra.com/tutorials/892/mu ... pts/page-1

Мультиплеер

Концепт мультиплеера.
Обратите внимание, что на 4 марта движок многопользовательской игры еще не опубликован. Этот туториал предназначен для того, чтобы вы могли начать изучать теорию создания многопользовательской игр заранее. Здесь есть довольно много тонкостей и это довольно сложный предмет обсуждения, поэтому начинайте читать сейчас и вы будете готовы к использованию возможностей мультиплеера, когда они будут опубликованы.

Введение
Разработка многопользовательских игр - это сложный процесс, даже несмотря на то, что объект мультиплеера устраняет ряд типовых проблем, стоящих перед разработчиком. События в каждой отдельной игре различны, и способ поддержки передачи сообщений и данных будет различным в зависимости от типа игры, которую вы делаете. Как результат, основные возможности объекта сделаны сравнительно абстрактными, чтобы вы могли настроить их именно относительно вашей конкретной игры. Для того, чтобы извлечь максимум из этих возможностей, важно знать основы работы многопользовательских онлайн игр, проблемы, которые возникают и как они решаются.

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

Если вы готовы начать обучение, то вот оно:

Связывание
Многопользовательский движок Констракта основан на каналах передачи данных WebRTC DataChannels. Это технология передачи данных от пользователя к пользователю (peer-to-peer) через браузер. Пользователи соединяются прямо друг с другом, а не через центральный сервер.

Несмотря на тот факт, что пользователи могут соединяться прямо друг с другом, игра все же разрабатывается в терминах клиент-серверной логики. Первый пользователь (пир, peer), который подсоединяется к игре, становится хостом. Все в дальнейшем присоединившиеся к игре пользователи затем соединяются только с хостом. Все игроки, которые не являются хостами, являются пирами. Хост действует как сервер для всей игры. Ключевое отличие хоста от центрального сервера в том, что хостом может быть любой игрок, в то время как постоянный центральный сервер запускается разработчиком игры. Также хост может быть полноправным участником игры в то время как сервер обычно является лишь условием связи игроков.


Мультиплеет, запущенный через центральный сервер.
Изображение

Peer-to-peer (без сервера с прямой связью между игроками) мультиплеер.
Изображение

Впрочем, если вы хотите, вы можете использовать и центральный сервер: вы можете спроектировать вашу игру так, что хост не будет участником игры и оставить его запущенным на предназначенном для этого сервере. Однако это приводит к необходимости платить за хостинг сервера и метод peer-to-peer - это дешевле.

Для того, чтобы присоединившийся пир был в состоянии соединиться с хостом, необходимо знать где он находится и как к нему присоединиться. Это включает три вещи: IP адрес, информация о наличии роутера, который накладывает ограничения на соединение, и информация о том, можно ли обойти эти ограничения.

Роутеры с ограничениями очень распространены. Интернет ушел от адресов IPv4 несколько лет назад и перешел на практику скрывать множество пользователей под одним IP. Это сделано при помощи технологии NAT (передачи сетевого адреса). Например, в вашем доме может быть роутер, к которому подключено несколько компьютеров. В этом случае все они будут появляться под одним IP адресом, но разными портами. Есть также несколько других вариантов NAT, включающих огромные примененные к целым регионам, мобильные сети и некоторые из них накладывают больше ограничений, чем другие. К сожалению, это означает, что в ряде случаев соединение будет невозможным, особенно, если и хост и присоединившийся пир будут из сетей с высокими степенями ограничений. Однако при обычных установках, пользователи смогут присоединяться друг к другу. Как правило, чем ближе они друг к другу географически, тем более велика вероятность успешного соединения с высоким качеством. Это одна из причин поощрять соединения хотя бы внутри одного континента.

Пример NAT
Изображение

Связывание автоматически осуществляется WebRTC. Технология попробует определить, как присоединиться к хосту, обходя ограничения NAT. Это означает, что игре не надо прописывать определенного порта, через который она будет работать. WebRTC сам подыщет подходящее решение. Например, в диаграмме выше три клиента совместно используют один IP, поэтому пир на другой стороны должен соединиться к этмоу адресу через порта А, если о хочет соедениться с первым игроком, через порт В, если со вторым и так далее. Однако держите в уме, что часто не будет возможности соединить двух пользователей вместе и может потребоваться найти другого пользователя, чтобы он работал как хост.

Принятие IPv6 предоставит возможность использования значительно большего пространства имен, что вновь вернет каждому устройству уникальный адрес и сделает NAT ненужным, позволяя установить соединение между 2 игроками вне зависимости от их установок. (Прим. но как по мне, это все далекое будущее, по диаграммам Гугла сейчас IPv6 принят только в 3 процентах случаев, да и то не в России).


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

Сигнальный сервер по-настоящему не является хостом для игр. Первый игрок в комнате является хостом и передает данные другим пирам. Сигнальный сервер - это просто центральное место для игроков, куда следует идти, чтобы найти друг друга. Когда пир хочет присоединиться к хосту, то сигнальный сервер транслирует информацию о IP адресе и детали связи между двумя. Как только пир успешно соединяется с хостом, сигнальный сервер больше не подключен и игроки обмениваются информацией друг с другом напрямую.

У Scirra есть свой собственный доступный для всех сигнальный сервер на wss://multiplayer.scirra.com. wss означает защищенное WebSocket соединение, так как данные транслируются через WebSockets. Игры сами по себе запускаются через WebRTC.

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

Сигнальный сервер сначала сортирует пользователей по каждой игре. Ваша игра должна иметь свой уникальный номер на сервере. Потом каждый пользователь вашей игры присоединяется к к этой игре на сервере. Это позволяет отделить пользователей вашей игры от пользователей других игр, которые работают в совсем другом режиме. Для каждой игры, которую вы создаете, вам следует использовать одно имя на сервере. Для того, чтобы удостовериться в том, что имя вашей игры уникально на сервере, включите в состав имени имя вашей компании или ваш псевдоним, например, "MyStudio-Asteroids" или "JohnSmith-Asteroids" вместо "Asteroids". Это имя не будет показываться нигде. Оно будет использоваться только внутри сигнального сервера, поэтому чувствуйте себя свободным в придумывании сложных уникальных имен.

После этого, сигнальный сервер, распределяет игроков по игровым экземплярам. Это позволяет вам запускать различные изолированные экземпляры вашей игры. Например, вы хотите иметь стабильный экземпляр, к которому будут подсоединяться большинство игроков и бета-экземпляр, к которому будут подсоединяться тестеры. Это предотвратит смешение бета тестеров и игроков, для которых могут быть предоставлены разные игровые механики и возможности. По этой же причине экземпляры могут иметь версии, например, "v1.0", "v1.1", "v1.2". Это предоставит возможность соединять только пользователей с одинаковыми версиями игры. Еще одна хорошая практика заключается в том, чтобы иметь экземпляры, распределенные по континентам, например, "Europe", "North America" и "Asia". В этом случае, пользователи будут подключаться только к своему региону, увеличивая шанс на качественное соединение. Может быть скомбинировано с версиями игры, например, "Europe-v1.1", "Europe-v1.2" и так далее.

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

В объекта Мультиплеер Констракта все действия, условия и выражения, относящиеся к сигнальному серверу, находятся в категории Signalling. Все остальные возможности относятся непосредственно к игре.

Хаос интернета

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

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

Многопользовательские игры были бы намного проще, если быть все соединения были бы почти мгновенными. Например, как локальные (LAN) внутри вашего дома или офиса. Однако интернет феноменально сложен. Между любыми 2 игроками может быть 10-20 сетевых устройств (таких как роутеры). Эти устройства отличаются друг от друга для каждой пары игроков.Для каждого отдельного посланного сообщения, каждое устройство по маршруту следования должно получить входящий пакет данных, прочитать и понять его направление, однозначно определить куда его передавать дальше и передать дальше. Более того, если вы соединяетесь с игроком через океан, то ваши данные будут путешествовать по кабелям под тощей океана, что дает экстраординарные количества траффика.

Пример соединения между двумя пирами.
Изображение

Удивительно, но каждое устройство по маршруту часто передает входящий пакет следующему за миллисекунды. Однако с ростом количества передач по маршруту, особенно в случае, если некоторые из устройств работают под высокой нагрузкой, появляются задержки. У этих устрйоств, как и у любых компьютером могут быть поломки, недостаток памяти, потеря питания, баги, которые могут влиять на сервис, и так далее. Посредством впечатляющих инженерных решений роутеры часто могут изменять маршрут в обход устройств, перешедших оффлайн или пускать по альтернативному более быстрому пути. Все это может приводить к временным или постоянным изменениям времени прохождения сообщения из пункта А в пункт Б.

Также следует принимать во внимание законы физики. Если игрок из Лондона (Англия) соединяется с игроком из Сиднея (Австралия), то данные должны пройти приблизительно 17000 км. Путешествие по прямой со скоростью света это должно занять 57 миллисекунд. Физически невозможно передать данные быстрее этого. Кабели по этому пути не идеально прямы и между точками много роутинговых устройств.

Качество соединения.
Это те измерения, которые могут быть сделаны для определения качества соединения. Включает задержку (latency), packet delay variance (PDV), packet loss and bandwidth.

Задержка (latency, ping)
Как результат наличия законов физики и роуторов, для каждого сообщения, посланного через интернет, должно пройти определенное количество времени, прежде чем оно придет к адресату. Время передачи называется задержкой (latency) или временем пинга (ping time). Обычно находится в пределах 20-200 миллисекунд для любых заданных игроков в мире, хотя может и выходить за эти значения. Игра обычно работает на 60 кадрах в секунду, что означает, что кадр занимает 16 миллисекунд. Задержка в 100 миллисекунд означает, что игра будет впереди на 6 кадров прежде чем сообщение будет получено.

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

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

Вариативность в задержке передачи пакетов (Packet Delay Variance (PDV))
Еще одна проблема с задержкой заключается в том, что она может быть различной для каждого сообщения. Если 2 сообщения посланы по интернету, одно может достигнуть адресата за 50 миллисекунд, а второе за 70. Это называется вариативностью задержки передачи пакетов (Packet Delay Variance (PDV)). В констракте она измеряется как наибольшая задержка минус самая маленькая задержка между несколькими последними измерениями. В нашем случае она будет равна 20 (70-50). Высокий уровень PDV - это хуже, чем высокий уровень задержки. Движок мультиплеера на основании истории передачи пакетов пытается скомпенсировать время задержки. Высокая степень задержки с низким PDV означает, что предсказания о времени прибытия пакета будут сравнительно точными и и компенсация будет аккуратной. Маленькая задержка и высокий PDV означает, что компенсация будет иногда неаккуратной, что будет провоцировать нестабильный геймплей так как движок мультиплеера будет вынужден вносить коррекционные процедуры, сводящие на нет преимущества низкой задержки.

Потеря пакетов (Packet loss)
Сообщения также могут быть полностью потеряны. Если роутеры по пути следования пакета перегружены или испытывают иные проблемы технического характера, они могут направить сообщение по оптимального пути, а могут выкинуть сообщение. Процент утраченных в ходе передачи сообщений называется потерей пакетов (packet loss). Движок мультиплеера может с легкостью компенсировать единичные потери, но если потеря пакетов высока, то качество геймплея может начать страдать.

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



Пропускная способность (Bandwidth)
Наконец, пропускная способность задает общее количество данных, которые могут быть пересланы. Все интернет соединения имеют максимальный размер загружаемых и выгружаемых данных, часто измеряемый в мегабитах в секунду. Так как в байте 8 бит, то деление этого числа на 8 даст вам значение в мегабайтах. Например, 40 мегабит в секунду позволяет теоретически передавать 5 мегабайт в секунду. Однако обратите внимание, что скорость загрузки может отличаться и как правило меньше, чем скорость выгрузки в большинстве пользовательских сетей.

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

Компенсация условий сети.
Для того, чтобы минимизировать влияние пропускной способности и поттери пакетов, по умолчанию, движок мультиплеера передает данные 30 раз в секунду. Игры обычно обрабатывают 60 кадров в секунду, поэтому это означает, что обновление идет раз в два фрейма.

Компенсация для пиров.
Пиры будут получать данные от своего хоста, которые будут завдать, к примеру, их позицию. Если они будут просто оттображать то, что они получают, то движения объектов будет прерывистым и неравномерным из-за обновлений раз в 2 кадра и влияния потери пакетов и PDV (см. выше).
Для решения этой проблемы движок мультиплеера интерполирует полученные данные для таких значений как координаты. В случае с положением, это будет линейная интерполяция между обновлениями. Например, если данные приходят раз в 2 кадра, то в кадр, когда не будет никаких полученных данных, движение будет в половину разницы между 2 предыдущими. Это делает движение более гладким без необходимости пересылать какие-либо дополнительные данные.

Однако при рендеринге интерполированного кадра, движок не знает еще пока следующего значения, потому что оно придет только в будущем. Вместо использования машины времени, движок решает это при помощи искусственной задержки в 80 миллисекунд для каждого пира. Это означает, что движок знает о нескольких следующих обновлениях до того момента, как их надо выводить на экран. Даже если следующее обновление пропущено из-за потери пакета, можно использовать следующее обновление и интерполировать относительно него. Даже при плохом интернет соединении, движок может продолжать экстраполировать значения между 2 предыдущими обновлениями. Не всегда точно, потому что в этом случае перед нами лишь работа с предположениями.

Многопользовательский движок позволяет использовать 3 возможных режима интерполяции для значений: линейная (для позиций объектов), угловая (для углов объекта) и "отключить" для значений, которые не должны быть интерполированы (например, булевы значения).

Вариации в задержке.
Задержка может отличаться. Например, маршрутизатор на пути следования пакета может казаться перегружен, и данные между 2 игроками внезапно окажутся перенаправленными по другому более медленному пути; или, наоборот, откроется более быстрый путь. Задержки также часто сокращаются в первую минуту после соединения, как только устройства по пути следования сигнала оптимизируют соединение по самому быстрому пути. Время задержки постоянно повторно измеряется для обнаружения такого рода задержек.

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

Компенсация для хоста.
Хост имеет авторитарную версию игры с нулевым уровнем задержки, так как ему нет необходимости передавать данные себе. Другими словами, хост участвует в реальной игре, а пиры получают данные от него с небольшой задержкой, поэтому хост имеет небольшое преимущество перед ними.
Вы можете подумать, что хосту необходимо интерполировать между обновлениями позиции объектов, которые он получил в ходе 2 последних обновлений от пиров. На практике этого как правило не допускается, потому что пиры не должны сообщать хосту-игроку где они о избежании читинга.


Предотвращение читинга.
Если пиры сообщают хосту, где они были и что они сделали и хост им доверяет, то пиры могут обманывать хост. Они могут просто неожиданно послать данные, говорящие, что они находятся по другую стороны стены или атакуют игрока, когда по правилам не могут этого сделать в силу текущих условий. Во избежание этого, пиры просто сообщают хосту данные от своих устройств ввода, например, какие клавиши стрелок они нажали. Хост получает эти данные и начинает двигать игрока, посылая данные обратно и демонстрируя пирам, где они по его мнению находятся.
В связи с этим появляется проблема добавления задержки между вводом и реакцией объекта на ввод. Если пользователь нажимает Влево, а задержка у нас 100 миллисекунд, то через 100 информация дойдет до хоста, а еще через 100 обратно, то пользователь будет чувствовать ощутимый лаг в работе приложения. Для решения этого предусмотрено локальное предсказание ввода.

Локальное предсказание ввода (Local input prediction)
С учетом этого, при нажатии влево, мы отсылаем информацию от ввода на хост и, не дожидаясь ответа, начинаем двигаться влево. Игрок получает контроль над происходящим в режиме реального времени и по-прежнему не может читинговать.

Однако, игрок-пир будет неизбежно дрифтовать относительно той позиции, на которой видит его хост. Это происходит из-за множества мелких ошибок, которые возникают из-за сетевого тайминга, синхронизации скорости смены кадров и так далее. Пир все еще получает сообщения от хоста, но они отклоняются. В предыдущем примере, пир получает позицию от хоста с общей задержкой в 200 миллисекунд. Для того, чтобы скорректировать отклонения, движок мультиплеера смотрит в историю объекта и сравнивает с тем, где он был 200 миллисекунд назад. Другими словами, коррекции делаются, с учетом того, где объект был в прошлом, принимая во внимание задержку относительно хоста. Если объект находится в неправильном месте, то движок мультиплеера незначительно сдвигает его для компенсации. Это делается не слашком часто, чтобы сделать как можно менее заметным. В экстремальных условиях сильная и заметная коррекция будет необходима, но в уловиях стабилььного быстрого соединения этого не потребуется - будут необходимы только небольшие незаметные коррекции.

Предсказания ввода для пиров не ограничиваются только предсказаниями положения. Движок имеет возможность все эти манипуляции в любой переменной.

Лаг.
В условиях плохого интернет соединения могут возникать серьезные дефекты геймплея, известные как лаги. Рваное движение, прыжки и чрезвычайно нерегулярное обновление, пользователь может резко менять позицию ил условия могут оказаться неравными для двух игроков. К сожалению, нет хорошего решения для того, чтобы избежать этой проблемы за исключением более качественного соединения. Эти проблемы возникают как правильно только из-за значительной потери данных (например, в течение нескольких секунд) или внезапного сильного изменения задержки или PDV. В таких случаях почти невозможно компенсировать эти дефекты соединения. Часто это просто реальность соединения через интернет.

Компенсация лагов.
Представим, что у нас есть следующая проблема: игрок А стоит и целится в игрока Б, который бежит вправо. Игрок А наводит мышь точно на игрока Б и стреляет. Представим, что выстрел мгновенный (например, лазер). Сообщение, посылаемое на хост, указывающее на выстрел идет на сервер 100 миллисекунд. В это время игрок Б продолжает двигаться направо. Хост получает сообщение через 100 миллисекунд и тестирует на столкновение. После теста, оказыввается, что игрок А промахнулся, потому что игрок Б двигался.
В общем случае хост видит действия каждого игрока несколько позже из-за задержки и игроки промахиваются мимо движущихся мишеней. Для того, чтобы попадать, надо целиться несколько впереди цели. Ряд пользователей этого принять не может. Специально для их обостренного чувства реализма придумана техника компенсации лагов.

Перемотка времени
Хост знает, как далеко каждый игрок видит игру, потому что измеряет время задержки для каждого пира. Поэтому когда хост получает сообщение, указывающее, что игрок А выстрелил, он знает, что в действительности тот сделал это 100 миллисекунд назад. Хост запоминает несколько прошедших секунд из истории каждого объекта и может посмотреть, что делал объект Б 100 миллисекунд назад. Дальше он может протестировать столкновение относительно момента выстрела и выдать более правильное значение.

Компенсация лагов в многопользовательской игре.
Это вызывает и другу проблему. Игрок Б также имеет задержку. Если у него 100 мс задержка, то хост передвигает их на 100 мс назад от того места, где они себя видят (помните о их локальном предсказании ввода?). Это означает, что игрок Б видит игрока А, который целится позади него и должен по идее промахнуться, но тот стреляет и попадает. Это раздражает игрока Б, но это, как правило, лучше, чем не иметь компенсации совсем, потому что позволяет целиться и попадать туда, куда целился.

Как много игроков могут присоединиться к одной игре?
Ограничение на то, сколько игроков может присоединиться к игре задается пропускной способностью загрузки хоста. Движок не накладывает лимитов сам по себе. Проблема в том, что хост посылает сообщение с данными для N игроков, для каждого из N игроков. Например, если хосту требуется послать 16 байт данных каждому игроку, то каждое сообщение будет иметь размер N*16, а потому это сообщение будет послано N раз.
Для 10 игроков обновление будет весить 16*10*10 = 1600 байт.
Для 20 = 16*20*20 = 6 400 байт.
Для 30 = 16*30*30 = 14 400 байт.
Для 100 = 16*100*100 = 160 000 байт
Даже несмотря на то, что количество игроков увеличивается линейно, требования к пропускной способности увеличиваются в квадрате. Это означает, что даже с помощью значительно более мощных серверов или уменьшением размеров пакета для игрока, это не даст вам большого количества дополнительных игроков онлайн.
По умолчанию обновления посылаются 30 раз в секунда, поэтому последний пример со 100 игроками будет требовать пропускную способность 40 мегабит в секунду. Это очень большое значение для домашнего соединения, но не требует выделенного сервера. Более того, хосту требуется запускать игру для большого количества игроков, выполнять вычисления по компенсации артефактов соединения, которые могут быть в значительной мере интенсивными. Также надо обновлять игру для хоста, если он участник. Обычно общее количество работы резко увеличивается с увеличением количества игроков и хотя и зависит от вида игры или соединения, все же редко подходит к 100 игрокам в одной игре.


Контролирование форматов обновлений.
Возможно выбрать точный формат значений, передаваемых движком мультиплеера. Правильное использование опции помогает значительно снизить требования к пропускной способности хоста без значительного эффекта на точность геймплея. Позволяет более эффективно использовать сеть, увеличивая количество игроков, которые могут присоединиться.
Типы чисел, которые вы можете использовать в Констракт:
1) Высокая точность = High (double, 8 bytes): число с плавающей точкой двойной точности, которое может содержать числа без влияния на их точность. Имеет 15-17 значимых знаков. Но требует 8 байт на одно число. на практике не следует использовать это во избежании перегрузки канала.
2) Нормальная точность (float, 4 bytes):число с плавающей точкой, имеет 6-9 значимых символов. Более практично чем double, потому что занимает вдвое меньше места, а вся информация, находящаяся после 6 символов после запятой не так уж и важна обычно для практических целей.
3) Низкая точность = Low (int16, 2 bytes): 16 битное целое число в диапазоне от -32768 до 32767.
4) Очень низкая = Very low (uint8, 1 byte): 8-битное целое число от 0 до 255.
Для минимизации нагрузки на пропускную способность, важно выбирать как можно более низкую точность. Для координат достаточно часто использовать низкую точность (целые числа). Так как макет меньше, чем 32767x32767 (это очень много), и субпиксели округляются, то этого достаточно для эффективного использования.
Два последних значения полезны для входных данных пиров, которые они посылают хосту. Используя выражения setbit, getbit and togglebit в Construct 2, вохможно поставить индивидуальные биты для этих чисел. Если игра использует 4 клавиши стрелки для передвижения и пробел для выстрела, то у нас только 5 контрольных клавиш, которые могут быть сохранены в 8 битах, где 0 - не нажато, а 1 - нажато. Потом хост может прочитать этот бит и симулировать нужную клавишу. Это может быть сделано при помощи 1 байта, или 2 байт (int16), если у вас больше 8 клавишей контроля. Также и хост может посылать множественную информацию в одном сообщении.

Плагин многопользовательского режима в Construct 2.
В общем многопользовательская игра в Костракте выглядит следующим образом.

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

Обратите внимание, что игра заканчивается, если у хоста дисконнект. Он рассматривается как сервер для игры, поэтому если у него дисконнект, то игра больше не продолжается. Это причина для запуска специального хоста на отдельном центральном сервере. Важно для больших игр. Не важно для игр с сессиями для 2 игроков - если один из них покидает игру, то игра все-равно по логике заканчивается.

Плагин мультиплеера имеет возможности покрытия сигнальной фазы (шаги 1,2), также как и возможности, связанные с комнатой внутри игры, такие как триггера "когда пир присоединился к игре" или "покинул игру" или "когда сообщение получено" и так далее.

Обзор проекта.
Подразумевается, что у вас один объект, который представляет как самого игрока, так и всех остальных игроков в игре. Этот объект используется всеми пирами и хостом. Мудро будет обозвать его Peer, чтобы дотянуться до его сути. Если у вас есть игрок, состоящий из множества объектов, например, ружья, тела, то сделайте базовый объект пира и поместите в контейнер все остальные объекты. Это даст уверенность, что игрок будет создаваться полностью со всем комплектом и все объекты, связанные с контейнером будут автоматически выбираться в собтиях с базовым объектом.

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

Действие мультиплеера Sync object - это фундаментальный способ для указания, что вы хотите послать данные об объекте по сети. Он говорит хосту послать информацию об этих объектах пирам и говорит пирам подождать получения информации об этих объектах. Движок автоматически создает и разрушает объекты, которые представляют пиром, когда они подключаются и покидают. Также это действие может быть использовано для других объектов, не являющихся аватарами пиров.

Каждый пир имеет идентификатор Peer ID, присвоенный сигнальным сервером. Это строка, которая короткой последовательностью случайных символом уникально идентифицирует их. Peer ID в общем случае используется для ссылки на конкретного игрока, даже если его имя сменилось. Peer ID необходимо сохранять в переменной, так чтобы знать, какого пира представляет данный объект. Когда объект пира создается при помощи движка, то выражение Multiplayer.PeerID expression устанавливается к peer ID, так чтобы его можно было сохранить как переменную.

Режимы надежности.
Последняя вещь для упоминания на сегодня: есть 3 режима передачи данных. Они устанавливают разное соотношение между надежностью и производительностью.
Наиболее надежный режим - это Reliable ordered. Он посылает сообщение и отслеживает его доставку. Если оно было отброшено, то он будет посылать сообщение до тех пор, пока оно не прибудет. Сообщения также выставляются в определенном порядке, что гарантирует, что они прибудут в том же порядке, в каком были посланы. Полезно, но не очень быстро: если одно сообщение было послано и выброшено, то следующее не будет передано, пока не пройдет это. Это полезно только для важных сообщений с низкой частотой, например, чата.

Промежуточный режим - это Reliable unordered. Посылает сообщения до того момента, как оно не будет получено, но не выстраивает в порядке. Полезно для игровых событий, которые должны придти, но не связаны друг с другом, например, открытие двери или взрыв.

Самый быстрый режим - это Unreliable. Посылает одно сообщение и забывает о нем. Если оно было выброшено в процессе передачи, то оно просто никогда не дойдет до адресата. Предназначено для регулярных сообщений, в которых важнее скорость передачи сообщения, чем то, придет ли оно вообще. Если оно будет выброшено по дороге, то его сменит следующее с более свежими данными. Обратите внимание, что движок автоматически использует этот режим для синхронизированных объектов со встроенной интерполяцией и компенсационными возможностями, потому нет необходимости повторять эту функциональность вручную этим режимом.

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

Новые туториалы скоро появятся!
Аватара пользователя

Игродел
Сообщений: 49
Я тут с 07 фев 2014
Откуда: Санкт-Петербург, Москва
Репутация 61 [ ? ]

Сообщение Мультиплеер
» 04 мар 2014, 10:44

:clapping: Аплодисменты! :biggrin:
Крайне полезная статья.
Аватара пользователя

Игродел
Сообщений: 226
Я тут с 11 фев 2013
Откуда: Россия, О. Сахалин
Skype: Seryiza
Репутация 184 [ ? ]

Сообщение Мультиплеер
» 04 мар 2014, 11:51

по ходу классный плагин готовят)
ИзображениеИзображениеИзображение
лучший ХОСТИНГ<= промокод SPBP20017462

лучший КОШЕЛЕК<= это PAYEER
Аватара пользователя
ab

Администратор
Сообщений: 772
Я тут с 06 сен 2012
Репутация 109 [ ? ]

Сообщение Мультиплеер
» 04 мар 2014, 12:19

отличная статья, вот только картинок из оригинала нехватает
Аватара пользователя

Администратор
Сообщений: 2406
Я тут с 06 сен 2012
Откуда: Санкт-Петербург, Южно-Сахалинск
Skype: sirg1987
Репутация 268 [ ? ]

Сообщение Мультиплеер
» 18 мар 2014, 18:20

Это статья, а не урок. Следует перенести в Новости Construct 2.
если помог, то поставь +1 к репутации.
Аватара пользователя

Участник
Сообщений: 77
Я тут с 28 авг 2013
Skype: prodacshen3d
Репутация 7 [ ? ]

Сообщение Мультиплеер
» 18 мар 2014, 20:08

nikita3462 писал(а):Это статья, а не урок. Следует перенести в Новости Construct 2.

нормально она тут лежит. у нас этот раздел и для статей тоже подходит. здесь гдето была еще статья по оптимизации игр
Аватара пользователя

Администратор
Сообщений: 5820
Я тут с 05 сен 2012
Двиг: Construct2
Лицензия: Personal
Skype: c2community
VK: gabrielsailergray
Репутация 392 [ ? ]

Сообщение Мультиплеер
» 02 янв 2015, 19:36

Спасибо! Прочитал статью, теперь понял основные моменты в разработке игр с мультиплеером. :good2:
Изображение
Аватара пользователя

Участник
Сообщений: 5
Я тут с 02 янв 2015
Откуда: Санкт-Петербург
Skype: cs_snickers
Репутация 0 [ ? ]

Сообщение Мультиплеер
» 04 янв 2015, 21:17

Всем привет, я прочитал все мануалы по мультиплееру, но сделать его у меня так и не получается так как у меня управление другое да и когда делал копию примера тоже ничего не вышло, возможно есть люди которые могу помочь с мультиплеером, уже мозг кипит! :scratch_one-s_head:
Аватара пользователя

Участник
Сообщений: 10
Я тут с 13 дек 2014
Репутация 10 [ ? ]

Сообщение Мультиплеер
» 04 янв 2015, 21:20

Какое др. управление?
Аватара пользователя

Участник
Сообщений: 9
Я тут с 20 дек 2014
Репутация 1 [ ? ]

Сообщение Мультиплеер
» 04 янв 2015, 22:37

При нажатии в любую точку экрана ставится маркер, и корабль начинает двигаться к этой точке, я сейчас сделал у меня где хост появляется почему 2 корабля, и когда подключаюсь пиром в экране где хост все эти корабли двигаются к этому маркеру, в окне пира 2 корабля и пир пытается двигаться к маркеру но он дёргается на месте, вот в этом и проблема! также не отображается поворот корабля =( уже всё передала и ничего не меняется как есть так и остаётся =(
Аватара пользователя

Участник
Сообщений: 10
Я тут с 13 дек 2014
Репутация 10 [ ? ]



Вернуться в Другие уроки по Construct 2

Сейчас эту тему просматривают

Зарегистрированные пользователи: нет зарегистрированных пользователей

Наверх