Что входит в создание многопользовательской платформерной игры в реальном времени?

Я создаю платформерную игру, которая имеет «кооперативную» функцию, с которой я бы хотел работать в сети / интернете.

Теперь я прочитал о программировании сетевых игр, включая такие статьи, как « Что должен знать каждый программист о сетевых играх», и поэтому я понимаю разницу между такими технологиями, как архитектура одноранговой блокировки и архитектура прогнозирования сервер-клиент:

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

Это оставляет предсказание клиента, но даже для такой простой игры, как платформер, это звучит довольно сложно.

Как мне создать работающую клиентскую прогностическую систему для многопользовательской платформерной игры?

networking multiplayer platformer

— Джастин
источник

Одной вещью, о которой вам будет гораздо меньше беспокоиться в совместной игре, является мошенничество;)

— Джонатан Коннелл,

Я пометил это как не конструктивное. Поставленные вопросы («Сколько стоит работа над созданием сетевой игры, которая использует предсказание клиента? Я собираюсь в итоге получить половину своей кодовой базы, состоящей из сетевого кода?»), Слишком широки и совсем не специфичны для проблемы. Ответ будет в основном «это зависит», что не является хорошим ответом.

— TravisG

-1, «Сколько работы» субъективно.

— Тетрад

Сколько работы, не субъективно, так как оно само по себе, но оно зависит от нескольких факторов (размер игры, требования к точности и т. Д.), Которые эти факторы могут повлиять, если много работы, мало работы или где-то между ними (хотя какой тип работы лучше вопрос); тем не менее, я думаю, что OP действительно спрашивает, сколько усилий требуется и насколько большой частью базы кода будет этот тип кода. Как сказано, оно может быть слишком широким. Я выбрал более узкую интерпретацию и ответил на это. Я думаю, что ФП следует приложить немного больше усилий, чтобы сузить вопросы до нескольких очень конкретных моментов.

— конец

@Tetrad Извините - я изо всех сил старался сделать этот вопрос как можно более объективным, но мой вопрос сводится к тому, «сложно ли создать работающую клиентскую прогностическую систему для игры типа Y» - если нет, то я буду учиться, как я иди, но мое время ограничено, поэтому учиться, что слишком много работы после X дней игры, уже слишком поздно. Я бы попытался предоставить более подробную информацию о Y, но я не хочу делать вопрос "слишком локализованным". Основной проблемой здесь является движение, которое является общим для всех платформеров (я хочу, чтобы другие сочли этот вопрос полезным). Если я могу улучшить этот вопрос, то предложения приветствуются.

— Джастин

Ответы:

Я не думаю, что половина вашей кодовой базы превратится в сетевой код, если вы решите реализовать такую функцию, как эта.

На мой взгляд, самый простой способ сделать это - настроить «центральный» сервер (даже если это означает, что один игрок «размещает» игру, а затем подключается к своему собственному серверу), который принимает все пользовательские данные как можно быстрее. и отправляет его обратно каждому клиенту.

На клиенте вы реализуете это не иначе, как если бы вы проводили совместную игру для двух игроков локально, за исключением того, что вы читали P1 с клавиатуры и P2 из сети.

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

— Nate
источник

Это примерно так же просто, как и подход «клиент-сервер» (за исключением того, что один клиент размещает сервер -> вам не нужен выделенный сервер, но вы должны использовать что-то вроде UDP + NAT Punchthrough, которому в любом случае требуется выделенный сервер). Во-вторых, вы предлагаете метод lockstep (как вы говорите об отправке полных игровых состояний), это, IMHO, не лучший метод, если игра запускается через Интернет (хотя, вероятно, через LAN), где клиент-сервер намного проще реализовать.

— Вальмонд

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

— Нейл

У меня полностью функциональная игра в стиле mMORPG с предсказанием клиента (игра далека от завершения, но она работает «ОК»), и у меня есть что-то около 40 000 строк кода для сервера и удвоение для клиента (добавьте такое же количество для инструментов и т. Д. .). Предсказание, вероятно, составляет не более нескольких сотен строк (если даже это), и вся сеть разделяет пару тысяч строк, но не более, чем, скажем, 5000 (немного зависит от того, где вы проводите линию).

Нечеткий вопрос нечеткий ответ ;-)

— Valmond
источник

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

Одна вещь, которую вы захотите в своем игровом коде, - это способность обрабатывать несколько различных состояний игры, которые вы можете использовать для интерполяции и прогнозирования. Это довольно просто спроектировать заранее, но может потребовать значительных усилий, если вы вносите изменения в существующую однопользовательскую игру.

Также обратите внимание, что если вы хотите, чтобы незнакомые люди играли в одноранговую игру через Интернет, вам, вероятно, понадобится хотя бы один сервер, который бы где-то занимался лобби / организацией матчей.

— Адам
источник