Готовый перевод C# Game Programming Cookbook for Unity 3D / Программирование игр на Unity 3D C#. Книга готовых решений.: 1.1.2 Связь скриптов

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

1. Прямые ссылки на переменные управляющих скриптов, изменяемые в редакторе окна Инспектора.

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

public void aScript otherScript;

В редакторе, Инспекторе будет видно поле otherScript. На это поле перетаскивается,объект содержащий скрипт, с который мы хотим связаться. А в классе, вызываем функцию этой переменой, например,

otherScript.DoSomething();

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

SomeGameObject.SendMessage("DoSomething");

SendMessage может также принимать несколько параметров, так бы из передача не вызывала ошибки, того что нет приемника, то есть, нет функции в скрипте, прикрепленному к GameObject с именем, совпадающим с в вызовом SendMessage. (SendMessageOptions). Вы также можете передать один параметр в выбранной функции так же, как если вы просто обычно вызывали функцию, на пример

SomeGameObject.SendMessage("AddScore",2);
SomeGameObject.SendMessage("AddScore",
SendMessageOptions.RequireReceiver);
SomeGameObject.SendMessage("AddScore",
SendMessageOptions.DontRequireReceiver);

3. Статические переменные.
Статическая переменная полезна для связи, поскольку оно распространяется по всей системе; она будет доступна в любом другом скрипте. Это особенно полезно для скриптов управления игрой, где несколько различных скриптов общаются с остальными решая такие вещи, как добавить к счету игрока, потеряете жизни, или, возможно, изменить уровень.
Пример декларация статической переменной

private static GameController aController;

Хотя статические переменные видны во всей программе, вы можете их делать частные и публичные. Все становится немного сложнее, когда вы пытаетесь понять разницу между частной и публичной статической переменой. Мне повезло иметь друзей в Twitter, которые смогли объяснить все это для меня, так что позвольте мне передать, что мне сказали:

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

1 В нашем скрипте gamecontroller.cs контролирующему игру, мы создали открытую статическую переменую:

public static GameController gateway;

2 Когда игровой контроллер (gamecontroller.cs) запускает функцию Start (), она сохраняет ссылку на себя в публичной статической переменной, как это:

gateway = this;

3 Из любова другова класса, мы можем теперь получить доступ в игровой контроллер, ссылаясь на его типа а потом на статическую переменную (GameController.gateway), вот так

GameController.gateway.GotBanana();

Частная статическая переменная
Частная статическая переменная видима в классе и в любых других объектах того же класса. Другие классы / скрипты не смогут получить доступа к ней.

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

private static PlayerManager playerManager;

Объект PlayerManager должен быть создан только один раз, для всех экземпляров класса игрока, чтобы быть его можно было использовать для объектов этого класса. Все player.cs скрипты смогут иметь доступ к этому экземпляру PlayerManager.

4 Дизайн шаблон Singleton
В предыдущей части этого раздела, мы рассмотрели использование статической переменной предоставляющей доступ к скрипту менеджеру игры. Самая большая опасность этого метода является то, что можно создать несколько экземпляров одного и того же скрипта. Если это произойдет, вы можете обнаруживать, что ваш скрипт игрока сообщает не тому экземпляру менеджера игры.

Singletonis стандартный шаблон проектирования, который позволяет создавать только один объект определенного класса. Эта модель идеально подходит для игровых скриптов, которым, придется общаться по всему коду игры. Обратите внимание, что мы будем предоставлять статический ссылку на скрипт, точно так же, как мы делали в методе "Статические переменные» ранее в этом разделе, но в реализации класса Singletonis, мы будем добавлять дополнительный код, чтобы убедиться, что только один экземпляр нашего скрипта мог быть создан.

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/55263/242396

Переводчики: Zeke0028