Локальная сеть android unity

Элементы сетевого взаимодействия в Unity

(For new projects, you should use the new networking system introduced in 5.1. This information is for legacy projects using the old networking system.)

Встроенные в Юнити способы работы с сетями поддерживают всё, описанное на предыдущей странице. Создание серверов и подключение клиентов, обмен данными между подключенными клиентами, определение какой игрок управляет какими объектами, доступ через различные конфигурации сети — всё это поддерживается сразу после установки Юнити. На этой странице мы рассмотрим реализацию в Юнити этих сетевых задач.

Создание сервера

Перед тем как вы сможете начать играть в сетевую игру, вам необходимо определить другие компьютеры, с которым вы будете обмениваться данными. Чтобы это сделать, необходимо создать сервер. Это может быть как машина, на которой запущена игра, так и отдельная выделенная машина, не принимающая участия в игре. Чтобы создать сервер, просто вызовите Network.InitializeServer() в скрипте. Если вы хотите подсоединться к уже существующему серверу как клиент, вызывайте Network.Connect().

В общем, вам может быть очень полезно ознакомиться со всем классом Network class.

Связь с использованием компонентов Network View

Network View (просмотр сети) это компонент, который отправляет данные через сеть. Компонент Network View даёт вашим объектам GameObject возможность отправлять данные, используя удаленный вызов процедур RPC или синхронизацию состояний State Synchronization. Способ, которым вы используете Network View будет определять, как будут работать сетевые взаимодействия вашей игры. Network View имеют несколько вариантов, но все они необычайно важны для ваших сетевых игр.

Для большей информации об использовании Network View изучите Network View Guide page и Component Reference page.

Удаленные вызовы процедур (Remote Procedure CAlls, RPC)

Удаленные вызовы процедур (Remote Procedure Calls, RPC) это функции, объявленные в скриптах, прикрепленных к GameObject, который содержит NetworkView. Network View должен указывать на скрипт, содержащий RPC функцию. После этого, RPC функция может быть вызвана из любого скрипта в этом GAmeObject.

Для большей информации об использовании RPC в Юнити, изучите RPC Details page.

Синхронизация состояний (State Synchronization)

Синхронизация состояний это постоянный обмен данными между всеми клиентами игры. Таким способом позиция игрока может быть синхронизирована со всем клиентами, так что будет казаться, что он управляется локально, когда данные в действительности доставляются через сеть. Для синхронизации состояний внутри объекта GameObject вам просто надо добавить компонент NetworkView на этот объет и объяснить ему, за чем наблюдать. Наблюдаемые данные после этого синхронизируются со всеми клиентами в игре.

Для большей информации об использовании синхронизации состояний в Юнити, изучите State Synchronization page.

Network.Instantiate()

Network.Instantiate() позволяет вам создавать экземпляры префабов на всех клиентах естественно и просто. По сути, это вызов функции Instantiate() , но он выполняет создание экземпляров на всех клиентах.

Внутренне Network.Instantiate это простой вызов RPC, который выполняется на всех клиентах (также локально). Он распределяет NetworkViewID и назначает его созданной копии префаба, что гарантирует его правильную синхронизацию среди всех клиентов.

Для большей информации изучите страницу Network Instantiate.

NetworkLevelLoad()

Работа с обменом данными, состоянием клиентов игроков и загрузкой уровней может быть слишком большой. На странице Network Level Load вы найдёте полезный пример для решения этой задачи.

Master Server

Master Server (Управляющий сервер) помогает вам подбирать игры. При запуске сервера, вы подключаетесь к master server, и он предоставляет вам список всех активных серверов.

Master Server это место встречи для серверов и клиентов, где афишируются серверы и совместимые клиенты подключаются к запущенным играм. Это снимает необходимость заботиться об IP адресах для всех сторон. Это даже может помочь пользователям хостить игры без необходимости возиться с их маршрутизаторами, что требовалось бы при обычных обстоятельствах. Это может помочь клиентам пройти через брандмауэр сервера и добраться до частных IP адресов, обычно недоступных из публичного интернета. Это делается с помощью facilitator, который способствует установлению соединения.

Для большей информации изучите Master Server page.

Минимизация сетевого трафика

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

Для получения советов по уменьшению сетевого трафика, изучите Minimizing Bandwith page.

Отладка сетевых игр

Юнити поставляется с несколькими вспомогательными инструментами, которые помогут вам отладить вашу сетевую игру.

Источник

Русские Блоги

Unity3D UNET имитирует игры по локальной сети

За два дня обучения я нашел хорошее руководство по компоненту Unity в Unity, и я поделюсь им с вами здесь. К
Создайте новый UnetProject. К
Создайте новый GameObject, переименуйте его в Network Manager и добавьте к нему компонент Network Manager. Это основной компонент управления, предоставляемый Unet. Вы можете получить доступ к Network Manager в скрипте для разработки сети. К
Вам также необходимо добавить компонент HUD Network Manager, который используется для отображения пользовательского интерфейса, а кнопки в пользовательском интерфейсе будут взаимодействовать с Network Manager. В это время на рабочем экране появится следующее:

