Как использовать функцию из другого скрипта unity

MonoBehaviour.Invoke

Thank you for helping us improve the quality of Unity Documentation. Although we cannot accept all submissions, we do read each suggested change from our users and will make updates where applicable.

Submission failed

For some reason your suggested change could not be submitted. Please <a>try again</a> in a few minutes. And thank you for taking the time to help us improve the quality of Unity Documentation.

Declaration

Description

Invokes the method methodName in time seconds.

If time is set to 0 and Invoke is called before the first frame update, the method is invoked at the next Update cycle before MonoBehaviour.Update. In this case, it’s better to call the function directly.

Note: Setting time to negative values is identical to setting it to 0.

In other cases, the order of execution of the method depends on the timing of the invocation.

If you need to pass parameters to your method, consider using Coroutine instead. Coroutines also provide better performance.

Unity. Вызов функции из другого скрипта

Помогите дописать код
Нужно чтобы при таче по кнопке выполнялась функция (func1) из другого скрипта (anotherScript).

Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.3.11.43300

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Методы организации взаимодействия между скриптами в Unity3D

Пусть у нас в проекте есть два скрипта. Первый скрип отвечает за начисление очков в игре, а второй за пользовательский интерфейс, который, отображает количество набранных очков на экране игры.
Назовем оба скрипта менеджерами: ScoresManager и HUDManager.
Каким же образом менеджеру, отвечающему за меню экрана можно получить текущее количество очков от менеджера, отвечающего за начисление очков?
Предполагается, что в иерархии объектов(Hierarchy) сцены существуют два объекта, на один из которых назначен скрипт ScoresManager, а на другой скрипт HUDManager.
Один из подходов, содержит следующий принцип:
В скрипте UIManager определяем переменную типа ScoresManager:

Но переменную ScoresManager необходимо еще инициализировать экземпляром класса. Для этого выберем в иерархии объектов объект, на который назначен скрипт HUDManager и в настройках объекта увидим переменную ScoresManager со значением None.

Далее, из окна иерархии перетаскиваем объект, содержащий скрипт ScoresManager в область, где написано None и назначаем его объявленной переменной:

После чего, у нас появляется возможность из кода HUDManager обращаться к скрипту ScoresManager, таким образом:

Все просто, но игра, не ограничивается одними набранными очками, HUD может отображать текущие жизни игрока, меню доступных действия игрока, информацию о уровне и многое другое. Игра может насчитывать в себе десятки и сотни различных скриптов, которым нужно получать информацию друг от друга.
Чтобы получить в одном скрипте данные из другого скрипта нам каждый раз придется описывать переменную в одном скрипте и назначать (перетаскивать вручную) ее с помощью редактора, что само по себе нудная работа, которую легко можно забыть сделать и потом долго искать какая из переменных не инициализирована.
Если мы захотим что-то отрефакторить, переименовать скрипт, то все старые инициализации в иерархии объектов, связанные с переименованным скриптом, сбросятся и придется их назначать снова.
В то же время, такой механизм не работает для префабов (prefab) — динамического создания объектов из шаблона. Если какому-либо префабу нужно обращаться к менеджеру, расположенному в иерархии объектов, то вы не сможете назначить самому префабу элемент из иерархии, а придется сначала создать объект из префаба и после этого программно присвоить экземпляр менеджера переменной только что созданного объекта. Не нужная работа, не нужный код, дополнительная связанность.
Следующий подход решает все эти проблемы.

Подход 2. «Синглтоны»

Применим упрощенную классификацию возможных скриптов, которые используются при создании игры. Первый тип скриптов: «скрипты-менеджеры», второй: «скрипты-игровые-объекты».
Основное отличие одних от других в том, что «скрипты-менеджеры» всегда имеют единственный экземпляр в игре, в то время как «скрипты-игровые-объекты» могут иметь количество экземпляров больше единицы.

Примеры

