Denis Gaydak

Можно лерпить кватернион для нахождения промежуточных точек. Насчёт оптимальности пути ничего не скажу, но выглядит корректно. Сначала находите локальные координаты объектов, потом нормализуете их и получаете направление. Создаёте вращение от одного направления к другому и ступеньками его применяете для расчёта точек. Рисовать проще всего с помощью LineRenderer.

using UnityEngine;

public class LineExample : MonoBehaviour
{
    public LineRenderer lineRenderer;
    public Transform a;
    public Transform b;
    public float sphereRadius = 0.5f;
    public int positionCount = 10;

    private void Awake()
    {
        Vector3 aDirection = transform.InverseTransformPoint(a.position).normalized;
        Vector3 bDirection = transform.InverseTransformPoint(b.position).normalized;

        var fromRotation = Quaternion.identity;
        var toRotation = Quaternion.FromToRotation(aDirection, bDirection);

        lineRenderer.positionCount = positionCount;
        for (int i = 0; i < positionCount; i++)
        {
            float t = i/(positionCount - 1f);
            Quaternion rotation = Quaternion.Lerp(fromRotation, toRotation, t);
            Vector3 point = rotation*aDirection*sphereRadius;
            lineRenderer.SetPosition(i, point);
        }
    }
}

Судя по всему юнити...
Сохраняйте при потере фокуса - OnApplicationFocus. Мало ли что потом произойдет - телефон может банально сесть - тогда вообще никаких колбеков не будет.

Потому что Collider2D наследуется от Object, у которого есть оператор конвертации в bool. Практически все юнитёвые сущности можно не сравнивать с null, а просто вставлять в условие, например, if(transform). Связано появление этого оператора с тем, что объекты живут не только в шарповом коде, но и в плюсовой части движка. То есть в шарпе объект может быть не null, а в плюсовой части уже уничтожился, и наоборот. Но это было актуально пару лет назад, с тех пор они бэкэнд переписывали и проблем с этим я уже давно не наблюдал, считайте, что это просто остатки легаси кода. Ещё иногда про это спрашивают на собеседованиях, но это скорее мусорные знания, дизайн так себе.

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

Про шейдеры есть хороший сайт The Book of Shaders, там немного другой стандарт чем в юнити, но всё переносимо с минимальными изменениями. В шейдерах основная сложность не математике, а в понимании функционального программирования и параллелизма, большинство вещей всё равно делается на простом сложении да умножении.

Если же всё-таки хотите подтянуть математику, то найдите где-нибудь "сборник задач по математике для поступающих в вузы", есть много книг с похожим названием. Интегралы можете сразу пропускать, а вот синусы и косинусы можете порешать. Ещё можете поиграть с Wolfram Alpha и интерактивными рисовалками графиков. Этого должно быть более чем достаточно, в геймдеве дело редко заходит дальше сложения векторов.

Можно и за месяц.

Из навыков JS (но как я понял для юнити лучше C#).

Юнити ТОЛЬКо c#. JS там никогда небыло - был UnityScript, который типо по синтаксису похож. Но его уже депрекейтнули.

Правильный путь - накачать ассетов из ассетстора и лепить из готового говна свое говно.
А вообще - начать с диздока. И диздок - это не 10 страниц.

Настраивается же в сторах, а не в юнити.

Создаёте кватернион с нужным вращением с помощью Quaternion.Euler или Quaternion.AngleAxis и умножаете на нормаль, на выходе получите повёрнутый вектор.

Картинками делайте, например.

да, подойдёт

transform с маленькой буквы сделайте

Существует такая должность - геймдизайнер. Который сложность уровней просчитывает таблично и заносить в баланс игры - тобишь в конфигурационные файлы. Никаких примеров тут быть не может - ни юнити ни пюгейм тут ни при чем - дело просто в конфигах.
Гуглите "геймдизайн кривая сложности".

Компаний много. Проектов много. Руководителей много.

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

И если вам на тостере все скажут "да не нужно никому ВО", а руководитель проекта скажет "нет ВО - досвидания", вы его скриншотами с тостера не переубедите.

Идите к ним напрямую и спрашивайте при трудоустройстве.

Штатная возможность в драйвере принтера Windows.
Называется "Печать в файл".

Правильный способ - отсортировать рандомно массив и потом брать элементы по-очереди с первого. Гуглите по ключевому слову Shuffle.

array.Shuffle();

foreach (var randomItem in array) {
    Console.WriteLine( randomItem );
}

Связь между скриптами работает замечательно, вы не понимаете разницу между ссылочными и знаковыми типами. MoveItems.coin имеет тип int, который не является ссылочным типом, а это значит, что в старте вы копируете текущее значение из MoveItems в CoinUi, и это значение потом просто лежит в переменной и не меняется. Если вы хотите получить текущее значение, то вы можете, например, сохранить ссылку на MoveItems и обращаться к coin через неё. Но, вообще говоря, превращать число в строку в Update это не очень хорошая идея, поскольку ToString выделяет память при конверсии, и со временем вы можете либо загадить всю память и уронить приложение, либо нарваться на фризы во время работы сборщика мусора. Лучше использовать события или что-нибудь ещё.

Создаёте камеру, создаёте текстуру, суёте текстуру в камеру. После этого камера будет рендерить в пропорциях и разрешении тектуры. Далее переводите канвас в режим "Screen Space - Camera", суёте в него камеру, и он будет в пропорциях камеры.

С .NET - никак. Там Mono.
С c# - все сложнее. Вы описываете логику программы на языке C# с использованием библиотек Mono (System) и библиотек Unity (UnityEngine). Далее это все дело компилируется в IL. А дальше - в зависимости от платформы. Может и выполнится сразу (интерпретатор встроен в Unity, скорее всего на основе Mono), а может дальше транслироваться в cpp и компилироваться уже как плюсовый код.

Это не просто не сложный вопрос, это из раздела getting started in 15 minutes.
Переместите родителя со сцены в ассеты и прочитайте документацию.

Должно быть:
1. Ссылка на префаб GameObject enemyPrefab
2. Любого Enemy мы создаём из префаба, даже первого. Enemy enemy = Instantiate(enemyPrefab)

Цель проекта - впервые сделать архитектуру по-человечески

Что такое архитектура "по человечески"?
Практически каждый программист сталкивался с тем, что глядя на свой код 6-12 месячной давности хочется все переписать с нуля.
А через год происходит тоже самое с новым кодом.

Хотелось бы сделать все максимально СОЛИДно, но я, видимо, не понимаю сути.

Суть и не понять, пока не наступишь на грабли.

Если у вас это домашний проект - я бы предложил плюнуть на все правила хорошего кода, и писать как захочется - без комментариев, без MVC, без SOLID принципов и т.д. Затем, наступая на грабли своего говнокода вы:
1. Поймете, почему надо делать так, а не иначе
2. Перепишите свой код более правильно

Самое главное что вы в таком подходе получите - кучу опыта. И реальное понимание почему нужно делать так, а не иначе.