Даниил Басманов

Вам нужно не папку поменять, а создать проект в Android Studio и либо собрать aar-файл, либо скопировать проект целиком в папку с плагинами. Подробности читайте в мануале.

Юнитёвый UI для сортировки элементов использует индекс трансформа в иерархии относительно родителя. Работать с этим индексом можно с помощью методов Transform.GetSiblingIndex и Transform.SetSiblingIndex. Конкретно для примера с оттягиванием и обновлением пригодится метод Transform.SetAsFirstSibling, только учтите, что обновление будет происходить рывком, если хотите получить плавную анимацию, то придётся использовать трюки, либо писать свой класс для прокручиваемого списка.

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

Чаще всего берут и просто расставляют BoxCollider'ы, это долго и нудно, зато производительно и гибко. В качестве альтернативы можно использовать MeshCollider, но он дороже и с ним сложнее итерироваться. Ускорить работу с ним можно с помощью ProBuilder или аналогичного плагина. Иногда ещё пишут утилиты для редактора, которые расстанавливают коллайдеры по заданному пути. Если уровень не собираетесь сильно менять, то я бы посоветовал использовать BoxCollider, в ином случае берите ProBuilder.

ToggleGroup для того и нужен, чтобы нельзя было выделить несколько галочек, читайте внимательнее мануал. Если хотите выделить несколько - удалите ToggleGroup, вот и всё.

Загруженные спрайты не удаляются, если вы сидите на одной сцене, если вы меняете сцену, то всё должно выгрузиться автоматически при условии, что у вас в каком-нибудь синглтоне не осталась висеть ссылка. UnloadUnusedAssets может помочь в ситуации, когда вы нагрузили кучу разных ресурсов, использовали их, потом обнулили все ссылки и хотите всё вычистить. Если это одиночные большие картинки, то лучше выгружать более явным образом через Resources.UnloadAsset. В этот метод нужно передавать то, что вы загрузили из ресурсов, например, если вы загрузили текстуру и создали из неё спрайт с помощью Sprite.Create, то передавать нужно текстуру, а не спрайт. С Destroy нужно работать аккуратно, он тоже может освободить память, но в некоторых ситуациях он может удалить объект так, что вы потом без перезапуска приложения не сможете его повторно загрузить. Ещё настоятельно рекомендую подобный код тестировать изолированно на отдельной сцене на целевом устройстве, в редакторе правильность выгрузки не проверить.

Плохо искали, на эту тему есть официальный туториал, а в ассет сторе можно скачать проект с примерами настроек.

Это больше вопрос вкуса, я видел оба варианта, сам тоже использую SerializeField, но чаще склоняюсь к пропертям, а не методам, но, опять-таки, всё зависит от проекта. Ещё видел часто подход вида:

[SerializeField]
private int _field;
public int field { get { return _field; } set { _field = value; } }

Если говорить про абстрактный код в вакууме, то лучше данные наружу отдавать вообще через интерфейсы, но это не всегда целесообразно, особенно в контексте юнити. А так вообще да, с любым публичным полем есть риск, что его снаружи кто-то дёрнет и что-то заломает, поэтому лучше видимость переменных ограничивать по максимуму.

Всё сводится к поиску положения мышки в мировых координатах, после этого, зная положение игрока, можно делать всё, что душе угодно. Основные методы, которые вам нужны это Camera.ScreenPointToRay и Camera.ScreenToWorldPoint. Кроме того, на эту тему есть официальный туториал, рекомендую посмотреть.

Если нужно просто узнать совпадает ли направление векторов, то можно использовать Vector3.Dot. Если нужны градусы, то для этого есть Vector3.Angle.

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

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

Потому что порог вхождения очень низкий и любой рукожопый разработчик может дотащить свою игру до магазина. Сам движок ни в чём не виноват кроме доступности, средств для оптимизации предостаточно: встроенный профайлер, внешние профайлеры, Frame Debugger, RenderDoc и т. п.

Нагружает движок всё, что есть в игре. Если оно сделано неаккуратно или из рук вон плохо, то и результат будет соответствующий. Решается это построением правильного производственного процесса и регулярным тестированием и профилированием. Если в план разработки изначально не заложена фаза тестирования и полировки, то потом, скорее всего, на неё уже не останется ресурсов. Кроме того, некоторые оптимизации требуют изменения подхода к разработке и на полуготовой игре их уже не применить. Многие студии находятся под влиянием "людей с деньгами", которые ожидают увидеть результат в кратчайшие сроки, а процесс оптимизации видимых результатов практически не даёт, и, если игра большую часть времени нормально играется, то на всё остальное закрывают глаза. Кроме того, тормоза и баги редко сильно влияют на продажи.

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

Билды под линукс не очень стабильные, поэтому распространяются через форум.
https://forum.unity3d.com/threads/unity-on-linux-r...

Это баг юнити, они поменяли процесс проверки лицензии, и после апгрейда до 2017 не у всех корректно обновляются файлы движка. Кому-то помогает перелогинивание в юнитёвый аккаунт, кому-то нет. Ещё можете попробовать удалить файлы как описано здесь. У меня после пары переустановок пропало.

GUI.Button это старый и медленный способ, никто им не пользуется, вам нужен Canvas, можете начать с официального туториала. Для "если нажали на спрайт" существует специальный компонент Button.

Вы неправильно понимаете суть классов и компонентов, внимательно почитайте документацию. GameObject это не компонент, с помощью каста в другой класс нельзя магическим образом достать из него компонент, для этого существует специальный метод GameObject.GetComponent. Кроме того, в вашем случае конструкцию с FindGameObjectWithTag можно заменить вызовом Camera.main, результат будет такой же. Это не очень хорошая практика в контексте камер, но это уж вам решать. Что касаемо второй ошибки, она случается из-за того, что в вашем старте в первой строчке вызывается исключение, что обрывает поток метода, и все последующие строчки не вызываются, поэтому camera2 остаётся null.

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

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