Как правило, в единственном экземпляре существуют скрипты, отвечающие за общую логику пользовательского интерфейса, за проигрывание музыки, за отслеживание условий завершения уровня, за управление системой заданий, за отображение спецэффектов и так далее.
В то же время, скрипты игровых объектов существуют в большом количестве экземпляров: каждая птичка из «Angry Birds» управляется экземпляром скрипта птички со своим уникальным состоянием; для любого юнита в стратегии создается экземпляр скрипта юнита, содержащий его текущее количество жизней, позицию на поле и личную цель; поведение пяти разных иконок обеспечивается различными экземплярами одних и тех же скриптов, отвечающих за это поведение.
В примере из предыдущего шага скрипты HUDManager и ScoresManager всегда существуют в единственном экземпляре. Для их взаимодействия друг с другом применим паттерн «синглтон» (Singleton, он же одиночка).
В классе ScoresManager опишем статическое свойство типа ScoresManager, в котором будет храниться единственный экземпляр менеджера очков:

Осталось инициализировать свойство Instance экземпляром класса, который создает среда Unity3D. Так как ScoresManager наследник MonoBehaviour, то он участвует в жизненном цикле всех активных скриптов в сцене и во время инициализации скрипта у него вызывается метод Awake. В этот метод мы и поместить код инициализации свойства Instance:

После чего, использовать ScoresManager из других скриптов можно следующим образом:

Теперь нет необходимости в HUDManager описывать поле типа ScoresManager и назначать его в редакторе Unity3D, любой «скрипт-менеджер» может предоставлять доступ к себе через статическое свойство Instance, которое будет инициализировать в функции Awake.

Плюсы

— нет необходимости описывать поле скрипта и назначать его через редактор Unity3D.
— можно смело рефакторить код, если что и отвалится, то компилятор даст знать.
— к другим «скриптам-менеджерам» теперь можно обращаться из префабов, через свойство Instance.

Минусы

— подход обеспечивает доступ только к «скриптам-менеджерам», существующим в единственном экземпляре.
— сильная связанность.
На последнем «минусе» остановимся подробнее.
Пусть мы разрабатываем игру, в которой есть персонажи (unit) и эти персонажи могут погибать (die).
Где-то находится участок кода, который проверяет не погиб ли наш персонаж:

Каким образом игра может отреагировать на смерть персонажа? Множеством разнообразных реакций! Приведу несколько вариантов:
— надо удалить персонажа из сцены игры, чтобы он больше не отображался на ней.
— в игре начисляются очки за каждого погибшего персонажа, нужно их начислить и обновить значение на экране.
— на специальной панели отображаются все персонажи в игре, где мы можем выбрать конкретного персонажа. При смерти персонажа, нам нужно обновить панель, либо убрать персонажа с нее, либо отобразить что он мертв.
— нужно проиграть звуковой эффект смерти персонажа.
— нужно проиграть визуальный эффект смерти персонажа (взрыв, брызги крови).
— система достижений игры имеет достижение, которое считает общее число убитых персонажей за все время. Нужно добавить к счетчику только что умершего персонажа.
— система аналитики игры отправляет на внешний сервер факт смерти персонажа, нам этот факт важен для отслеживания прогресса игрока.
Учитывая все вышеперечисленное, функция Die может выглядеть следующим образом:

Получается, что персонаж после совей смерти должен разослать всем компонентам, которые в ней заинтересованы этот печальный факт, он должен знать о существовании этих компонентов и должен знать, что они им интересуются. Не слишком ли много знаний, для маленького юнита?
Так как игра, по логике, очень связанная структура, то и события происходящие в других компонентах интересуют третьи, юнит тут ничем не особенный.
Примеры таких событий (далеко не все):
— Условие прохождение уровня зависит от количества набранных очков, набрали 1000 очков – прошли уровень (LevelConditionManager связан с ScoresManager).
— Когда набираем 500 очков, достигаем важную стадию прохождения уровня, нужно проиграть веселую мелодию и визуальный эффект (ScoresManager связан с EffectsManager и SoundsManager).
— Когда персонаж восстанавливает здоровье, нужно проиграть эффект лечения над картинкой персонажа в панели персонажа (UnitsPanel связан с EffectsManager).
— и так далее.
В результате таких связей мы приходим к картине похожей на следующую, где все про всех все знают:

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

Подход 3. Мировой эфир (Event Aggregator)

Введем специальный компонент «EventAggregator», основная функция которого хранить список событий, происходящих в игре.
Событие в игре — это функционал, предоставляющий любому другому компоненту возможность как подписаться на себя, так и опубликовать факт совершения этого события. Реализация функционала события может быть любой на вкус разработчика, можно использовать стандартные решения языка или написать свою реализацию.
Пример простой реализации события из прошлого примера (о смерти юнита):

