как сделать ссылку на скрипт в unity
Методы организации взаимодействия между скриптами в Unity3D
Вступление
Подход 1. Назначение через редактор 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).
Где-то находится участок кода, который проверяет не погиб ли наш персонаж:
Получается, что персонаж после совей смерти должен разослать всем компонентам, которые в ней заинтересованы этот печальный факт, он должен знать о существовании этих компонентов и должен знать, что они им интересуются. Не слишком ли много знаний, для маленького юнита?
Так как игра, по логике, очень связанная структура, то и события происходящие в других компонентах интересуют третьи, юнит тут ничем не особенный.
Примеры таких событий (далеко не все):
— Условие прохождение уровня зависит от количества набранных очков, набрали 1000 очков – прошли уровень (LevelConditionManager связан с ScoresManager).
— Когда набираем 500 очков, достигаем важную стадию прохождения уровня, нужно проиграть веселую мелодию и визуальный эффект (ScoresManager связан с EffectsManager и SoundsManager).
— Когда персонаж восстанавливает здоровье, нужно проиграть эффект лечения над картинкой персонажа в панели персонажа (UnitsPanel связан с EffectsManager).
— и так далее.
В результате таких связей мы приходим к картине похожей на следующую, где все про всех все знают:
Пример со смертью персонажа немного преувеличен, сообщать о смерти (или другом событии) шести разным компонентам не так часто приходится. Но варианты, когда при каком-то событии в игре, функция, в которой произошло событие, сообщает об этом 2-3 другим компонентам встречается сплошь и рядом по всему коду.
Следующий подход пытается решает эту проблему.
Подход 3. Мировой эфир (Event Aggregator)
Введем специальный компонент «EventAggregator», основная функция которого хранить список событий, происходящих в игре.
Событие в игре — это функционал, предоставляющий любому другому компоненту возможность как подписаться на себя, так и опубликовать факт совершения этого события. Реализация функционала события может быть любой на вкус разработчика, можно использовать стандартные решения языка или написать свою реализацию.
Пример простой реализации события из прошлого примера (о смерти юнита):
Добавляем это событие в «EventAggregator»:
Теперь, функция Die из предыдущего примера с восемью строчками преобразуется в функцию с одной строчкой кода. Нам нет необходимости сообщать о том, что юнит умер всем заинтересованным компонентам и знать о этих заинтересованных. Мы просто публикуем факт свершения события:
А любой компонент, которому интересно это событие, может отреагировать на него следующим образом (на примере менеджера отвечающего за количество набранных очков):
В функции Awake менеджер подписывается на событие и передает делегат, отвечающий за обработку этого события. Сам же обработчик события, принимает в качестве параметра экземпляр умершего юнита и добавляет количество очков в зависимости от типа этого юнита.
Таким же образом, все другие компоненты, кому интересно событие смерти юнита, могут подписаться на него и обработать, когда событие произойдет.
В результате, диаграмма связей между компонентами, когда каждая компонента знала друг о друге, превращается в диаграмму, когда компоненты знают только о событиях, которые происходят в игре (только о интересующих их событиях), но им все равно, от куда эти события пришли. Новая диаграмма будет выглядеть следующим образом:
Замечание
Говоря, что никакой другой код не меняется, я конечно немножко лукавлю. Может оказаться так, что систему достижений интересуют события, которые ранее просто не публиковались в игре, потому как ни одну другую систему до этого не интересовали. И в этом случае, нам нужно будет решить какие новые события добавить в игру и кто будет их публиковать. Но в идеальной игре уже все возможные события есть и эфир наполнен ими по полной.
Плюсы
— не связанность компонентов, мне достаточно просто опубликовать событие, а кого оно интересует не имеет значение.
— не связанность компонентов, я просто подписываюсь на нужные мне события.
— можно добавлять отдельные модули без изменения в существующем функционале.
Минусы
— нужно постоянно описывать новые события и добавлять их в мир.
— нарушение функциональной атомарности.
Последний минус рассмотрим более детально
Представим, что у нас есть объект «ObjectA», в котором вызывается метод «MethodA». Метод «MethodA», состоит из трех шагов и вызывает внутри себя три других метода, которые выполняют эти шаги последовательно («MethodA1», «MethodA2» и «MethodA3»). Во втором методе «MethodA2» происходит публикация какого-то события. И тут происходит следующее: все кто подписан на это событие начнут его обрабатывать, выполняя какую-то свою логику. В этой логике тоже может произойти публикация других событий, обработка которых также может привести к публикации новых событий и так далее. Дерево публикаций и реакции в отдельных случаях может очень сильно разрастись. Такие длинные цепочки крайне тяжело отлаживать.
Но самая страшная проблема, которая тут может произойти, это когда одна из веток цепочки приводит обратно в «ObjectA» и начинает обрабатывать событие путем вызова какого-то другого метода «MethodB». Получается, что метод «MethodA» у нас еще не выполнил все шаги, так как был прерван на втором шаге, и содержит сейчас в себе не валидное состояние (в шаге 1 и 2 мы изменили состояние объекта, но последнее изменение из шага 3 еще не сделали) и при этом начинается выполняться «MethodB» в этом же объекте, имея это не валидное состояние. Такие ситуации порождают ошибки, очень сложно отлавливаются, приводят к тому, что надо контролировать порядок вызова методов и публикации событий, когда по логике этого делать нет необходимости и вводят дополнительную сложность, которую хотелось бы избежать.
Решение
Решить описанную проблему не сложно, достаточно добавить функционал отложенной реакции на событие. В качестве простой реализации такого функционала мы можем завести хранилище, в которое будем складывать произошедшие события. Когда событие произошло, мы не выполняем его немедленно, а просто сохраняем где-то у себя. И в момент наступления очереди выполнения функционала какой-то компоненты в игре (в методе Update, например) мы проверяем на наличие произошедших событий и выполняем обработку, если есть такие события.
Таким образом, при выполнении метода «MethodA» не происходит его прерывание, а опубликованное событие все заинтересованные записывают себе в специальное хранилище. И только после того как к заинтересованным подписчикам дойдет очередь, они достанут из хранилища событие и обработают его. В этот момент весь «MethodA» будет завершен и «ObjectA» будет иметь валидное состояние.
Unity ссылка на скрипт
В редакторе Unity вы изменяете свойства Компонента используя окно Inspector. Так, например, изменения позиции компонента Transform приведет к изменению позиции игрового объекта. Аналогично, вы можете изменить цвет материала компонента Renderer или массу твёрдого тела (RigidBody) с соответствующим влиянием на отображение или поведение игрового объекта. По большей части скрипты также изменяют свойства компонентов для управления игровыми объектами. Разница, однако, в том, что скрипт может изменять значение свойства постепенно со временем или по получению ввода от пользователя. За счет изменения, создания и уничтожения объектов в заданное время может быть реализован любой игровой процесс.
Обращение к компонентам
Наиболее простым и распространенным является случай, когда скрипту необходимо обратиться к другим компонентам, присоединенных к тому же GameObject. Как упоминалось во разделе Введение, компонент на самом деле является экземпляром класса, так что первым шагом будет получение ссылки на экземпляр компонента, с которым вы хотите работать. Это делается с помощью функции GetComponent. Типично, объект компонента сохраняют в переменную, это делается в C# посредством следующего синтаксиса:
В UnityScript синтаксис немного отличается:
Как только у вас есть ссылка на экземпляр компонента, вы можете устанавливать значения его свойств, тех же, которые вы можете изменить в окне Inspector:
Дополнительная возможность, недоступная в окне Inspector – вызов функций экземпляра компонента:
Имейте ввиду, что нет причины, по которой вы не можете иметь больше одного пользовательского скрипта, присоединенного к одному и тому же объекту. Если вам нужно обратиться к одному скрипту из другого, вы можете использовать, как обычно, GetComponent, используя при этом имя класса скрипта (или имя файла), чтобы указать какой тип Компонента вам нужен.
Если вы попытаетесь извлечь Компонент, который не был добавлен к Игровому Объекту, тогда GetComponent вернет null; возникнет ошибка пустой ссылки при выполнении (null reference error at runtime), если вы попытаетесь изменить какие-либо значения у пустого объекта.
Обращение к другим объектам
Пусть иногда они и существуют изолированно, все же, обычно, скрипты отслеживают другие объекты. Например, преследующий враг должен знать позицию игрока. Unity предоставляет несколько путей получения других объектов, каждый подходит для конкретной ситуации.
Связывание объектов через переменные
Самый простой способ найти нужный игровой объект – добавить в скрипт переменную типа GameObject с уровнем доступа public:
Переменная будет видна в окне Inspector, как и любые другие:
Теперь вы можете перетащить объект со сцены или из панели Hierarchy в эту переменную, чтобы назначить его. Функция GetComponent и доступ к переменным компонента доступны как для этого объекта, так и для других, то есть вы можете использовать следующий код:
Кроме того, если объявить переменную с доступом public и заданным типом компонента в вашем скрипте, вы сможете перетащить любой объект, который содержит присоединенный компонент такого типа. Это позволит обращаться к компоненту напрямую, а не через игровой объект.
Соединение объектов через переменные наиболее полезно, когда вы имеете дело с отдельными объектами, имеющими постоянную связь. Вы можете использовать массив для хранения связи с несколькими объектами одного типа, но связи все равно должны быть заданы в редакторе Unity, а не во время выполнения. Часто удобно находить объекты во время выполнения, и Unity предоставляет два основных способа сделать это, описанных ниже.
Нахождение дочерних объектов
Иногда игровая сцена может использовать несколько объектов одного типа, таких как враги, путевые точки и препятствия. Может возникнуть необходимость отслеживания их в определенном скрипте, который управляет или реагирует на них (например, все путевые точки могут потребоваться для скрипта поиска пути). Можно использовать переменные для связывания этих объектов, но это сделает процесс проектирования утомительным, если каждую новую путевую точку нужно будет перетащить в переменную в скрипте. Аналогично, при удалении путевой точки придется удалять ссылку на отсутствующий объект. В случаях, наподобие этого, чаще всего удобно управлять набором объектов, сделав их дочерними одного родительского объекта. Дочерние объекты могут быть получены, используя компонент Transform родителя (так как все игровые объекты неявно содержат Transform):
Вы можете также найти заданный дочерний объект по имени, используя функцию Transform.Find:
I’m creating a game that have multiples references to scripts, one to another.
My doubt enter when I can do two different things:
- In SomeBehavior access/edit GUI variable/function that I whant. Like:
1.1. variable = GameObject.Find(«GuiTag»).GetComponent ();
variable.score. and go on.
In SomeBehavior access/edit GUI variable/function by Controller.gui (gui a public variable on controller script). Centralization all the base scripts to one, in that way, having less variables in the scripts, less memory (perraps).
2.1. variable = GameObject.Find(«ControllerTag»).GetComponent ();
variable.gui.score.
Which one is better?
Создан 29 сен. 13 2013-09-29 13:26:14 user2828407
Benchmark and test. You should store results of ‘GameObject.Find’ if you’ll use them again, ‘Find’ is a spendy call. As far as memory goes. you should probably read up on C#’s reference types. «Less variables in the scripts» has little-to-no relation to memory. – Jerdak 30 сен. 13 2013-09-30 13:32:05
1 ответ
In the Scripts that you will only have one of you can set a public static variable in that class with a public get and private set. On the Start or Awake function you set that variable to this and then you can access that script easily from any other scripts.
Создан 29 сен. 13 2013-09-29 20:57:26 Shredder2500
Два основных компонента у объекта в Unity3D — это Transform и GameObject.
GameObject
GameObject — основа, контейнер, который содержит в себе все компоненты любой объект в Unity3D. Чтобы удалить, к примеру, игровой объект — удалять нужно именно GameObject этого объекта. Для доступа к GameObject — используется переменная, которая присутствует по умолчанию в любом скрипте, унаследованном от MonoBehaviour (то есть в любом скрипте, созданном через Unity3D).
Получение ссылки на игровой объект
Данным способом можно из одного скрипта получить ссылку на другие игровые объекты и управлять ими, их дочерними объектами, а также их компонентами.
Уничтожение игрового объекта
Данным способом можно удалить игровой объект.
Активация/деактивация игрового объекта
Деактивация объекта аналогична снятия галочки инспекторе Unity3D, которая обведена красным цветом на скриншоте ниже.
Деактивация элемента деактивирует также все его дочерние объекты и останавливает выполнение в их скриптов.
Добавление новых компонентов и скриптов игровому объекту
Таким образом можно добавить абсолютно любой компонент, либо скрипт, который можно добавить в редакторе Unity3D.
Получение доступа к компоненту игрового объекта
Таким же образом можно получить доступ к любому компоненту игрового объекта.
Переименование игрового объекта. Считывание имени объекта
Сделать объект статичным
Данный код аналогичен установке/снятию галочки в редакторе Unity3D (на скрине ниже).
Установить слои игровому объекту, а также считать их
Установить тэг игровому объекту, а также его считывание
Transform
С трансформом всё немного проще — этот компонент не является основой, но тем не менее — является основной и, главное, неотъемлемой частью GameObject’а. Он отвечает за месторасположение объекта на сцене, его «вращении», размерах, а также содержит информацию о дочерних и родительском объектах.
Это единственные компонент, который невозможно удалить из GameObject.
Изменение положение объекта
За положение объекта на сцене отвечает элементы transform.position и transform.localPosition.
Они оба являются переменной типа Vector3 и имеют в себе 3 главных составляющих x,y и z, которые соответствуют координатам в трехмерном пространстве. Следует учитывать, что x, y и z невозможно менять напрямую — они только для чтения. Чтобы добавить единичку к x — нужно добавить к самому transform.position новый Vector3, который равен (1,0,0), что добавить к x единицу, а к y и z — нули.
Чем же отличаются transform.position и transform.localPosition?
Их главное (и единственное отличие) заключается в том, что position — показывает и принимает координаты объекта, относительно мировых координат, а localPosition — относительно родительского объекта. Если же игровой объект является «корневым», то есть у него нет родительских объектов, то position и localPosition будут равны.
Движение объекта
Сначала рассмотрим элементарные варианты.
Как мы уже говорили — position (буду далее использовать именно его, так как отличия от localPosition только в том, относительно чего эти координаты) является переменной типа Vector3. Поэтому для его изменения нужно либо прибавить к нему другой вектор, либо вычесть другой вектор, либо заменить его другим вектором.
Рекомендуется использовать функцию transform.Translate.
Это уже не переменная, как transform.position — это функция. У неё есть два входящих параметра:
Вращение объекта
За вращение объекта отвечает компонент transform.rotation, transform.localRotation и функция transform.Rotate.
Здесь все аналогично transform.position. Кроме одного, несмотря на то, что в редакторе Unity3D Rotation представляет собой Vector3, то есть вращение относительно оси X, оси Y, оси Z. Но в коде оно представлено в виде кватернионов. Что такое кватернион — отдельная история. И обычно её изучают в вузах. По факту — знание кватернионов не обязательно для разработки игр. К счастью разработчики Unity3D это понимают и сделали две удобные для программистов вещи:
Меньше слов — больше кода:
Вместо rotation можно применять localRotation, аналогично position.
Такой подход аналогичен transform.Translate и также является более производительным.
Поиск других объектов на сцене
Есть два подхода поиска объекта на сцене.
Также можно запрашивать дочерние элементы по их номеру:
Также дочерний элемент может запросить родительский, а также родительский родительского и так далее:
В следующих статьях будет информация о том, что такое private, public, static, отправление сообщений игровым объектам.
12 комментариев для “Скрипты в Unity3D. Урок 0. Основы”
Отличный урок! Планируется ли продолжение?
Здравствуйте! Да, продолжение планируется и уже есть заготовки, но времени, увы, нет совсем =(
Присоединяюсь к предыдущем комментатору, очень жду продолжения.
Ну и отдельное спасибо за этот урок.
И коментарии бы типа:
var childTransform = transform.FindChild(«myChild1»); // находим myChild1 помещаем в childTransform
var childGameObject = childTransform.gameObject; // тут что происходит я хрен чё понимаю откуда что берётся
var anotherTransformLink = childGameObject.transform; // и зачем столько букав
А так-то нормуль, есть что законспектировать.
Здравствуйте! Спасибо за советы, я обязательно их учту при написании следующих статей.
Постараюсь вкратце ответить на ваши вопросы.
1) Слова в коде относятся к командам, классам, интерфейсам, или именам переменных. Обычно в C# с большой буквы пишется класс, интерфейс, или переменная с модификатором доступа ‘public’ (не забываем про функции). Где, как и в каких случаях что используется тяжело описать, так как это основы языка программирования C#.
Например:
var myObject = new MyObject().
Конкретно в данном случае — MyObject — это класс. А myObject — это конкретный экземпляр класса MyObject.
А вот другой пример:
public GameObject MyGameObject;
Это публичное свойство класса типа GameObject. Сам экземпляр данного класса называется MyGameObject и может быть доступен как и изнутри самого класса, так и из других классов, у которых есть ссылка на данный экземпляр класса.
2) Почему objectBoxCollider с маленькой, а BoxCollider с большой? ObjectBoxCollider — это имя класса, а objectBoxCollider — это его экземпляр..
К тому же Unity3d очень активно использует наследование (хотя бы взять любой скрипт — он наследован от MonoBehavior. Нужно знать как работает наследование и какой базовый функционал (и какие свойства) уже доступны «из коробки» у любого класса, который будет наследован от него.
Всё-таки Unity3D подразумевает, что у разработчика есть базовые знания C#, или JS. Я бы вам порекомендовал вначале почитать статьи с замечательного сайта https://metanit.com/sharp/tutorial/
Лучше чем там я объяснить всё равно не смогу 🙂
оО, о как, очень рад что сайт живой,ато вновь и вновь прочёсываю инет своими тегами, гляжу — котодомик))
думаю — та-ак, помню что там чтото полезное было пойду ещё загляну) а тут опаньки, живая планета,.
только вот пользователи сетей видать не очень жалуют домен «рф» и встречается он редковато,
буду значит наблюдать за сайтом,по возможности единомышленников подтягивать,
пс
C#
transform.position += new Vector3(1,0,0); // добавляем к X единице (смещаем на единицу)
transform.position += new Vector3(1,0,2)*Time.deltaTime; // двигаем объект в реальном времени с установленными значениями
по осям х и z
int speed = 5;
void Start()
transform.position += new Vector3(speed,0,0)*Time.deltaTime;//движение по оси х с заданием параметра(скорости) через переменную speed
transform.position += new Vector3(1,0,1)*speed*Time.deltaTime;// движение по заданным осям со скоростью установленной переменной speed
вот типа того бы, с пояснениями и дальнейшим развитием их применения
ещё поподробней бы про кватернионы и ейлеры, каким образом кватернион вывести в вектор3
про ригидбоди — нет нигде информации, как ограничивать угол поворота по осям,матф.кламп
как использовать драг по разным осям с разным значением
гравитация и енерция их ограничения и направления,
почему объект в вертикальном положении может подвергаться гравитации а в горизонтальном уже нет..+-
Спасибо за отзыв! Приятно! 🙂
Стараюсь поддерживать актуальность сайта по мере сил и возможности.
Отдельное спасибо за темы для новых статей.
Спасибо очень сильно помог, ещё раз большое спасибо.
есть vector3 как взять по нему gameObject?
Здравствуйте. К сожалению никак. Vector3 это структура данных, которая содержит информацию о точках X,Y,Z.
Vector3, как и Vector2 стоит рассматривать наравне с int, string, bool, float..
Например. Контейнер gameObject всегда содержит ссылку на компонент (обязательный) transform.
А transform содержит много свойств, отвечающих за позицию и размер объекта на сцене. Одно из свойств, как раз position — является Vector3.
Через любой компонент можно получить ссылку на gameObject, как и через gameObject можно получить ссылку на любой компонент, который данный gameObject содержит внутри себя.
Например: var boxColl >();
Но Vector3 не является компонентом в Unity3D.
Являются компонентами только те объекты, которые можно добавить к gameObject’у, используя графический интерфейс редактора Unity3D.
Спасибо за хорошо изложенную информацию) Сделал по туторам три простеньких игру, просто повторяя все за автором курса. Но во многое не въехал. Тут почитал, многое встало на свои места сразу. У вас талант к ясному изложению. Не бросайте это дело)
Здравствуйте! Большое спасибо за ваш отзыв 🙂
К сожалению сейчас нет особой возможности вести блог.
Но если у вас есть какие-то конкретные вопросы по Unity3D, то я могу с удовольствием на них ответить.