Создать трекер клиента P2P игры
Сейчас я занимаюсь созданием сетевой игры с использованием P2P. Игра не такая высокая, и у меня нет доступа к выделенному серверу, поэтому P2P мне кажется хорошим выбором. У меня есть доступ к интернет-домену. Программирование выполняется на C ++.
Не обращая внимания на опасности Game Networking, я подумал, что P2P не нуждается ни в каком виде централизованного взаимодействия с сервером. Тогда я подумал: «Но как же я могу найти других пользователей игры, принимающих игру, не зная их IP?». Теперь я думаю, что мне нужен какой-то центральный «хаб», к которому игра может подключиться, чтобы получить список доступных одноранговых хостов с их IP-адресом и портом. Затем он подключится к этому хосту и отправит данные по протоколу UDP (я знаю, что он без соединения, но, похоже, у ENet есть для этого некоторые хитрости). Если моя идея полностью абсурдна, то дайте мне знать.
У меня была идея сделать очень простой PHP-клиент-IP-switch-thingy в моем онлайн-домене. Игра не привлечет более 2-3 человек, потому что она предназначена только для моих личных целей обучения, поэтому, думаю, нагрузка на этот домен не будет слишком большой проблемой. Проблема в том, что я не могу найти какую-либо полезную информацию о создании чего-либо подобного с использованием PHP. Я пытался просмотреть «похожие вопросы», но я все еще не могу найти много информации.
Мой вопрос к вам: как я могу создать трекер клиента / хоста для игры на PHP, если это вообще возможно? Знаете ли вы какие-либо хорошие сайты или статьи по этому поводу?
Кстати, я хочу использовать комбинацию ENet и SFML, ENet для надежного пакета UDP и SFML для компоновщика пакетов. Это жизнеспособный выбор?
Решение
Как всегда, несколько вариантов приемлемы для того, что вы хотите сделать.
Использовать P2P-соединения сложно, но может быть очень эффективно, особенно в таких областях с малой задержкой, как VOIP и многопользовательские онлайн-игры.
Я думаю, что вам нужно будет выставить сервер, который будет обрабатывать информацию и состояния, связанные с подключенными игроками. Я бы порекомендовал использовать C++ для этой части и boost::asio для сетей, так как вы найдете множество хорошо объясненных примеров, использующих эти два, вы также можете найти их очень надежный и масштабируемый Но это в конце, безусловно, зависит от вас.
Этот компонент должен принимать входящие соединения от игроков, которые хотят присоединиться или создать игру. Он будет содержать список игр и пользователей, подключенных в настоящее время, и сделает их доступными для новых входящих игроков.
Довольно просто, не правда ли? Теперь вам нужно выбрать игровую архитектуру. Выборы здесь используют P2P связь между игроками или использование вашего сервера в качестве прокси между игроками.
Сервер как прокси
Сервер, содержащий информацию о каждой игре и игроках, может использоваться для пересылки соединений между игроками. Это довольно неэффективно с точки зрения масштабируемости и производительности, потому что вы создаете единственную точку отказа, которая является вашим сервером, но, поскольку ваши требования к этому домену невысоки, это может быть вариантом для вас.
В этом случае сервер может принять новое соединение (например, на другом сокете), когда игрок хочет присоединиться к игре и транслировать сообщения всем остальным игрокам, чтобы все в игре могли получать рекламу, когда другой игрок присоединяется, перемещается, стреляет …
Одноранговое соединение
Это немного сложнее. Сервер всегда будет служить для определения того, какие игроки и игры существуют в настоящее время, но вместо того, чтобы отвечать за управление связями между самими пользователями, он может просто сказать игроку, который хочет присоединиться к игре: «Эй, ты собирается присоединиться к новой игре, если вы хотите, пожалуйста, свяжитесь с 10.20.30.40«. Это было бы общественности IP-адрес парня, «размещающего» игру.
Затем вы столкнетесь с первой большой трудностью. Как вы собираетесь общаться с этим хостом, если он за роутером? Вам нужно будет реализовать возможности NAT-traversal на стороне клиента, чтобы позволить входящему игроку добраться до компьютера, на котором размещена игра, между его маршрутизатором.
Некоторые методы используются приложениями VOIP для решения этой проблемы (например, Skype), когда они используют UPnP's IGD (Internet Gateway Device) попросить маршрутизатор открыть и перенаправить какой-либо порт на нужный компьютер. Это сложно, потому что это занимает время и не реализовано на каждом маршрутизаторе, поэтому это может привести к полному отказу. Ради этого примера, скажем, мы можем легко преодолеть эту проблему и перейдем к следующему.
При подключении к компьютерному хостингу игры вы можете спросить его, какие другие игроки также подключены к игре, и объявить других игроков, к которым вы подключены в данный момент.
Идея состоит в том, чтобы каждый игрок в матче говорил друг с другом об обновлениях (опять же, это были бы ходы, выстрелы, личные сообщения или что-то еще), чтобы синхронизировать каждого игрока (и поверьте мне, что они не будут) , Вы также можете реализовать алгоритм упорядочения пакетов (предпочтительно с использованием UDP или ENet), в котором вы будете определять, как реклама и сообщения будут транслироваться другим игрокам.
Возьмем, к примеру, матч, к которому подключены 4 игрока. Есть хозяин боб, Алиса его сосед, Том парень, живущий в Нью-Йорке и Майк другой парень нам нужен для целей этого примера.
Алиса сначала подключается к игре Боба, она сообщает Бобу, что присоединилась к его игре, при каждом обновлении Боб и Алиса обмениваются информацией о текущем состоянии матча. Теперь приходит Том и говорит Бобу, что он новый игрок, Боб говорит Тому, что к нему подключен еще один игрок, и дает ему свой IP-адрес (Алиса). Теперь Боб сообщает Алисе, что кто-то подключен, и дает ей свой IP-адрес. Вообразите, что Боб умирает, Боб скажет Алисе, что он умер, потому что он привык говорить с ней прежде, чем Том начнет действовать, и теперь Алиса должна сказать Тому, что Боб только что умер.
Вы можете просто сделать так, чтобы все игроки транслировали каждому игроку каждую рекламу, но это было бы довольно большим объемом данных для обработки и не настолько масштабируемым, учитывая количество игроков в матче. Используя график общение в среде P2P может быть гораздо более эффективным, но объяснение может занять гораздо больше, чем просто минуты.
Я дал вам свою точку зрения на эти методы, используйте классическую архитектуру клиент-сервер, если вы хотите оставаться простым, учитывая нагрузку, с которой вам придется справиться, это будет более чем приемлемо.
Наслаждаться 😉
Другие решения
Других решений пока нет …