Добавляем это событие в «EventAggregator»:

Теперь, функция Die из предыдущего примера с восемью строчками преобразуется в функцию с одной строчкой кода. Нам нет необходимости сообщать о том, что юнит умер всем заинтересованным компонентам и знать о этих заинтересованных. Мы просто публикуем факт свершения события:

А любой компонент, которому интересно это событие, может отреагировать на него следующим образом (на примере менеджера отвечающего за количество набранных очков):

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

Я же люблю другую интерпретацию: представьте, что прямоугольник «EventAggregator» растянулся во все стороны и захватил внутрь себя все остальные прямоугольники, превратившись в границы мира. В моей голове, на этой диаграмме «EventAggregator» вообще отсутствует. «EventAggregator» это просто мир игры, некий «игровой эфир», куда различные части игры кричат «Эй, народ! Юнит такой-то умер!», и все прослушивают эфир и если какое-то из услышанных событий их заинтересует, они на него отреагируют. Таким образом — связей нет, каждый компонент независим.
Если я компонент и отвечаю за публикацию какого-то события, то я кричу в эфир мол этот умер, этот получил уровень, снаряд врезался в танк. И мне наплевать интересно кому-нибудь об этом. Возможно, никто не слушает это событие сейчас, а может на него подписана сотня других объектов. Меня, как автора события, это ни грамма не волнует, я про них ничего не знаю и знать не хочу.
Такой подход позволяет легко вводить новый функционал без изменения старого. Допустим, в готовую игру мы решили добавить систему достижений. Мы создаем новую компоненту системы достижений и подписываемся на все интересующие нас события. Никакой другой код не меняется. Не надо ходить по другим компонентам и из них вызывать систему достижений и говорить ей мол и мое событие посчитай пожалуйста. К тому же, все кто публикуют события в мире ничего не знают о системе достижений, даже о факте ее существования.

Замечание

Говоря, что никакой другой код не меняется, я конечно немножко лукавлю. Может оказаться так, что систему достижений интересуют события, которые ранее просто не публиковались в игре, потому как ни одну другую систему до этого не интересовали. И в этом случае, нам нужно будет решить какие новые события добавить в игру и кто будет их публиковать. Но в идеальной игре уже все возможные события есть и эфир наполнен ими по полной.

Плюсы

— не связанность компонентов, мне достаточно просто опубликовать событие, а кого оно интересует не имеет значение.
— не связанность компонентов, я просто подписываюсь на нужные мне события.
— можно добавлять отдельные модули без изменения в существующем функционале.

Минусы

— нужно постоянно описывать новые события и добавлять их в мир.
— нарушение функциональной атомарности.

Последний минус рассмотрим более детально

Представим, что у нас есть объект «ObjectA», в котором вызывается метод «MethodA». Метод «MethodA», состоит из трех шагов и вызывает внутри себя три других метода, которые выполняют эти шаги последовательно («MethodA1», «MethodA2» и «MethodA3»). Во втором методе «MethodA2» происходит публикация какого-то события. И тут происходит следующее: все кто подписан на это событие начнут его обрабатывать, выполняя какую-то свою логику. В этой логике тоже может произойти публикация других событий, обработка которых также может привести к публикации новых событий и так далее. Дерево публикаций и реакции в отдельных случаях может очень сильно разрастись. Такие длинные цепочки крайне тяжело отлаживать.
Но самая страшная проблема, которая тут может произойти, это когда одна из веток цепочки приводит обратно в «ObjectA» и начинает обрабатывать событие путем вызова какого-то другого метода «MethodB». Получается, что метод «MethodA» у нас еще не выполнил все шаги, так как был прерван на втором шаге, и содержит сейчас в себе не валидное состояние (в шаге 1 и 2 мы изменили состояние объекта, но последнее изменение из шага 3 еще не сделали) и при этом начинается выполняться «MethodB» в этом же объекте, имея это не валидное состояние. Такие ситуации порождают ошибки, очень сложно отлавливаются, приводят к тому, что надо контролировать порядок вызова методов и публикации событий, когда по логике этого делать нет необходимости и вводят дополнительную сложность, которую хотелось бы избежать.

Решение

