Мимокрокодил

Поиграйтесь с настройками Size over Lifetime и Color over Lifetime.

Тут есть несколько моментов.
1) Так как вы создаёте, а не открываете, у вас идёт генерация файлов - это всегда процесс не быстрый, но зато последующие запуски будут шустрее.
2) Во время создания проекта генерируется большое количество файлов (для 2д вашей версии примерно ~13 тыс), что неплохо грузит жёсткий диск. Долгий процесс также может свидительствовать о возможных проблемах с ним.
3) Unity 2021 и моложе сами по себе немного глючные, в сравнении, например, с теми же 2019/2020.

Рекомендую вместо Translate использовать Vetor3.MoveTowards. Таким образом перемещение станет более контроллируемым и вы сможете использовать поворот LookAt.

"Camera.main" находит первую камеру на сцене, подписанную стандартным тегом "MainCamera". Убедитесь в том, что на нужной камере он есть.

В Unity вы можете начать работать вообще без знания кода в принципе. Вам в любом случае придётся потратить время, чтобы понять что в Unity что делает. Поэтому советую изучать Unity и C# параллельно. Знания второго раздела достаточно для старта в юнити по скриптам. Остальное вы можете осваивать уже по ходу разработки первых простых игр вроде 2д платформеров и раннеров.

Поворачивайте вокруг оси Y сам объект с CharacterController. Это можно сделать через Transform объекта.

Простой способ:
1) Создаёте класс Enemy и в нём реализовываете возможность получить урон;
2) Создаёте производные классы и накладываете их на соответствующие объекты;
3) В скрипте попадания используете TryGetComponent.
4) Profit

Пример:

using UnityEngine;

public class Projectile : MonoBehaviour {

	private void OnCollisionEnter(Collision c) {
		if (c.gameObject.TryGetComponent(out Enemy e)) {
			// damage enemy
		}
		// destroy bullet or return to object pool
	}
}

Если простым языком, опция Render Mode используется следующим образом:
1) Overlay - стандартный вариант, когда у вас одна камера на все задачи;
2) Camera - показать специфический интерфейс для определённой камеры;
3) World - вообще отвязать от камер, сделав объектом сцены.

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

Далее размер зоны Canvas-а на сцене. В режиме Overlay он огромен неспроста - он имеет размер экрана. Например, если эран 2960:1440, то и канвас будет иметь такой размер, почти 3к в ширину и 1.5к в высоту. Но на камеру он будет накладываться так, чтобы вложиться в её границы. Единственное неудобство в том, что чисто визуально сложно представить, как это дело будет выглядеть в игре. Чтобы каждый раз не прыгать в плеймод, можно просто вкладку Game расположить где-нибудь рядом. Ну или делать как мои знакомые. Заметил среди знакомых тренд, что они в простых гиперказуалках просто ставят режим Render Mode - Camera и сразу так работают. Сценический размер и положение канваса подстраиваются под камеру и им удобно.

Касательно масштабирования, обычно разработчики выбирают эталонное разрешение экрана, которое указывают в Canvas Scaler (рядом с Canvas на одном объекте). Там опция - UI Scale Mode, режим Scale With Screen Size. А ползунком ниже указывают как именно интерфейс будет зависеть от ширины и высоты. Затем нужно перейти во вкладку Game и там слева вверху есть выпадающий список с размерами экрана. Нужно выбрать или создать и выбрать то же самое разрешение.

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

Открываем, согласно подсказке жмём Shift+Alt и нажимаем на левый верхний квадрат:

Осталось только в самой компоненте задать такие Pos X / Pos Y, чтобы вам нравились отступы от левого и верхнего краёв экрана.

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

Осталось лишь придумать как привязать этот интерфейс к игроку на уровне скрипта. Много кто использует для этого синглтон, кто-то при спавне игрока просто ищет специфический скрипт на сцене и сохраняет на него ссылку. Это реально неплохие варианты.

