(Unity) Оптимизированное сетевое решение для многих движущихся объектов

8

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

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

Однако проблема возникает, когда я пытаюсь подключить эту игру к сети. Я уже пытался следовать этому руководству для реализации этой функции: http://www.paladinstudios.com/2013/07/10/how-to-create-an-online-multiplayer-game-with-unity/

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

Вопрос, который я задаю:

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

Я уже думал об одном способе сделать это. После порождения отряда они будут двигаться только в одном направлении, пока не столкнутся с чем-то - возможно, я могу синхронизироваться только тогда, когда отряды появляются и когда они взаимодействуют с другим объектом? Будет ли это иметь много пользы? Какой идеальный способ реализовать это?

Заранее спасибо за отзывы!

Рейчел Кэбот
источник
Вероятно ли, что мне нужна модель со ступеньками? clintonbrennan.com/2013/12/lockstep-implementation-in-unity3d
Рэйчел Кэбот
Я нахожусь за брандмауэром и не могу получить доступ к примеру, который вы связали, но вы пытались сериализовать только ID объекта, положение и векторы скорости в каждом кадре? В зависимости от того, насколько вы умны с помощью алгоритма сериализации, вы можете уменьшить информацию о состоянии до 7 байт на объект. Если вы убедитесь, что клиент принимает отсутствующий идентификатор из обновления как смерть, а новые как порождение, у вас не должно возникнуть никаких проблем.
Стефан

Ответы:

1

Для 200+ движущихся объектов вы определенно захотите сделать игру своей игрой. С «шагом» возникает необходимость в детерминизме, но это не должно быть слишком трудно для бактерий (что можно смоделировать при столкновении окружность-окружность).

Если вы не возражаете против моего бесстыдного самостоятельного подключения и хотите получить пример с сетевой логикой и симуляцией логической игры, посмотрите этот ресурс бесплатно: https://www.assetstore.unity3d.com/en/#!/ Содержание / 36206 . К сожалению, эта версия не включает в себя весь исходный код, но не стесняйтесь взломать его с моего благословения;). Вот видео раннего теста DPhysics: https://www.youtube.com/watch?v=NEzOghxfMdU .

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

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

JPtheK9
источник
1
Этот подход может привести к рассинхронизации, даже если все детерминировано, просто из-за задержки между общими входами. В качестве примера возьмем игру, в которой игроки пытаются заблокировать движение объекта путем размещения стен. На экране одного игрока он мог правильно рассчитать время размещения, и объект заблокирован. Но репликация этого другому клиенту может прибыть поздно, и как только стена установлена, объект уже прошел это местоположение. В зависимости от игровой механики может потребоваться периодически отправлять обновления «большой картинки» для повторной синхронизации клиентов.
Acidictadpole
Хорошая точка зрения. Существует 0 возможностей рассинхронизации, если это сделано правильно. Если пакет пропущен или приходит очень поздно, клиент не может перейти к следующему кадру - ему придется ждать, пока пакет прибудет, чтобы выполнить текущий кадр. Кадры могут быть представлены целыми числами. Сервер распределяет пакеты, помеченные целым числом для каждого кадра.
JPtheK9
Проверьте сеть и логику кадров для себя.
JPtheK9
1
@ JPtheK9 «ему придется ждать прибытия пакета для выполнения текущего кадра». А что, если пакет не приходит?
Стефан
Запросите новый.
JPtheK9