Решить описанную проблему не сложно, достаточно добавить функционал отложенной реакции на событие. В качестве простой реализации такого функционала мы можем завести хранилище, в которое будем складывать произошедшие события. Когда событие произошло, мы не выполняем его немедленно, а просто сохраняем где-то у себя. И в момент наступления очереди выполнения функционала какой-то компоненты в игре (в методе Update, например) мы проверяем на наличие произошедших событий и выполняем обработку, если есть такие события.
Таким образом, при выполнении метода «MethodA» не происходит его прерывание, а опубликованное событие все заинтересованные записывают себе в специальное хранилище. И только после того как к заинтересованным подписчикам дойдет очередь, они достанут из хранилища событие и обработают его. В этот момент весь «MethodA» будет завершен и «ObjectA» будет иметь валидное состояние.

Communication between Scripts — Examples in Unity

In this arti­cle we see how to CALL FUNCTIONS and READ VARIABLES that are defined in a dif­fer­ent script in Uni­ty. This is espe­cial­ly impor­tant to cre­ate object-ori­ent­ed solu­tions, because being able to access oth­er scripts allows us to cre­ate scripts that solve spe­cif­ic prob­lems and work with oth­er scripts to achieve a big­ger result, sep­a­rat­ing respon­si­bil­i­ty, increas­ing abstrac­tion. In addi­tion you will also find two videos about call­ing func­tions and read­ing vari­ables from anoth­er script in Unity.

Dear read­er

In the chan­nel there lots of videos about Blender, Uni­ty and pro­gram­ming
in which we solve dif­fer­ent prob­lems and we pro­vide use­ful infor­ma­tion on these topics.

ABOUT THESE VIDEOS

Here you have two videos about access­ing vari­ables and call­ing func­tions from anoth­er script. All the infor­ma­tion is pre­sent­ed to you as gener­ic exam­ples, two scripts, «Scrip­tA» and «ScriptB«, the vari­able we want to read and the func­tion we want to call are defined in Scrip­tA, so from ScriptB we are going to access to Scrip­tA.

HERE YOU HAVE MY UNITY PLAYLIST
����

What should we take into account?

Let’s look at a list of items to keep in mind to under­stand the basis behind the inter­ac­tion between scripts.

About the Scripts

In this case we are going to see an exam­ple in Uni­ty, there­fore the two Scripts we are going to use will be an exten­sion of the MonoBe­hav­iour class. This, in prac­ti­cal terms, means that when the game starts, a «Start» func­tion will be exe­cut­ed and also in each frame of the game an «Update» method will be auto­mat­i­cal­ly executed.

About the execution of Scripts

In order to exe­cute the code that we will include in our scripts, those scripts must be assigned to at least one «GameOb­ject» in the hier­ar­chy of the scene we will run. In pro­gram­ming, there must exist an Instance of the class defined in the Script.

Instances of a classes

When we add the same Script to two dif­fer­ent GameOb­jects we are cre­at­ing two sep­a­rate instances of the class, i.e. two objects that are going to be sim­i­lar because they come from the same class, but their inter­nal state will not nec­es­sar­i­ly be the same all the time.

Having the reference of an object

This is one of the key points to pay atten­tion to and try to under­stand in depth.

Objects in pro­gram­ming are instances of a cer­tain class and in order to access its func­tion­al­i­ty, that is to say read its pub­lic para­me­ters or exe­cute its pub­lic func­tions, we must have the ref­er­ence of the object we need to use, in oth­er words find the object among all the oth­er objects that exist in the program.

The Dot Operator

The dot oper­a­tor in sev­er­al pro­gram­ming lan­guages allows us to access the pub­lic fields and meth­ods from an object. In oth­er words, if we have the object ref­er­ence, we can apply the dot oper­a­tor to it in order to exe­cute any of its pub­lic meth­ods or read and write any of its pub­lic fields.

MOST SEARCHED VIDEOS FROM MY CHANNEL

ABOUT UNITY

ABOUT BLENDER

Practical example of Interaction between Scripts in C# — Unity

Previous Steps

In any Uni­ty project we cre­ate two Scripts, Scrip­tA and ScriptB, in the first one we define the func­tion that will be exe­cut­ed from the sec­ond Script.

In the hier­ar­chy we are going to cre­ate two emp­ty GameOb­jects to be able to cre­ate instances of both Scripts.

In GameOb­jec­tA we add the Scrip­tA as com­po­nent and in GameOb­jectB the ScriptB. We can do this from the inspec­tor with the «Add Com­po­nent» but­ton or by drag­ging the script to the inspec­tor of the GameObject.

