Какие проблемы возникают при реализации многопользовательских игр в реальном времени?
Обычно эта ошибка возникает, когда мы отправляем заголовок после эха или печати. Если эта ошибка возникает на определенной странице, убедитесь, что страница не выполняет эхо-сигналы перед вызовом start_session().
Пример непредсказуемой ошибки:
<?php //a white-space before <?php also send for output and arise error
session_start();
session_regenerate_id();
//your page content
Еще один пример:
<?php
includes 'functions.php';
?> <!-- This new line will also arise error -->
<?php
session_start();
session_regenerate_id();
//your page content
Вывод: не выводить символ перед тем, как вызывать функции session_start() или header(), даже не с помощью пробела или новой строки
5 ответов
- 'клиент-сервер' или 'одноранговый узел для пиринга' или что-то промежуточное: какой компьютер имеет полномочия над который игровые действия.
С основанными на повороте играми, обычно очень легко просто сказать, что 'сервер имеет окончательные полномочия, и мы сделаны'. С оперативными играми часто тот дизайн является великолепным местом для запуска, но как только Вы добавляете задержку, клиентское перемещение/действия чувствует себя безразличным. Таким образом, Вы добавляете своего рода 'сокрытие задержки' разрешение клиентского входа влиять на их символ или единицы сразу для решения той проблемы, и теперь необходимо заниматься проблемами согласования, когда клиент и серверы gamestate начинают отличаться. 9 раз из 10, что очень хорошо, Вы появляетесь или lerp объекты, на которые клиент влиял к авторитетной позиции, но что 1 из 10 раз, когда объект является аватаром плеера или чем-то, то решение недопустимо, таким образом, Вы запускаете, дают клиентские полномочия над некоторыми действиями. Теперь необходимо согласовать несколько gamestates на сервере и открыть себя до потенциального 'обмана' через злонамеренный клиент, если Вы заботитесь о такой вещи. Это в основном, где каждая teleport/dupe/whatever ошибка/обман подходит.
, Конечно, Вы могли запустить с модели, где 'у каждого клиента есть полномочия над 'их' объектами', и проигнорируйте проблему обмана (прекрасный в довольно многих случаях). Но теперь Вы уязвимы для крупного влияния на игровом моделировании, если тот клиент выбудет, или даже 'просто падает немного позади в не отставании от моделирования' - эффективно, то каждая игра плееров закончит тем, что/чувствовала эффекты отставания или в других отношениях неблагополучного клиента, или в форме ожидания отставания клиента для наверстывания, или в форме наличие gamestate, которым они управляют из синхронизации.
- 'синхронизировался' или 'asynchronus'
общая стратегия А гарантировать, что все плееры воздействуют на тот же gamestate, должен просто договориться о списке входов для плеера (с помощью одной из моделей, описанных выше), и затем иметь моделирование геймплея, теряют значение синхронно на всех машинах. Это означает, что логика моделирования должна соответствовать точно, или игры выйдут из синхронизации. Это на самом деле и легче и более твердо, чем это звучит. Это легче, потому что игра является просто кодом, и код в значительной степени выполняет точно то же, когда это, дают тот же вход (даже генераторы случайных чисел). Это более твердо, потому что существует два случая, где это не имеет место: (1) когда Вы случайно используете случайный за пределами Вашего игрового моделирования и (2) когда Вы используете плавания. Первый исправлен при наличии строгих правил/утверждений по тому, какие RNGs являются использованием какой игровые системы. Последний решен, не используя плавания. (плавания на самом деле имеют 2 проблемы, один они работают очень по-другому на основе конфигурации оптимизации Вашего проекта, но даже если это было разработано, они работают несовместимо через другой банкомат архитектур процессора, lol). Starcraft/Warcraft и любая игра, которая предлагает 'воспроизведение', скорее всего, используют эту модель. На самом деле наличие системы воспроизведения является отличным способом протестировать тот Ваш RNGs, остаются в синхронизации.
С асинхронным решением игровые государственные органы просто широковещательно передают то все состояние всем другим клиентам на некоторой частоте. Клиенты берут те данные и сбрасывают это на их gamestate (и обычно делайте некоторую упрощенную экстраполяцию, пока они не получают следующее обновление). Вот то, где 'udp' становится жизнеспособным вариантом, потому что Вы массово рассылаете весь gamestate, каждый ~1sec или так, отбрасывая некоторую часть тех обновлений не важен. Для игр, которые имеют относительно мало игрового состояния (землетрясение, World of Warcraft) это часто - простое решение.
Существует несколько факторов, вовлеченных в установку многопользовательского
-
протокол, важно, чтобы Вы решили, хотите ли Вы TCP или UDP. UDP имеет меньше служебное, но не гарантируется доставку. С другой стороны TCP более защищен. Каждая игра будет иметь их предпочтительный протокол. UDP, например, будет работать на шутер от первого лица, но не может подойти для RTS, где информация должна быть последовательна
-
Брандмауэр/Соединение. Удостоверяясь Ваша многопользовательская игра не должна устанавливать исходящие связи 2000 года и использует стандартный порт, таким образом, portforwarding легок. Взаимодействие через интерфейс с ним с брандмауэром окон, вероятно, будет добавленной премией.
-
Пропускная способность. Это важно, сколько данных Вы намереваетесь протолкнуть сетевое соединение? Я предполагаю, что это снизится для игры тестирования и записи пропускной способности. Если Вы требуете вверх 200kb/s для каждого клиента, можно хотеть заново продумать несколько вещей.
-
Загрузка Сервера. Это также важно, сколько обработки требуется сервером для нормальной игры? Вам нужны некоторые супер 8 базовых серверов с 16 ГБ RAM для выполнения его? Есть ли способы уменьшить его?
я предполагаю, что существует "куча" больше, но действительно Вы хотите игру, которая удобна для игры по сети и по множеству соединений.
TCP прекрасен если Ваше выполнение на LAN. Но если Вы хотите играть онлайн, необходимо использовать UDP и реализовать собственное подобное уровню TCP: необходимо передать маршрутизаторы NAT броска.
необходимо выбрать между Одноранговой или коммуникацией Клиент-сервер. В Клиент-серверной модели синхронизацию и состояние мира легче реализовать, но у Вас могло бы быть отсутствие реактивности онлайн. В Моче одноранговому узлу это более сложно, но быстрее для плеера.
не сохраняют историю действия плеера для игровой цели (сделайте это, но только для функциональности воспроизведения). Если Вы достигаете точки, где это необходимо, предпочтите, заставляют каждый плеер ожидать.
Планирование является Вашим лучшим другом. Фигура, каковы Ваши потребности действительно.
Загружающиеся Данные: каждый компьютер будет иметь те же модели и графику, и просто названия и местоположение отодвинуты сеть. Если каждый игрок может настроить их символ или другие объекты, необходимо будет переместить эти данные.
Обман: необходимо ли волноваться об этом? Можете Вы доверять тому, что говорит каждый клиент. Если не тогда Вы серверная логика будет выглядеть по-другому, чем Вы клиентская логика. Вообразите этот простой случай, у каждого из Ваших 10 плееров может быть различная скорость перемещения из-за взлетов питания. Для уменьшения обмана, Вы должны, чтобы вычислить, как далеко каждый плеер может переместиться между коммуникационными обновлениями с сервера, иначе плеер мог взломать, там убыстряются, и ничто не остановило бы их. Если бы плеер последовательно немного быстрее, чем ожидалось или имеет один переход времени, сервер просто изменил бы местоположение их в самом близком месте, которое было возможно, потому что это - вероятная расфазировка тактовых сигналов или одно прерывание времени в связи. Однако, если плеер постоянно перемещается дважды в максимально возможной степени тогда, может быть благоразумно вышибить их из игры. Чем больше математики, тем больше частей игры указывает, что можно проверить дважды на сервере, более последовательное, которым игра будет, случайно это сделает обман тяжелее.
, Как одноранговый узел для пиринга является этим: Даже если игра будет быть одноранговым узлом для пиринга с Вами, то вероятно, захочет сделать, чтобы один плеер запустил игру и использовал их в качестве сервера, это намного легче, чем попытка справиться с некоторыми более облачными подходами. Если нет никакого сервера тогда, необходимо работать протокол на решение споров между 2 машинами с непоследовательными игровыми состояниями.
Снова планированием является Ваш План лучшего друга, План, План. Если Вы думаете о проблеме достаточно, можно думать путь через большинство проблем. Тогда можно начать думать о тех, Вы еще не решили.
Как важный предотвращение обманывает? [Можно ли положить, что информация, прибывающая от клиента или им можно доверять и аутентифицировать?]
Объектная модель , Как объекты передаются от одной машины до другого? Как действия выполняются на объекте?
Вы делающий клиент/сервер или одноранговый узел одноранговому узлу?
Случайные числа , Если Вы, коллега для пиринга тогда с Вами должен сохранить их ступившими блокировкой и случайные числа синхронизируемый.
, Если Вы делаете клиент/сервер, как заключают Вас сделка с задержкой? [точный расчет?]
существует много нетривиальных проблем, вовлеченных в сетевое кодирование.
Выезд RakNet и это свободно загрузить код, и это - дискуссионные группы.