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

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

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

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

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

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

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

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

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

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

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

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