Code inside the Scripts

Let’s write the instruc­tions we’ll use to per­form the inter­ac­tion between Scripts.

When you cre­ate a new Script in Uni­ty, it will come with some func­tions pre­de­fined, as you can see in fig­ure 5. The «Start» and «Update» method, which will be auto­mat­i­cal­ly exe­cut­ed if the Script is assigned to at least one GameOb­ject from the hierarchy.

Functions and Variables from «ScriptA»

In the first Script we are going to write the fol­low­ing code:

A pub­lic string called «name» that will help us iden­ti­fy which instance it is.

Two meth­ods, one called «Function1» and the oth­er «Function2«, the first func­tion we will define it as pub­lic and the sec­ond pri­vate, lines 10 and 16 respec­tive­ly from fig­ure 6.

We will be able to access the «Function1» method through the dot oper­a­tor because it was defined with pub­lic vis­i­bil­i­ty. , as it’s defined as public.

As we can see in fig­ure 6, «Function1» prints in con­sole the result of the exe­cu­tion of «Function2«. This method returns a text that will allow us to see who is the object that is exe­cut­ing the «Function1» method and which instance of the Scrip­tA class it is.

Functions and Variables from «ScriptB»

The «ScriptB» script will be the one that calls the func­tion defined in the oth­er Script A. In fig­ure 7 we see the instruc­tions defined in the «ScriptB» script.

We define a string to assign a name and know which instance it is.

To be able to exe­cute func­tions defined in anoth­er Script we must have the ref­er­ence of the instance of that class. So let’s define a Scrip­tA type vari­able and name it «scrip­tA» (first let­ter with low­er­case), as we see in line 13 of fig­ure 7.

Here we only have half of the work done, we declared the
«A» vari­able inside «B», but this vari­able is emp­ty (a null vari­able) and will remain emp­ty unless we do some­thing about it.

To find the ref­er­ence of an object in a Script there are sev­er­al ways, in this case I will use a func­tion calle «FindObjectOfType<T>» where «T» is the type of the vari­able we want to find. This func­tion will search in the hier­ar­chy an object of the indi­cat­ed type and return the ref­er­ence of that object if it founds it. See line 18 of fig­ure 7.

Now that we have the ref­er­ence of the «A» object, inside «B» we can exe­cute the «Function1» func­tion that is defined inside the A Script. Line 20 from fig­ure 7).

Dot Operator

As men­tioned before, the dot oper­a­tor will allow us to access all the fields and pub­lic meth­ods defined with­in the class.

In fig­ures 8 and 9 we see that using the ref­er­ence of the Scrip­tA-type object fol­lowed by a dot, we can see the list of fields and meth­ods that are avail­able to use.

In fig­ure 8 we see the «name» vari­able that was the pub­lic string defined inside «Scrip­tA» and in fig­ure 9 we see the «Function1» method, also defined as pub­lic. We can’t see the «Function2» method because it was declared as pri­vate.

First exectution test

Before enter in the Play mode, we select GameOb­jects «A» and «B» from the hier­ar­chy and write names in the «name» fields to be able to ana­lyze the exe­cu­tion of our code.

The «Scrip­tA» instance will be called «George (A)» and the
«ScriptB» instance will be called «Mike (B)«, as we see in fig­ures 10 and 11.

When enter­ing in the Play mode we see in the inspec­tor of GameOb­jectB that the «Scrip­tA» field shows an object (unlike fig­ure 11 where it said «none»). This means that the «ScriptB» was able to find the «Scrip­tA» ref­er­ence.

Fig­ure 13 shows the on-screen mes­sage, print­ed by the Scrip­tA Function1 method, which was called from the ScriptB.

The mes­sage says: «Mike(B) has exe­cut­ed my Function1. I’m George(A), by the way.

Second execution test

Let’s go a lit­tle deep­er into the con­cept of pro­gram­ming object as an instance of a class.

Choose GameOb­jec­tA from the hier­ar­chy and add a sec­ond instance of the Scrip­tA class using the «Add Com­po­nent» or drag and drop button.

This sec­ond instance will be called «Luke (A)«, in fig­ure 14 we see both instances of the class.

When run­ning the game as it is, we see in the con­sole that Mike (B) has exe­cut­ed the Function1 method of Luke (A), see fig­ure 15.

