Сеть понг клон

У меня есть основы TCP-сокетов, UDP-коммуникаций и т. Д., Но я не могу найти много о том, как применить их в игровой среде в реальном времени.

У меня есть клон Pong с 4 игроками, и мне нужно синхронизировать позиции весла между тремя клиентами и сервером (сервер - четвертый игрок). В настоящее время я использую UDP для отправки обновлений в реальном времени (движения весла) и TCP для настройки игрового лобби и т. Д.

Это ПЛОХО, чтобы спамить огромные объемы UDP-трафика? Должен ли я взглянуть на что-то вроде DCCP для его функций заторов? Или это на самом деле не проблема с таким небольшим проектом?

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

Было бы лучше, чтобы клиенты сообщали друг другу о своих позициях весла друг с другом?

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

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

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

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

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

Что касается трафика - вы хотите избежать отправки более 20-30 пакетов в секунду на одноранговый узел. В общем случае, если вы отправляете меньшие и меньшие пакеты, вы будете испытывать (немного) меньшую задержку и меньшую вероятность потери пакетов.

Вы определенно не хотите отправлять обновления со скоростью, превышающей частоту кадров, поскольку игроки не смогут заметить разницу - действительно, если вы отправляете пакеты только 10 раз в секунду и интерполируете / экстраполируете результаты на принимающей стороне Большинство игроков не заметят разницы.

Это довольно широкий вопрос, но я постараюсь обобщить важные аспекты.

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

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

Для Понга я бы выбрал клиент / сервер, потому что это игра, ориентированная на действие. Здесь нужно отметить одну вещь, даже если вы говорите, что один игрок «является сервером», вам лучше структурировать свой код так, чтобы он по существу выполнял локальный сервер и подключался к нему как клиент.

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

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

Вы заботитесь об измене?

Если нет, переход в одноранговый режим сократит ваш лаг вдвое, так как это A <-> C вместо A <-> B <-> C. Если это так, для справедливости в синхронизации вы можете захотеть сделать ответ несколько медленным для локального игрока, или для того, что делает большинство игр - позвольте игроку делать все что угодно локально, а затем оглянуться назад, если результат сервера отличается от локально смоделированного.

Клон понг на самом деле немного сложнее, потому что в отличие от большинства игр, вы не можете (как разработчик) обмануть, когда одна сторона видит удар, а другая нет.

Что касается чего-то обобщенного, одна техника, о которой я слышал, но не нашел необходимой (хотя, возможно, и для экшн-игр), состоит в том, чтобы сохранять действия с их истинными временными метками (получать время - ping / 2) и откатывать сервер ( snap), если приходит событие более раннего времени, а затем повторно примените более поздние действия. Таким образом, все будут согласованы локально, если не будет конфликта из-за взаимодействия разных игроков. Единственная опасность - возможность «откатить время», если они имитируют слабую связь.

Гугл расплатился. Рассылка обновлений для 4 игроков не будет значительной. Объем отправляемых данных будет порядка байтов. Таким образом, это означает, что частые обновления должны быть в порядке. С мертвым расчетом вы перемещаете игрока на клиент и сервер. Сервер это авторитет. Когда положение клиента становится слишком несогласованным с сервером, оно должно вернуться к выравниванию. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking Использование UDP - это путь. Bupdates будут отправлены часто, что потерянные данные скоро будут заменены входящими данными в любом случае. Повторная передача пакета TCP не стоит позиции игрока. Посмотрите эту статью для получения дополнительной информации о том, как синхронизировать клиент и сервер.

Несколько недель назад я запрограммировал игру для 2 игроков в локальной сети, вот как я это сделал:

- Одна сторона открывает сервер, другая подключается автоматически. - Они оба рассылают спам по своему веслу x, положение по отношению друг к другу при 60 кадрах в секунду или меньше [UDP]. - Если одна сторона ударяет по мячу, они выбирают новые скорость и положение шаров и отправляют к другому [TCP] - если мяч пролетает мимо весла, игрок, пропустивший его, связывается с другим с сообщением об увеличении счета, и мяч сбрасывается [TCP] - мяч постоянно симулируется независимо, что подходит для простой физики мяча понг

Это создает примерно 0,3–0,5 КБайт / с трафика при 60 кадрах в секунду, и у игроков не возникает задержек в восприятии, но только в том случае, если пинг ниже определенного порога, поскольку необходимо передавать новую позицию шаров.

Также с этой системой легко обманывать, и есть высокая вероятность не синхронизироваться с очень потерянным соединением, но кого волнует обман в понге ?!