Разработка компьютерных игр | UDP IPv6

Пробрасывая IP между вложенными сетями через дополнительный сервер с таблицей адресации - в теории, ценой снижения скорости на работу серверов каждой такой подсети. На практике же с IP адресами стандарта 4 очень быстро начал возникать дефицит - большую чать IP зарезервировали за собой участники принятия данного стандарта, меньшая часть адресов попала в продажу от чего спрос на них привел к дефициту за каждый IPv4 в мировой сети, аренда 1 такого адреса что бы огранизовать свой игровой сервер для партии игры стоит в месяц как еще один хостинг сайта, при этом большая часть этих адресов просто зарезервирована и не используется т.е. при ином стечении абстоятельств эти адреса могли бы быть почти бесплатны вероятно поэтому на них установлен регулируемый дефицит.

В след за этим явлением появились сервисы вритуальных IPv4 - часто даже бесплатных, когда 1 владелец IPv4 в мировой сети разрешал его использовать множеству желающих - т.е. можно было обладая внутренним ip от провайдера еще держать на компьютере включенной exe программу подключавшую к нему еще один - внешний IP в мировой сети, и подключить к этому ip свой жесткий диск и сделать в общем доступе свои файлы или организовать сервер для игры разослав внешний IP другим игрокам что бы они к нему присоединились и т.д. но с этим явлением стали бороться частные провайдеры т.к. платный IPv4 это неплохая услуга в дополнении к оплате интернета и все соединения к этим адресам если они небыли куплены а подключены беслпатно стали неработоспособны - оборудование их просто перестало обслуживать т.е. у некоторых провайдеров бесплатные адреса работают а у некоторых нет т.е. оборудование определяет что это за адрес платный или нет и срабатывет по разному - однако это объясняется как технический сбой, который почему-то никто не исправляет и да - когда-то никакого сбоя небыло - в общем у бесплатных IP есть противники из числа тех кто продает платные IP хотя технически проблем выдать на каждые например 50 компьютеров 1 общий внешний IPv4 нет и раньше так и делали - но тогда нет смысла многим арендовать такие IP вероятно поэтому трафик программ которые подсоединяют локальный компьютер в подсети провайдеров к внешнему IPv4 стал обрываться.

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

Следующее что вызвало внимание это протоколо UDP в противовес TCP. TCP сам ведет проверку дошел пакет данных до адресата или нет и делает повтор отправки несколько раз если не дошел. UDP это не делает сам, но работает быстрее - однако, в некоторых случаях гарантия доставки пакета данных не всегда нужна. Тесты показали что даже на близких расстояниях UDP при отправки 5 пакетов теряет 2-3 пакета, цели достигают например около 2-х. Но, когда нужно доставить не сообщение текста а например трансляцию изображения иконки персонажа в онлайн игре - то нет смысла пересылать повторно недошедший кадр, если кадр получен небыл можно просто поставить картинку на паузу используя прошлый успешно полученный кадр и показывать анимацию используя следующий кадр который будет получен успешно в целом такая система должна работать быстро, но все же следует делать проверку сколько пакетов не дошло и повторять отправку тогда, когда этот показатель совсем низкий.

Все это заставило обратить внимание на IPv6 (что может дать возможность игрокам применять почти бесплатный IP адрес для организации партии онлайн игры) в сочетании с UDP. Однако оказалось что на момент поиска разных алгоритмов для игры в небыло найдено ни одного примера его реализации в отличии от сразу нескольких готовых кодов для реализации IPv4 на TCP протоколе (более медленный но надежный). Поэтому нескольким программистам кто когда-то успешно это уже делал были направлены предложения попробовать сделать варианты этого решения (применение этих решений по работе клиент-сервера разрешены (разумеется в целях не нарушающих закон), указывать данный сайт при использовании размещенного тут кода ненужно.) Из этих решений были выбраны безсбойные, которые работали более стабильно.

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

Размер передаваемых сообщений в разрабатываемой компьютерной игре в обоих направлениях не должен превышать примерно по 450 Килобайт. Проводился замер достижения пакетов данных адресатов - пакет в 1 мегабайт может успешно пройти расстояние в 3 региона страны, но между государствами (а играют одни и те же игры игроки из разных стран) расположены коммуникации интернет соединений работу которых обеспечивают например магистральные провайдеры интернета, в случаях высокой нагрузки по трафику оборудование провайдеров блокирует крупные пакеты данных в пользу малых пакетов что бы обеспечить хоть какую-то пусть небольшую пропускную способность нескольким адресам вместо большого потока данных на один адрес, таким образом например из России в Европу из 10 пакетов размеров 1 мегабайт может дойти 1-й и 8-й пакет в первых 10 последовательно отправленных по TCP протоколу а в следующих 20 30 40 и 100 - ни одного, крупные пакеты просто блокируются, что видит игрок - что нет связи с серверов совсем - при этом все будет работать если уменьшить размер пакета данных, сервера режут большие пакеты в пользу обеспечения загрузок сайтов и фильмов во время высокой нагрузки линий передачи данных. Т.е. если пеередвать данные небольшими пакетами то все до одного пакета если они менее чем 500 килобайт доходят успешно - это настройки оборудования в интернет инфраструктуре, они пропускают большие пакеты при низкой загрузке линий данных и пропускают только малые пакеты при высокой загруженности. Таким образом обстановка игрового мира в 1 кадре не может быть передана (обычными способами) более чем объемом в 500 Килобайт в момент времени (координаты космических кораблей, флотов, их техническое состояние и т.д.)

Увеличить объем данных можно запустив сразу 2 порта передачи данных и синхронизируя 2 пакета данных в один, но это для быстрой компьютерной игры мало пригодно, для наполнения баз данных может быть где скорость не важна но не для игры, кроме того, в компьютерной игре в каждом пакете даных придется передавать не измнения за 1 кадр а сразу несколько кадров внутри пакета - т.к часть пакетов будет терятся и не доходить до адресата и потребуется компенсировать утерянные данные другим пакетом информации идущим следом - т.е. избыточность дополнительно уменьшает объем передаваемой полезной информации, а с другой стороны - скорость обработки данных из пакета и ее интеграция в 3D пространство не позволит передавать слишком крупные пакеты данных в принципе. Таким образом размеры игрового мира при онлайн игре, если игра не представляет собой множество связанных отдельных локаций а представлена цельным миром, ограничиваются возможностями скорости синхронизации данных между компьютерами.