Многопользовательские / Сетевые опции для 2D игры с физикой

Question

Резюме:

Мой 50% готовый 2D боковой скроллер с Box2D в качестве физического движка должен иметь многопользовательскую поддержку в финальной версии. Тем не менее, текущий код представляет собой однопользовательскую игру.

• Что мне теперь делать?
• И что более важно, как мне реализовать мультиплеер и объединить его с одиночной игрой?
• Разве это плохая идея кодировать однопользовательский режим отдельно от многопользовательского режима ( как у Notch это было с Minecraft )?

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

Полный фон / вопросы:

Я работаю над сравнительно крупным 2D-проектом на C ++, основным элементом которого является физика. (Я использую Box2D для этого)

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

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

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

Итак, я нахожусь со своей половинчатой ​​2D-игрой с боковым скроллером, и я действительно не знаю, как дальше.

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

Во-первых, общий вопрос к любому, кто, возможно, оказался в такой ситуации:

• Как мне поступить?

Затем, более конкретный - я пытался выяснить, как я могу подойти к сетевой части для моей игры:

• Невидимый / loopback сервер для одиночной игры

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

Большой недостаток: производительность и другие ограничения в одиночной игре. Было бы запущено два симуляции физики. Один для клиента и один для сервера обратной связи.

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

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

• Отдельный одиночный / многопользовательский режим

В однопользовательском режиме сервер не задействован.

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

• Многопользовательский режим как модуль для одиночной игры

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

В ретроспективе я сожалею, что не планировал многопользовательский режим ранее. Я действительно застрял на этом этапе и надеюсь, что кто-то здесь сможет мне помочь!

Answer 1

Я думаю, что Нотч чувствует боль от развития SP и SMP по отдельности. Тем более, что он сказал команде разработчиков Bukkit, что он планирует перейти на подход «локальный сервер для одного игрока» (как вы сказали, как Source Engine.)

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

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

Самый простой способ сделать клиента состоит в том, чтобы добавить «фиктивные» флаги к вашим объектам, чтобы эти макеты управлялись непосредственно сервером. Затем перейдите в интерполяцию. (Передача обновлений объекта с частотой 60 Гц нереалистична, поэтому сглаживание между точками делает вещи по-прежнему красивыми. Источник делает это, добавляя небольшую искусственную задержку, если вы когда-либо играли в многопользовательскую игру GTA4 по интернет-соединению ниже номинальной, вы можете увидеть эффект переусердствовать на быстрых машинах.)

Также рекомендуется прочитать: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Answer 2

Вы могли бы использовать терминальный подход тупого рендера. Преимущество заключается в том, что его относительно легко интегрировать, не создавая его с самого начала. Недостатком является то, что задержка не будет компенсирована с помощью методов прогнозирования, и если имеется много видимых объектов, пропускная способность может быть высокой.

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

Насколько хорошо это работает, зависит от количества нарисованных объектов и сложности их графического описания. Но это описание обычно довольно мало для 2D-игр.

Я ожидаю, что это будет хорошо работать в локальной сети, так как это имеет хорошие задержки и пропускную способность. Понятия не имею, насколько хорошо это работает через Интернет.

---

Вот документ, описывающий, как работает нереальный сетевой код. А во введении описаны несколько более простых подходов. Возможно, вы захотите реализовать один из них. http://unreal.epicgames.com/Network.htm