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

Сначала нужно определиться - кнопки именно что не работают или просто не нажимаются.
На ум приходит 5 сценариев:
1) Что-то мешает.
Иерархия интерфейса устроена таким образом, что чем выше в иерархии объект, тем раньше он рисуется. Возможно ниже по иерархии есть иной графический элемент (даже если он в этом месте прозрачен, главное чтобы был включен), который перехватывает нажатие на себя. Нужно либо поменять иерархию, либо отключить галочку Raycast Target на всех объектах, которые мешают нажатию (ну или просто подвигать)
2) Кнопка в принципе выключена.
Проверьте, включено ли свойство Interactable кнопки
3) Возможно сама кнопка не слушает нажатия.
Проверьте на всякий случай, рядом с кнопкой на том же объекте должен лежать текст или картинка и там галочка Raycast Target должна быть включена.
4) На сцене нет Event System
Эта штука находится в меню создания UI / Event System
5) Сам канвас не слушает нажатия - проверьте чтобы на канвасе был включенный компонент "Graphic Raycaster"

Но может быть и так, что событие у самой кнопки просто не настроено (On Click)

Поиграйтесь с настройками 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")) {
// ... ну и так далее