Так как ваша сетка не движется, то единственное, чем она ваш комп грузит - это добавляет свои данные в Draw call Batching. А учитывая специфику этого процесса, выгоднее сделать меньше больших, чем больше маленьких. Но речь идёт о каких-то безумных числах, вроде 10 тыс клеток при условии, что они будут ВСЕ у вас на экране в границах активной камеры. Но даже так, пока изменение тайлмапа (большими порциями за раз) не происходит в рантайме вы не словите каких-то ощутимых лагов.
Если же говорить про оптимизацию процесса, то выгоднее сделать более мелкую сетку по одной простой причине - вы можете рисовать как одной клеткой за раз, так и их энным количеством (как буд-то вы рисуете более большой сеткой), а вот уменьшить исходно большую если и возможно, то я хз как.

У меня нет внешней камеры чтобы проверить, поэтому тут хз.

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

Чтобы решение было изящным, можно создать два скрипта. Отключение:

#!/bin/bash
sudo kextunload /System/Library/Extensions/AppleCameraInterface.driver/Contents/MacOS/AppleCameraInterface

Включение:

#!/bin/bash
sudo kextload /System/Library/Extensions/AppleCameraInterface.driver

Затем через Automator создать два действия:
1) /путь_к_файлу/unload_camera_driver.sh
2) /путь_к_файлу/load_camera_driver.sh
Как-нибудь их назвать и сохранить, например, на рабочем столе.

Пока вы только начинаете свой путь, не забивайте себе голову такими вещами как "актуально" или не "актуально". Основы и принципы, которые вы познаете во время освоения чего-либо в разработке пригодится вам дальше вне зависимости от того, что вы изучали.

Вероятно, вы говорите о видео с канала Сакутина. Это не самый лучший способ начать изучение, так как автор всё же делает контент больше для тех, кто понимает основные принципы программирования и процесс разработки проекта на юнити.
Начать можно с чего-то менее хардкорного, например https://www.youtube.com/@graphicaldesign2776/ и/или https://www.youtube.com/c/emeraldpowder.

Ошибка в использовании пустой ссылки:

// вместо
public static List<Vector2> colliderPositions;

// напишите
public static List<Vector2> colliderPositions = new List<Vector2>();

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

if (hitInfo.collider == null) {
	// то же как в блоке else
} else if (hitInfo.collider.CompareTag("Mirror")) {
// ... ну и так далее

Есть несколько рекомендаций:
1. Используйте асинхронный код. Что-то типа такого:

public static async void SetXMLValue(string pathToXMLFile, string nodeName1, string nodeName2, string nodeName2Value) {  
    TextAsset textAsset = Resources.Load<TextAsset>(pathToXMLFile);
    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.LoadXml(textAsset.text);
    XmlNode node = xmlDoc.SelectSingleNode("/" + nodeName1 + "/" + nodeName2);
    node.InnerText = nodeName2Value;
    await File.WriteAllTextAsync(Application.dataPath + "/Resources/" + pathToXMLFile + ".xml", xmlDoc.OuterXml);
}

2. Используйте более быстрые методы чтения и записи XML. Вместо стандартных методов XmlDocument.LoadXml() и XmlDocument.OuterXml вы можете использовать XmlReader и XmlWriter. XmlReader позволяет читать XML файлы по мере их поступления и не хранить их в памяти целиком, что позволяет сократить время чтения. XmlWriter позволяет записывать XML файлы по мере их создания, что позволяет сократить время записи.
3. Используйте кэширование данных в памяти. Вместо того, чтобы каждый раз читать настройки из XML файла, вы можете загрузить их в память при запуске программы и хранить в памяти. При изменении настроек вы можете обновить их как в памяти, так и в XML файле. Это позволит избежать чтения XML файла каждый раз при обращении к настройкам.
4. Используйте более быстрый способ доступа к файлам. Вместо использования метода File.WriteAllText() вы можете использовать методы доступа к файлам, которые более быстры и оптимальны для Unity, например, System.IO.MemoryMappedFiles.
5. Если вам и правда так припекло использовать XML, вы можете немного ускорить процесс, оптимизировав его структуру. Например, выделить для каждой локали по отдельному файлу. Но лично я вам советую познакомиться с форматом JSON, тем более в юнити есть хороший нативный инструмент JsonUtility, а в шарпе newtonsoft.json.

Но если ваша цель не решить интересную задачу, а просто иметь под рукой хороший инструмент, советую вам не мучать себя, а просто воспользоваться пакетом Unity.Localization. Ну или если у вас есть лишних $45, то пакетом i2 в ассет сторе.