Меня интересует, как протоколы (и игровой цикл) работают для игр такого типа; любые указатели или идеи приветствуются.
Я предполагаю, что основной цикл будет иметь состояние мира, которое будет продвигаться на несколько «тиков» в секунду, но как выполняются команды игроков? Какие данные должны передаваться туда и обратно?
Я могу рассказать об этом много подробностей, но сначала прочитайте «1500 лучников» http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php, и это ответит на многие ваши вопросы. Вот краткое изложение: во-первых, большинство игр используют UDP из-за характера игры в реальном времени. Игровой цикл выглядит примерно так:
Это значительно упрощено, и «возиться с физикой» легко может стать 200-страничной книгой, но это включает в себя предсказание на стороне клиента, где что-то может быть, получение данных с сервера, который устарел, но точно сообщает, где объект был/должен быть. быть, а затем каким-то образом интерполировать эти значения, чтобы объект выглядел «достаточно близко» к тому месту, где он на самом деле должен быть, что никто не замечает. Это очень важно для шутеров от первого лица, но не так важно для стратегии в реальном времени.
Для стратегии в реальном времени обычно используется пошаговая система, в которой время разделено на дискретные отрезки, называемые «ходами», которые происходят последовательно, и каждый ход имеет число, генерируемое монотонной функцией, которая гарантирует постоянное увеличение значений в определенном порядке без дубликаты. На любом заданном ходу n каждый клиент отправляет сообщение всем другим клиентам с их предполагаемым действием на ходу n + m, где m — произвольное число, которое обычно довольно мало и может быть лучше всего определено методом проб и ошибок, а также игровым тестированием. Как только все клиенты отправили свои предполагаемые действия, каждый клиент выполняет все действия, которые были отправлены на ходу n + m. Это приводит к небольшой задержке при заказе действия пользователем и при его выполнении, однако обычно это незаметно.
Есть несколько методов, которые можно использовать, чтобы обмануть время. Например, если вы выделите юнит, а затем скажете ему двигаться, он издаст звук и будет иметь анимацию, когда начнет двигаться, но на самом деле не тронется сразу. Однако сетевое сообщение о намерении переместить этот юнит отправляется немедленно, поэтому к тому времени, когда экран отвечает на ввод игрока, сетевые сообщения уже отправлены и подтверждены. Вы можете еще больше схитрить, введя небольшую задержку (около 100 мс) между щелчком мыши и ответом игрового объекта. Обычно это незаметно для игрока, но 100 мс — это целая вечность в игре по локальной сети, и даже при широкополосном соединении на домашнем компьютере средний пинг, вероятно, составляет около 15-60 мс или около того, что дает вам достаточно времени для отправки пакета до Движение.
Что касается данных для отправки, то в играх есть два типа данных: детерминированные и недетерминированные. детерминированные действия основаны на игровой физике, поэтому, когда действие начинается, есть 100% гарантия того, что я могу предсказать результат этого действия. Эти данные никогда не нужно отправлять по сети, поскольку я могу определить, какими они будут на клиенте, исходя из начального состояния. Обратите внимание, что использование генератора случайных чисел с одним и тем же начальным числом на каждом клиенте превращает «случайные» события в детерминированное поведение. Недетерминированные данные обычно являются вводом пользователя, но во многих случаях можно предсказать, каким может быть ввод пользователя. В стратегической игре в реальном времени они сочетаются друг с другом так, что недетерминированное событие является своего рода приказом одному из моих игровых объектов. После того, как игровому объекту было приказано двигаться, способ его движения становится на 100% детерминированным. Таким образом, все, что вам нужно отправить по сети, — это идентификатор объекта, заданная команда (сделайте это перечислением для экономии полосы пропускания) и цель команды (если она есть, поэтому заклинание может не иметь цели, если это заклинание). область воздействия, но у команды движения есть конечный пункт назначения). Если пользователь щелкает около 100 раз, чтобы заставить юнит двигаться, нет необходимости отправлять отдельную команду перемещения для каждого щелчка, поскольку все они находятся в одной и той же общей области, поэтому обязательно отфильтруйте это, так как это убьет ваш пропускная способность.
Еще один прием, позволяющий справиться с возможной задержкой между командой и ее выполнением, называется фильтром локального восприятия. Если я получаю приказ двигаться через некоторое время t после того, как приказ был отдан, я знаю, когда подразделение должно было начать движение, и я знаю его конечный пункт назначения. Вместо того, чтобы телепортировать юнит, чтобы доставить его туда, где он должен быть, я могу начать его движение позже, а затем возиться с физикой, чтобы немного ускорить его, чтобы он мог догнать его до того места, где он должен быть, а затем замедлить его обратно. поставить его в нужное место. Точное значение, которое вам нужно для ускорения, также относительно, и тестирование — единственный способ определить правильное значение, потому что оно просто должно «чувствовать себя правильно», чтобы оно было правильным. Вы можете сделать то же самое, стреляя пулями и ракетами, и это очень эффективно для этого. Причина, по которой это работает, заключается в том, что люди не очень хорошо видят тонкие изменения в движении, особенно если объект движется прямо к ним или от них, поэтому они просто не замечают.
Следующее, о чем нужно подумать, это сокращение пропускной способности. Не отправляйте сообщения клиентам, которые не могут видеть движущееся устройство или взаимодействовать с ним. Не отправляйте одно и то же сообщение снова и снова только потому, что пользователь нажимает на него. Не отправляйте сообщения немедленно о событиях, которые не имеют немедленных последствий. Наконец, не требуйте подтверждения для событий, которые будут устаревшими, если их не удастся получить. Если я не получу обновление движения, к тому времени, когда я повторно передам это обновление, его значение будет настолько старым, что оно больше не будет актуальным, поэтому лучше просто отправить еще одно движение и использовать фильтр локального восприятия, чтобы догнать или использовать кубический сплайн для интерполяции движения, чтобы оно выглядело более правильным или что-то в этом роде. Однако критическое событие, такое как «вы мертвы» или «ваш флаг занят», должно быть подтверждено и передано повторно, если это необходимо. Я преподаю программирование сетевых игр в Digipen, так что не стесняйтесь задавать любые другие вопросы по этому поводу, и я, вероятно, смогу дать вам ответ. Программирование сетевой игры может быть довольно сложным, но, в конечном счете, все зависит от того, как сделать выбор в реализации и понять последствия своего выбора.
Посмотрите Битву за Веснот.
Это бесплатно, с открытым исходным кодом и совершенно потрясающе. Вы можете многому научиться, копаясь в его источнике.
Обсуждение сетевой архитектуры Age of Empires здесь
ИМХО, этот стиль одноранговой архитектуры, основанной на дублированном воспроизведении, впечатляет, но немного тупиковый для чего-либо более 8 или около того игроков.
