Мне интересно, как протоколы (и игровой цикл) работают для этих типов игр; любые указатели или идеи оценены.
Я предполагаю, что основной цикл будет иметь мировое состояние, которое будет иметь несколько "тиков" в секунду, но как выполняются команды игроков? Какие данные должны идти взад и вперед?
Я могу подробно рассказать об этом, но сначала прочитайте "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 здесь
IMHO, этот стиль одноранговой архитектуры с дублированием и воспроизведением впечатляет, но немного тупик для чего-то большего, чем 8 или около того игроков.