Я сделал это для коммерческой гоночной игры PSP, которая работала как по специальной сети, так и через беспроводную точку доступа. (Или на статический сервер в интернете, если нужно)
Из-за пункта 2 система не должна быть сложной в отношении оптимизации
По моему опыту, это не так. Беспроводные устройства (особенно небольшие портативные) не похожи на компьютеры с проводными сетевыми подключениями - смартфоны и беспроводные игровые приставки, как правило, имеют медленные сетевые интерфейсы для игровых целей.
Не поймите меня неправильно - их пропускная способность обычно хорошая (то есть количество данных в секунду; отлично подходит для потоковой передачи фильмов и т. Д.), Но задержка при доставке определенного пакета может быть очень плохой и может быть такой очень изменчив, что трудно даже оценить, сколько времени займет доставка отдельного пакета. Это изменение становится еще хуже, поскольку все больше беспроводных устройств объединяются в одну общую область, поскольку их сигналы начинают мешать друг другу. В результате этого довольно много моего времени было потрачено на уменьшение количества пакетов, которые нужно было отправить, поэтому у нас было бы меньше коллизий пакетов. (Обратите внимание, что это несколько менее проблемно в случае, когда задействована активная точка доступа к сети, вместо того, чтобы устройства общались друг с другом напрямую через специальную сеть)
В качестве примера такого рода оптимизации наша гоночная игра произошла в мире со светофорами. Тысячи из них. И нам нужно было убедиться, что их сигналы синхронизированы между всеми игроками в сетевой сессии. Вместо того, чтобы пытаться рассылать пакеты, сообщая всем, в каком состоянии находятся светодиоды, мы определили статическое расписание для всех светофоров, а затем просто убедились, что все клиенты согласились с текущим «игровым временем». Поскольку все они знали время игры, и все состояния светофора могли быть определены по времени игры, мы синхронизировали все эти данные состояния без фактической отправки каких-либо специальных данных. Это одно изменение имело огромное значение для нашей сетевой производительности.
Это говорит о том, что установление надежной синхронизации часов между несколькими беспроводными устройствами (с сильно варьирующимся временем пинга, в основном из-за потери пакетов) было большой проблемой. Рад поговорить об этом больше, если у вас есть интерес.
Каждый клиент может быть авторитетным источником данных о себе и своем непосредственном окружении (например, пули).
Это то, что мы сделали, и это хорошо сработало для нас в нашей ситуации (автомобили). Проблемная часть, конечно, заключается в том, что когда объект перестает быть ближе к игроку «а», чем к игроку «б», и, следовательно, его право собственности переходит от одного игрока к другому.
На самом деле это удивительно сложные переговоры между игроками, когда игра «a» предлагает игру «b»: «Я думаю, что этот объект ближе к вам. Вы должны взять его под контроль». И тогда игра «b» может либо принять, либо может отказаться, исходя из собственного взгляда на ситуацию. Различия в воспринимаемом игровом состоянии между «a» и «b», а также изменение во времени между отправкой и получением запроса и ответа делают это особенно неприятным небольшим согласованием для обеспечения надежности, и оно может легко выродиться в игру «горячая картошка», с владением объектом, постоянно подпрыгивающим между несколькими игроками. И даже если это работает должным образом, если смотреть с точки зрения игры «с», там «
Моя интуиция заключается в том, что такого рода подход «владения объектами», вероятно, будет слишком громоздким для небольших, недолговечных объектов, таких как пули. Мы использовали его для дорожных машин и для гонщиков ИИ, которые, как правило, жили в симуляции относительно долгое время. Кажется, что более эффективный подход, если вы готовы доверять клиентам, состоял бы в том, чтобы у каждого игрока была своя позиция и свои снаряды, и объявляли, когда этот игрок был поражен чужим снарядом. (Так же как и «игра A», я отвечаю за то, где находится игрок A и снаряжение игрока A, но игрок B отвечает за то, что я ударил игрока B). С некоторыми хорошими расчетами вы должны быть в состоянии получить довольно разумное поведение из системы, подобной этой.