как обратиться к другому скрипту unity
Управление игровыми объектами (GameObjects) с помощью компонентов
В редакторе Unity вы изменяете свойства Компонента используя окно Inspector. Так, например, изменения позиции компонента Transform приведет к изменению позиции игрового объекта. Аналогично, вы можете изменить цвет материала компонента Renderer или массу твёрдого тела (RigidBody) с соответствующим влиянием на отображение или поведение игрового объекта. По большей части скрипты также изменяют свойства компонентов для управления игровыми объектами. Разница, однако, в том, что скрипт может изменять значение свойства постепенно со временем или по получению ввода от пользователя. За счет изменения, создания и уничтожения объектов в заданное время может быть реализован любой игровой процесс.
Обращение к компонентам
Наиболее простым и распространенным является случай, когда скрипту необходимо обратиться к другим компонентам, присоединенных к тому же GameObject. Как упоминалось во разделе Введение, компонент на самом деле является экземпляром класса, так что первым шагом будет получение ссылки на экземпляр компонента, с которым вы хотите работать. Это делается с помощью функции GetComponent. Типично, объект компонента сохраняют в переменную, это делается в C# посредством следующего синтаксиса:
В UnityScript синтаксис немного отличается:
Как только у вас есть ссылка на экземпляр компонента, вы можете устанавливать значения его свойств, тех же, которые вы можете изменить в окне Inspector:
Имейте ввиду, что нет причины, по которой вы не можете иметь больше одного пользовательского скрипта, присоединенного к одному и тому же объекту. Если вам нужно обратиться к одному скрипту из другого, вы можете использовать, как обычно, GetComponent, используя при этом имя класса скрипта (или имя файла), чтобы указать какой тип Компонента вам нужен.
Если вы попытаетесь извлечь Компонент, который не был добавлен к Игровому Объекту, тогда GetComponent вернет null; возникнет ошибка пустой ссылки при выполнении (null reference error at runtime), если вы попытаетесь изменить какие-либо значения у пустого объекта.
Обращение к другим объектам
Пусть иногда они и существуют изолированно, все же, обычно, скрипты отслеживают другие объекты. Например, преследующий враг должен знать позицию игрока. Unity предоставляет несколько путей получения других объектов, каждый подходит для конкретной ситуации.
Связывание объектов через переменные
Переменная будет видна в окне Inspector, как и любые другие:
Теперь вы можете перетащить объект со сцены или из панели Hierarchy в эту переменную, чтобы назначить его. Функция GetComponent и доступ к переменным компонента доступны как для этого объекта, так и для других, то есть вы можете использовать следующий код:
Кроме того, если объявить переменную с доступом public и заданным типом компонента в вашем скрипте, вы сможете перетащить любой объект, который содержит присоединенный компонент такого типа. Это позволит обращаться к компоненту напрямую, а не через игровой объект.
Соединение объектов через переменные наиболее полезно, когда вы имеете дело с отдельными объектами, имеющими постоянную связь. Вы можете использовать массив для хранения связи с несколькими объектами одного типа, но связи все равно должны быть заданы в редакторе Unity, а не во время выполнения. Часто удобно находить объекты во время выполнения, и Unity предоставляет два основных способа сделать это, описанных ниже.
Нахождение дочерних объектов
Иногда игровая сцена может использовать несколько объектов одного типа, таких как враги, путевые точки и препятствия. Может возникнуть необходимость отслеживания их в определенном скрипте, который управляет или реагирует на них (например, все путевые точки могут потребоваться для скрипта поиска пути). Можно использовать переменные для связывания этих объектов, но это сделает процесс проектирования утомительным, если каждую новую путевую точку нужно будет перетащить в переменную в скрипте. Аналогично, при удалении путевой точки придется удалять ссылку на отсутствующий объект. В случаях, наподобие этого, чаще всего удобно управлять набором объектов, сделав их дочерними одного родительского объекта. Дочерние объекты могут быть получены, используя компонент Transform родителя (так как все игровые объекты неявно содержат Transform):
Вы можете также найти заданный дочерний объект по имени, используя функцию Transform.Find:
Методы организации взаимодействия между скриптами в Unity3D.
Вступление.
Даже средний Unity 3 D проект очень быстро наполняется большим количеством разнообразных скриптов и возникает вопрос взаимодействия этих скриптов друг с другом.
Данная статья предлагает несколько различных подходов к организации таких взаимодействий от простого до продвинутого и описывает к каким проблемам может привести каждый из подходов, а так же предложит способы решения этих проблем.
Подход 1. Назначение через редактор Unity3D.
Пусть у нас в проекте есть два скрипта. Первый скрип отвечает за начисление очков в игре, а второй за пользовательский интерфейс, который, отображает количество набранных очков на экране игры.
Назовем оба скрипта менеджерами: ScoresManager и HUD Manager.
Каким же образом менеджеру, отвечающему за меню экрана можно получить текущее количество очков от менеджера, отвечающего за начисление очков?
Один из подходов, содержит следующий принцип:
В скрипте UIManager определяем переменную типа ScoresManager :
Но переменную ScoresManager необходимо еще инициализировать экземпляром класса. Для этого выберем в иерархии объектов объект, на который назначен скрипт HUD Manager и в настройках объекта увидим переменную ScoresManager со значением None.
После чего, у нас появляется возможность из кода HUDManager обращаться к скрипту ScoresManager, таким образом:
Все просто, но игра, не ограничивается одними набранными очками, HUD может отображать текущие жизни игрока, меню доступных действия игрока, информацию о уровне и многое другое. Игра может насчитывать в себе десятки и сотни различных скриптов, которым нужно получать информацию друг от друга.
Чтобы получить в одном скрипте данные из другого скрипта нам каждый раз придется описывать переменную в одном скрипте и назначать (перетаскивать вручную) ее с помощью редактора, что само по себе нудная работа, которую легко можно забыть сделать и потом долго искать какая из переменных не инициализирована.
Если мы захотим что-то отрефакторить, переименовать скрипт, то все старые инициализации в иерархии объектов, связанные с переименованным скриптом, сбросятся и придется их назначать снова.
В то же время, такой механизм не работает для префабов ( prefab ) – динамического создания объектов из шаблона. Если какому-либо префабу нужно обращаться к менеджеру, расположенному в иерархии объектов, то вы не сможете назначить самому префабу элемент из иерархии, а придется сначала создать объект из префаба и после этого программно присвоить экземпляр менеджера переменной только что созданного объекта. Не нужная работа, не нужный код, дополнительная связанность.
Следующий подход решает все эти проблемы.
Подход 2. «Синглтоны».
Применим упрощенную классификацию возможных скриптов, которые используются при создании игры. Первый тип скриптов: «скрипты-менеджеры», второй: «скрипты-игровые-объекты».
Основное отличие одних от других в том, что «скрипты-менеджеры» всегда имеют единственный экземпляр в игре, в то время как «скрипты-игровые-объекты» могут иметь количество экземпляров больше единицы.
Примеры:
Как правило, в единственном экземпляре существуют скрипты, отвечающие за общую логику пользовательского интерфейса, за проигрывание музыки, за отслеживание условий завершения уровня, за управление системой заданий, за отображение спецэффектов и так далее.
В то же время, скрипты игровых объектов существуют в большом количестве экземпляров: каждая птичка из «Angry Birds» управляется экземпляром скрипта птички со своим уникальным состоянием; для любого юнита в стратегии создается экземпляр скрипта юнита, содержащий его текущее количество жизней, позицию на поле и личную цель; поведение пяти разных иконок обеспечивается различными экземплярами одних и тех же скриптов, отвечающих за это поведение.
В классе ScoresManager опишем статическое свойство типа ScoresManager, в котором будет храниться единственный экземпляр менеджера очков:
Осталось инициализировать свойство Instance экземпляром класса, который создает среда Unity3D. Так как ScoresManager наследник MonoBehaviour, то он участвует в жизненном цикле всех активных скриптов в сцене и во время инициализации скрипта у него вызывается метод Awake. В этот метод мы и поместить код инициализации свойства Instance:
После чего, использовать ScoresManager из других скриптов можно следующим образом:
Плюсы:
Минусы:
На последнем «минусе» остановимся подробнее.
Пусть мы разрабатываем игру, в которой есть персонажи ( unit ) и эти персонажи могут погибать ( die ).
Где-то находится участок кода, который проверяет не погиб ли наш персонаж:
Учитывая все вышеперечисленное, функция Die может выглядеть следующим образом:
Получается, что персонаж после совей смерти должен разослать всем компонентам, которые в ней заинтересованы этот печальный факт, он должен знать о существовании этих компонентов и должен знать, что они им интересуются. Не слишком ли много знаний, для маленького юнита?
Так как игра, по логике, очень связанная структура, то и события происходящие в других компонентах интересуют третьи, юнит тут ничем не особенный.
Примеры таких событий (далеко не все):
В результате таких связей мы приходим к картине похожей на следующую, где все про всех все знают:
Пример со смертью персонажа немного преувеличен, сообщать о смерти (или другом событии) шести разным компонентам не так часто приходится. Но варианты, когда при каком-то событии в игре, функция, в которой произошло событие, сообщает об этом 2-3 другим компонентам встречается сплошь и рядом по всему коду.
Следующий подход пытается решает эту проблему.
Подход 3. Мировой эфир (Event Aggregator).
Введем специальный компонент « EventAggregator », основная функция которого хранить список событий, происходящих в игре.
Событие в игре – это функционал, предоставляющий любому другому компоненту возможность как подписаться на себя, так и опубликовать факт совершения этого события. Реализация функционала события может быть любой на вкус разработчика, можно использовать стандартные решения языка или написать свою реализацию.
Пример простой реализации события из прошлого примера (о смерти юнита):
Добавляем это событие в «EventAggregator»:
Теперь, функция Die из предыдущего примера с восемью строчками преобразуется в функцию с одной строчкой кода. Нам нет необходимости сообщать о том, что юнит умер всем заинтересованным компонентам и знать о этих заинтересованных. Мы просто публикуем факт свершения события:
А любой компонент, которому интересно это событие, может отреагировать на него следующим образом (на примере менеджера отвечающего за количество набранных очков):
В функции Awake менеджер подписывается на событие и передает делегат, отвечающий за обработку этого события. Сам же обработчик события, принимает в качестве параметра экземпляр умершего юнита и добавляет количество очков в зависимости от типа этого юнита.
Таким же образом, все другие компоненты, кому интересно событие смерти юнита, могут подписаться на него и обработать, когда событие произойдет.
В результате, диаграмма связей между компонентами, когда каждая компонента знала друг о друге, превращается в диаграмму, когда компоненты знают только о событиях, которые происходят в игре (только о интересующих их событиях), но им все равно, от куда эти события пришли. Новая диаграмма будет выглядеть следующим образом:
Я же люблю другую интерпретацию: представьте, что прямоугольник « EventAggregator » растянулся во все стороны и захватил внутрь себя все остальные прямоугольники, превратившись в границы мира. В моей голове, на этой диаграмме « EventAggregator » вообще отсутствует. « EventAggregator » это просто мир игры, некий «игровой эфир», куда различные части игры кричат «Эй, народ! Юнит такой-то умер!», и все прослушивают эфир и если какое-то из услышанных событий их заинтересует, они на него отреагируют. Таким образом – связей нет, каждый компонент независим.
Такой подход позволяет легко вводить новый функционал без изменения старого. Допустим, в готовую игру мы решили добавить систему достижений. Мы создаем новую компоненту системы достижений и подписываемся на все интересующие нас события. Никакой другой код не меняется. Не надо ходить по другим компонентам и из них вызывать систему достижений и говорить ей мол и мое событие посчитай пожалуйста. К тому же, все кто публикуют события в мире ничего не знают о системе достижений, даже о факте ее существования.
Замечание:
Говоря, что никакой другой код не меняется, я конечно немножко лукавлю. Может оказаться так, что систему достижений интересуют события, которые ранее просто не публиковались в игре, потому как ни одну другую систему до этого не интересовали. И в этом случае, нам нужно будет решить какие новые события добавить в игру и кто будет их публиковать. Но в идеальной игре уже все возможные события есть и эфир наполнен ими по полной.
Плюсы:
Минусы:
Последний минус рассмотрим более детально:
Представим, что у нас есть объект « ObjectA », в котором вызывается метод « MethodA ». Метод « MethodA », состоит из трех шагов и вызывает внутри себя три других метода, которые выполняют эти шаги последовательно (« MethodA 1», « MethodA 2» и « MethodA 3»). Во втором методе « MethodA 2» происходит публикация какого-то события. И тут происходит следующее: все кто подписан на это событие начнут его обрабатывать, выполняя какую-то свою логику. В этой логике тоже может произойти публикация других событий, обработка которых также может привести к публикации новых событий и так далее. Дерево публикаций и реакции в отдельных случаях может очень сильно разрастись. Такие длинные цепочки крайне тяжело отлаживать.
Но самая страшная проблема, которая тут может произойти, это когда одна из веток цепочки приводит обратно в « ObjectA » и начинает обрабатывать событие путем вызова какого-то другого метода « MethodB ». Получается, что метод « MethodA » у нас еще не выполнил все шаги, так как был прерван на втором шаге, и содержит сейчас в себе не валидное состояние (в шаге 1 и 2 мы изменили состояние объекта, но последнее изменение из шага 3 еще не сделали) и при этом начинается выполняться « MethodB » в этом же объекте, имея это не валидное состояние. Такие ситуации порождают ошибки, очень сложно отлавливаются, приводят к тому, что надо контролировать порядок вызова методов и публикации событий, когда по логике этого делать нет необходимости и вводят дополнительную сложность, которую хотелось бы избежать.
Решение:
Таким образом, при выполнении метода « MethodA » не происходит его прерывание, а опубликованное событие все заинтересованные записывают себе в специальное хранилище. И только после того как к заинтересованным подписчикам дойдет очередь, они достанут из хранилища событие и обработают его. В этот момент весь « MethodA » будет завершен и « ObjectA » будет иметь валидное состояние.
Заключение.
Компьютерная игра это сложная структура с большим количеством компонентов, которые тесно взаимодействуют друг с другом. Можно придумать множество механизмов организации этого взаимодействия, я же предпочитаю механизм, описанный мною, основанный на событиях и к которому я пришел эволюционным путем прохода по всевозможным граблям. Надеюсь кому-нибудь он тоже понравится и моя статья внесет ясность и будет полезной.
Как обратиться к struct из другого скрипта?
Как обратиться к переменной из другого скрипта?
public class heroScript : MonoBehaviour < public int score = 20; >Обращаюсь: public int.
Как из одного скрипта изменить переменную (int) другого скрипта?
У меня есть два скрипта (money который отвечает за общее количество денег и CarBuy который отвечает.
Как обратиться к картинкам внутри скрипта
Кто-нибудь знает как можно обратиться к картинкам window.runParams.imageBigViewURL внутри скрипта.
Решение
Добавлено через 4 минуты
или вы прсто не видите структуру?
ну так вынесите её за класс.
Добавлено через 2 минуты
чесслово) вопроса не понимаю
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Подскажите как обратиться к настройка света из скрипта
Нужно погрузить сцену в непроглядную тьму, подскажите пожалуйста как обратиться из скрипта к.
Как обратиться к объекту из другого метода
Есть две кнопки. Одна для создания контейнера, а другая для удаления этого контейнера. Когда создаю.
Как обратиться к переменной другого класса
Здравствуйте! Подскажите пожалуйста: как обратиться к переменной из одного класса находясь в.
Как обратиться к функции из другого файла
Добрый день. Как можно обратиться к функции из другого файла php ТоЛЬКО не используя функции.
Создание и Использование Скриптов
Unity изначально поддерживает три языка программирования:
Изучение искусства программирования и использования этих языкам выходит за рамки данного введения. Однако есть множество книг, обучающих материалов и ресурсов для изучения программирования в среде Unity. Посетите Обучающий раздел на нашем сайте для получения подробной информации.
Создание скриптов
В отличии от других ассетов, скрипты обычно создаются непосредственно в Unity. Вы можете создать скрипт используя меню Create в левом верхнем углу панели Project или выбрав Assets > Create > C# Script (или JavaScript/Boo скрипт) в главном меню.
Новый скрипт будет создан в папке, которую вы выбрали в панели Project. Имя нового скрипта будет выделено, предлагая вам ввести новое имя.
Лучше ввести новое имя скрипта сразу после создания чем изменять его потом. Имя, которое вы введете будет использовано, чтобы создать начальный текст в скрипте, как описано ниже.
Структура файла скрипта
После двойного щелчка на скрипте в Unity, он будет открыт в текстовом редакторе. По умолчанию Unity будет использовать MonoDevelop, но вы можете выбрать любой редактор из панели External Tools в настройках Unity.
Содержимое файла будет выглядеть примерно так:
Заметка для опытных программистов: вы можете быть удивлены, что инициализация объекта выполняется не в функции-конструкторе. Это потому, что создание объектов обрабатывается редактором и происходит не в начале игрового процесса, как вы могли бы ожидать. Если вы попытаетесь определить конструктор для скриптового компонента, он будет мешать нормальной работе Unity и может вызвать серьезные проблемы с проектом.
A UnityScript script works a bit differently to C# script:
Здесь функции Start и Update имеют такое же значение, но класс не объявлен явно. Предполагается, что скрипт сам по себе определяет класс; он будет неявно производным от MonoBehaviour и получит своё имя от имени файла скриптового ассета.
Управление игровым объектом
Как было сказано ранее, скрипт определяет только план компонента и, таким образом, никакой его код не будет активирован до тех пор, пока экземпляр скрипта не будет присоединен к игровому объекту. Вы можете прикрепить скрипт перетаскиванием ассета скрипта на игровой объект в панели Hierarchy или через окно Inspector выбранного игрового объекта. Имеется также подменю Scripts в меню Component, которое содержит все скрипты, доступные в проекте, включая те, которые вы создали сами. Экземпляр скрипта выглядит так же, как и другие компоненты в окне Inspector:-
После присоединения скрипт начнет работать, когда вы нажмете Play и запустите игру. Вы можете проверить это добавив следующий код в функцию Start:-
Managed Plugins
Обычно скрипт в проекте содержится как файл исходного текста и компилируется Юнити при изменении. Однако также возможно компилировать скрипт в динамически связываемую библиотеку (dll) используя внешний компилятор. Результирующая dll может быть затем добавлена к проекту, а содержащиеся в ней классы прикреплены к объекту как обычные скрипты.
Создание dll
Путь к dll Юнити обычно такой
На Виндовс dll могут быт myfqltys в папках, принадлежащих приложению Юнити. Путь обычно такой
Использование dll
После компиляции dll файл может быт просто перетащен в Юнити проект как и любой другой ассет. Dll ассет имеет треугольник раскрывающий содержимое файла для выбора отдельного класса внутри библиотеки. Классы, которые были унаследованы от MonoBehaviour могут быть перетащены на ГеймОбъект как обычные скрипты. Не MonoBehaviour классы могут быт использованы прямо из других скриптов обычным путем.
Развернутая dll с классами в ней
Пошаговое руководство для MonoDevelop и Visual Studio
В этой секции вы узнаете как собрать и интегрировать простую dll с использованием MonoDevelop и Visual Studio, и как подготовить отладочную сессию для этой DLL.
Настройка проекта
Затем нужно заполнить информацию о новой библиотеке:
На данном этапе, у вас будет возможность выбрать нужный DLL файл. В Mac OSX, файл можно найти в
Для этого примера, переименуем класс в “MyUtilities” в Solution browser, и заменим его код на следующее:
Закончив с кодом, соберите проект, и сгенерируйте DLL файл с отладочными символами.
Использование DLL в Unity
/bin/Debug/DLLTest.dll в папку Assets. Затем, создайте C# скрипт под именем “Test” в Assets, и замените его содержимое на следующий код:
Когда вы присоедините этот скрипт к объекту в сцене, и нажмете Play, вы увидите вывод кода из DLL в окне консоли.
Настройка отладочного сеанса для DLL
Во-первых, вы должны исправить отладочные символы для DLL. В MonoDevelop, скопируйте файл сборки
/bin/Debug/DLLTest.dll.mdb в папку Assets/Plugins. В Visual Studio, выполните