Хост LAN (H): считайте этот компьютер сервером + клиентом, то есть сервером плюс клиентом.
Клиент LAN (C): подключитесь к серверу и введите IP-адрес (localhost — это машина)
Только сервер LAN (S): этот аппарат используется только как сервер.
Этот компонент обычно используется при тестировании. К
Теперь используйте собственную модель Unity, чтобы собрать Player (что хотите) и добавить к нему компонент Network Identity. Это сетевой идентификатор. Объекты с идентификаторами могут быть сгенерированы в сети, то есть синхронизированы с другими клиентами. К

Отмеченное место: только сервер: разрешено работать только на стороне сервера
Полномочия локального игрока: будут иметь полномочия на стороне клиента, это локальная роль
Мы выбираем Local Player Authority для Player, что означает, что мы также можем работать с ним при подключении к серверу во время выполнения. К
Чтобы позволить ему генерировать в локальной сети,

Это указывает на то, какого персонажа мы хотим сгенерировать, поэтому Network Manager будет автоматически создавать персонажа на основе Prefab игрока каждый раз, когда он находится в сети. К
Автоматическое создание игрока: каждый раз, когда сервер и клиент подключаются, создается игрок.
Теперь эффект бега не очевиден, сначала мы сделали роль управления, и эффект очевиден при беге. К

Создайте новый скрипт PlayerController и отредактируйте:

Здесь вам также необходимо добавить компонент Network Transform в Player, который является синхронным компонентом Transform, включая: положение, поворот и масштаб. Его синхронизация является односторонней, то есть контролируемый вами объект синхронизируется с другими клиентами.Когда вы изменяете объект на сервере, клиент не будет следить за изменением. К

Нажмите Ctrl + B, чтобы упаковать проект. После выбора пути нажмите Ctrl + B, чтобы автоматически упаковать его. Теперь упакованная программа и unity запущены. В конце концов, он в сети. Чтобы увидеть эффект, должно быть двое. это Unity действует как сервер + клиент, а упакованная программа действует как чистый клиент. Ниже приведен рендеринг:

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

Добавьте приведенный выше код, а затем запустите,

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

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

Теперь пули могут стрелять, но они не синхронизированы. Теперь мы позволим ему синхронизироваться. Онлайн-игры помещают всю функциональную обработку на сервер для обработки, такую ​​как генерация врагов и оценка игровой логики, поэтому мы также позволяем генерировать пули здесь на сервере, а затем синхронизировать их с клиентом. Добавьте в список компонент Network Identity, а затем измените Network Manager.

Измените сценарий PlayerController:

Примечание. Перейдите на CmdFire, где бы он ни был вызван. . При добавлении компонента Network Transform к маркеру, Transform Sync Mod соответствует Sync Rigidbody 3D, который является синхронным твердотельным компонентом, а Network Send Rate изменяется на 0, что означает, что он будет синхронизирован только один раз, то есть добавить скорость. К
Хорошо, теперь вы можете подключиться к локальной сети, управлять и стрелять по отдельности, и я объясню содержание в следующем блоге. К
Этот блог используется новичками для изучения и обсуждения. Если есть какие-то плохие или неправильные места, укажите на них, спасибо.

Источник

Локальный мультиплеер в Unity с помощью Unet

Всем привет! Сегодня хотелось бы рассказать про один из способов, как можно создать локальный мультиплеер в Unity. Данное решение подходит для шоукейсов, теста фич или локального мультиплеера. К примеру, если вам хочется видеть, что делает игрок, но не хочется скажем на андроиде тратить лишние ресурсы и забирать скринкаст с помощью ADB, то можно просто поднять сервер на какой-то машинке в виде копии приложения, которое работает на телефоне, и слать туда информацию о действиях игрока.

Я вкратце опишу, как можно это сделать с помощью HLAPI на Unet, но не через NetworkingManager, а чуть более низкоуровнево. По доброй традиции приложу пример своей реализации такого клиент-серверного взаимодействия. Пример прошу не судить строго, так как я прекрасно понимаю, что архитектура данного решения никуда не годится и создаёт кучу проблем в перспективе. Моей целью было максимально быстро (за выходные) написать систему, в которой можно показать принцип работы с сетью. Также скажу с какими проблемами пришлось столкнуться. В данном примере реализации предполагается, что сервер так же является Unity приложением.

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

В целом игра в данном примере работает очень просто. Есть 2 сцены. Загрузочная и геймплейная. При загрузке геймплейной сцены у нас генерируется поле на котором играют игроки. Там же происходит проверка условия победы, есть классы отвечающие за работу UI, а так же порядок ходов и в целом логику игры, но нам это не особо интересно. Основные классы, которые отвечают за сетку — это Server, Client, NetManager и отдельный файл для сообщений NetMessages и определённый в нём enum MyMsgType. Они представляют из себя обёртку над средствами Unet. С точки зрения Unet основные классы, которые мы будем использовать — это NetworkClient, NetworkServer, MessageBase и MsgType. Что это за классы?