What has hap­pened here is that the «Find­Ob­jectOfType<>» func­tion in line 18 of fig­ure 7, has found a dif­fer­ent ref­er­ence of a Scrip­tA type object than before, the «name» vari­able from this ref­er­ences is «Luke (A)«. A dif­fer­ent instance of the same class as the one that has the text «George (A)» in its «name» variable.

Now lets mod­i­fy the code in «ScriptB» so that it is able to find all the «Scrip­tA» ref­er­ences in the scene and exe­cute the «Function1» method of each one of them.

In the object dec­la­ra­tion we have now defined an array (or vec­tor) of «Scrip­tA» type objects (line 13 fig­ure 16), this means that we will be able to save sev­er­al ref­er­ences of Script­sA objects.

In line 18 of fig­ure 16 the change is rather sub­tle, instead of run­ning the «FindObjectOfType<T>» func­tion we use «FindObjectsOfType<T>«, this oth­er func­tion returns all the ref­er­ences of the indi­cat­ed «T» type that is able to find in the hierarchy.

The last thing we do is go through all the ele­ments of the array using a fore­ach loop and we exe­cute the «Function1» method to all of them, as can be seen in lines 20 to 23 of fig­ure 16.

When enter­ing again in the Play Mode, we see that now in the GameOb­jectB inspec­tor we have the «Scrip­tA» object ref­er­ences (fig­ure 17) inside an array of size 2.

And now in the con­sole appear two mes­sages, the first cor­re­sponds to the exe­cu­tion of Luke’s «Function1» method and the sec­ond to the exe­cu­tion of George’s «Function2» method.

Third execution test

We are going to mod­i­fy the ScriptB again to see anoth­er way to obtain the ref­er­ences of the objects and thus to be able to call their func­tions from anoth­er Script.

In this case, in the «ScriptB«, we are going to declare two seri­al­ized «Scrip­tA» objects (they can also be pub­lic, the idea is that they appear in the inspec­tor). These objects will be called «scrip­tALuke» and «Scrip­tA­George«.

Then in the Start method we are going to exe­cute the «Function1» meth­ods direct­ly using these objects. In this case it is not nec­es­sary to find the ref­er­ences through code since we will assign them direct­ly in the inspec­tor.

The mod­i­fied «ScriptB» is shown below.

In the inspec­tor we can see the new fields for «Scrip­tA» objects (fig­ure 20).

We will mod­i­fy a lit­tle the GameOb­jects of the hier­ar­chy, we will have an Emp­ty GameOb­ject called A‑Luke and anoth­er called A‑George.

In each GameOb­ject we assign the Scrip­tA com­po­nent and com­plete the cor­re­spond­ing name, see fig­ures 22 and 23.

Now let’s take the GameOb­jects from the hier­ar­chy and assign them in the cor­re­spond­ing fields of the «ScriptB»

In fig­ures 25 and 26 we see that the ref­er­ences have been assigned man­u­al­ly, this means that we can exe­cute the «Function1» meth­ods from each instance.

In con­sole we see that the mes­sages are print­ed due to the exe­cu­tion of «Function1» method on both instances.

Before fin­ish­ing I would like to change the order of exe­cu­tion of the Function1 meth­ods in the ScriptB, as seen in fig­ure 28.

When we do this and enter in the Play Mode again we see that the mes­sages on the con­sole switch places, fig­ure 29.

Conclusion

We have seen how to call func­tions that are defined in oth­er Scripts. This is only pos­si­ble if the func­tions are declared with pub­lic vis­i­bil­i­ty, this allows the access from exter­nal con­texts.

In addi­tion we must have the ref­er­ence of the object that con­tains that method to exe­cute, this can be achieved in sev­er­al ways, in this arti­cle we saw three ways to do it. It’s impor­tant to under­stand the con­cept of instances in pro­gram­ming, it can be two or more instances of the same class and there­fore mul­ti­ple objects with the same func­tion defined but the result of the exe­cu­tion of that func­tion on each instance could be different.

Under­stand in depth the con­cept of object in pro­gram­ming, which is the instance of a class and the fact that in order to access anoth­er object we must have the ref­er­ence of that object, allow us to build more com­plex solu­tions, sep­a­rat­ing respon­si­bil­i­ty, increas­ing the abstrac­tion of our solutions.