Самые простые классы — это MessageBase и MsgType. Первый — это абстрактный класс, от которого надо наследовать все наши сообщения, чтобы пересылать их между клиентом и сервером. MsgType — это просто класс, который хранит в себе константы, отвечающие за определённый набор вшитых в Unet сообщений.

NetworkServer — это синглтон, который предоставляет возможность обрабатывать общение с удалёнными клиентами. Под капотом он использует экземпляр NetworkServerSimple и по сути представляет из себя удобную обёртку над ним. Для начала нам надо запустить сервер на определённом порте. Для этого необходимо вызвать метод Listen(int serverPort) — этот метод запускает сервер на порте serverPort. (Напомню, что все порты в диапазоне от 0 до 1023 являются системными и их не стоит использовать в качестве параметра данного метода)

Отлично сервер работает и слушает какой-то порт. Теперь нужно, чтобы он реагировал на сообщения. Для этого нужно зарегистрировать хэндлер с помощью метода RegisterHandler(short msgType, Networking.NetworkMessageDelegate handler). Данный метод принимает параметром тип сообщения и делегат. Делегат в свою очередь должен принимать входным параметром NetworkMessage. Допустим мы хотим, чтобы в тот момент, когда к нему присоединялся игрок на сервере начала загружаться геймплейная сцена, а так же раздавались айдишники игроков. Тогда нужно зарегистрировать хэндлер на соответствующее сообщение, а так же реализовать метод, который мы будем передавать в качестве делегата для регистрации.

Выглядит это примерно так:

Теперь метод OnConnect будет вызываться при каждом коннекте какого-то пользователя. Стоит уточнить, что в данной реализации айдишники определяют порядок хода, поэтому при первом коннекте выбираются айдишники для клиента и сервера. Остальные клиенты автоматом получают айди равный -1, что означает, что этот клиент является зрителем.

Простой сервер есть. Теперь бы клиенты не помешали. Для этого воспользуемся классом NetworkClient. Для того, чтобы присоединиться к серверу надо просто вызвать метод Connect(string serverIp, int serverPort). В качестве порта мы устанавливаем порт, который слушает наш сервер, в качестве айпи ставим localhost, если мы тестируем наше приложение на одной машине или же айпи компа в локальной сети, который мы используем в качестве сервера (Узнать его можно или в настройках сети, или в консоли с помощью команды ipconfig на том компе, который будет выступать в роли сервера).

Замечательно, мы может подконнектиться. Ранее говорилось, что сервак у нас раздаёт айдишники. Значит нам надо во-первых, послать сообщение о айдишнике, а так же зарегистрировать хэндлер этого сообщения на клиенте. Как упоминалось ранее все сообщения надо наследовать от MessageBase. Для начала определим их (я предпочитаю это делать в отдельном файле):

Чтобы послать данное сообщение вызываем на клиенте метод Send(short msgType, Networking.MessageBase msg), который отправит сообщение msg «типа» msgType серверу, или на сервере один из методов в зависимости от цели SendToAll(short msgType, Networking.MessageBase msg) или SendToClient(int connectionId, short msgType, Networking.MessageBase msg), где connectionId — это id определённого клиента.

Чтобы читать наши кастомные сообщения пришедшие нам от другого приложения пользуемся reader.ReadMessage(). Например:

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

О чём ещё хочется сказать, и на что пришлось потратить время, так это пару вещей, которые вам могут быть не очевидны, если вы не работали с сетями.

1. Проверьте, что редактор юнити не заблокирован вашим фаерволом для общения по протоколам TCP и UDP. Однажды я потратил на это некоторое время, при том, что добрался до фаерволла и поставил нужный порт в исключения, но не проверил то, что редактор незаблокирован.

2. Передавайте в сообщениях value-type или сериализуемые reference-type, а так же не передавайте наследников MonoBehavior. Так же важно понимать что reference-type в данном случае будет передавать копию объекта, а не сам объект, и его надо обрабатывать соответствующим образом.

В случае, когда мы говорим про локальную сеть и заранее известное железо, нет многих проблем возникающих в случае “настоящего” мультиплеера. Практически не нужно задумываться о задержках, флуктуациях, потерях пакетов и прочем. Поэтому такое решение может быть полезно, хотя и эти проблемы можно решать с таким подходом до некоторого предела. В сравнении с более высоким уровнем абстракции в Unet, через NetworkManager, NetworkBehavior и т.п., оно предоставляет более понятную и очевидную гибкость (на мой взгляд), если на клиентах требуется загружать разные сцены и т. п., а скажем сервер используется, как стриминг, и показывает то, что отображается на девайсе игрока, принимая его позицию и поворот + дублируя происходящее на своей стороне. В остальных случаях, когда необходимо решение быстрее и вы умеете работать с сетью, Unet предоставляет возможность писать на транспортном уровне.

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

Источник