dollar

По Unity, помимо документации, основной обучающий ресурс - learn.unity.com
Для комфортного обучения есть платный вариант.

Сделайте хитбокс.
Надеюсь, очевидно, что это такое (википедия).

Как исправить проблему

Исправление проблем в плохо работающей программе (игре) называется отладка. Процесс отладки - это поиск, т.е. последовательность проверок и экспериментов, в ходе которой копится информация, которая в итоге помогает догадаться, где и какая ошибка допущена.

Основной метод - это метод исключений. Примерно как в игре "Данетки" (или "Ситуации"), только применительно к приложению ("да" - работает, "нет" - не работает). Очевидно, что нужно правильно подбирать "вопросы", тогда и ответ быстро найдётся. Например, можно попробовать выполнить функцию удаления пули саму по себе без условий. Если она выполнится, то она точно работает, и можно исключить её из дальнейшего анализа. Если она не выполнится, то проблема в ней, и следует углубиться в неё, исключая всё остальное (пока что). Таким образом, одним лишь экспериментом (вопросом) проблема делится пополам, а точнее уменьшается вдвое. И так далее. За 10 таких вопросов-проверок вы уменьшите проблему в 1000 раз, а может уже и полностью локализуете её к тому времени.

Знаю, что ответ слишком общий, но он вам и правда подходит. Как тот ни бесполезно и нравоучительно звучит, но мой совет - учитесь отлаживать.

На данный момент вы задали 0 вопросов, включая этот. Почему ноль? Вопрос-то вы вроде как задали, но результат не описали. Вы сказали, что вам надо (чтобы враг и пуля удалялись), но не сказали, что на данный момент есть. Враг удаляется, а пуля - нет? Пуля удаляется, а враг - нет? Игра вообще не запускается из-за попытки сделать эту фичу? Пуля проходит насквозь? Пуля отскакивает, как от бетона, и падает на пол? Любая из этих подсказок была бы первым шагом и помогла бы уменьшить проблему в 2 или даже в 10 раз. Но вы эту подсказку не дали, так что проблема может заключаться, в чем угодно. В этом случае вам можно помочь либо телепатией (угадыванием), либо сделав вашу задачу с нуля, не беря в расчет ваши наработки.

Но даже если будет 1 подсказка, этого будет не достаточно. Как я сказал выше, нужно несколько подсказок. И где искать следующую, зависит от того, где вы нашли предыдущую. Так что вы и только вы можете этим заниматься. Через Тостер это будет в формате "попробуй так - сделал, вышло то-то - тогда проверь это - ок, выдало такое - значит, здесь исправь" и т.д.

Код в данном случае не очень помогает, и я уже сказал почему. Потому что проблема (которая не описана) может быть, где угодно, даже вне этого кода.

UPD:

Non-invocable member 'GameObject' cannot be used like a method.

Спасибо за добавление описания ошибок в текст вопроса. Теперь гораздо понятнее, что происходит (это аж 4 подсказки), но ответить однозначно всё равно нельзя. Потому что они вроде как очевидны, их описание говорит само за себя, но, тем не менее, вопрос всё ещё актуален. Это говорит о недостатке знаний в C# или в английском языке. Пройдусь кратко:

1. Trigger вы используете, но нигде не объявили. И компилятор жалуется, что не знает, что это такое. Возможно, вы хотите что-то проверить и вам по смыслу понятно, что это должно быть (какой-то "триггер"), но компилятор не знает английского, для него это лишь идентификатор какой-то сущности - переменной ли, функции ли, и так далее. Кроме того, даже человеческий программист зайдёт здесь в тупик, потому что не ясно, к чему относится ваше Trigger("Ammo"), равно как и Collision("Enemy"). Если у вас в игре много врагов и пуль, то что эта строчка может значить? Коллизию всех со всеми? Или что? Когда (если) вы глубже поймете язык C# и вообще ООП, то узнаете, что есть классы, объекты и их методы. И что методы обычно вызываются не сами по себе, а применительно к какому-то объекту, да хотя бы к текущему (но в текущему такого метода нет). Объяснять "в целом" можно долго, но я не смогу в ответ запихнуть учебник по C#.
   
2. Collision - здесь компилятор сообщает, что этот идентификатор ему знаком, но вы его используете не так, как задумано.
   
3. GameObject - аналогично предыдущему, это знакомо компилятору, но так нельзя, это не функция.
   
4. GameObjcet - а здесь компилятор говорит, как и в первом сообщении, что вы нигде не объявили этот идентификатор. Очевидно, что там просто опечатка. Это как раз тот пример, когда, занимаясь отладкой, вы должны догадаться об этом. Ведь, GameObject это вот прям основное слово в Unity, но компилятор его не знает? Что? Как так? И если исключить невозможное, то остается почти единственный вариант - опечатка. Вот так просто.
   

Полагается по стандарту.
Хотите нарушать - ваше право, не возбраняется.

Это геттеры и сеттеры. То есть функции доступа к свойству.

Зачем? Попробую объяснить простым языком. Большие программы сложно полностью загрузить в мозг отдельного человека и представлять всю структуру целиком со всеми нюансами одновременно. Поэтому принято делить программу на части. Вынос кода в отдельную функцию - один из простых способов. В ООП к этой проблеме подходят более основательно. Класс как явление - тому пример.

Класс делит программу как минимум на 2 части - то, что внутри класса, и то, что снаружи класса. Считается как бы, что класс пишет один человек, а пользуется им другой человек. Но это может быть и один единственный человек, всё равно так проще, потому что человек сначала пишет класс, тщательно всё там кодит и тестирует, а потом напрочь ЗАБЫВАЕТ, как он устроен внутри, потому что он уже готов и им можно пользоваться. То есть человек выгружает из своей ненадежной человеческой памяти эту инфу и переходит к следующей задаче, в которой просто использует этот класс. Всё, что ему нужно помнить, это то, как пользоваться классом, а всю подноготную можно забыть до тех пор, пока не понадобится улучшить класс. И здесь снова получается удобно. Когда будем улучшать класс (это не обязательно тот же самый человек), можно не думать о том, как его используют. Главное, чтобы способ взаимодействия с классом не изменился (не сильно изменился).

В вашем примере - это просто заготовка. Дальше нужно наполнять эту заготовку функционалом. В самом простом виде геттер просто возвращает приватное свойство, а сеттер меняет его. Так нужно сделать сразу, чтобы потом не пришлось переписывать всю программу (и согласовывать с коллегами). Но даже здесь уже есть небольшое правило - нельзя передавать отрицательные значения. Условия могут быть сложнее. И вообще всё может быть сложнее. Например, вместо age можно хранить дату рождения. И функция GetAge будет каждый раз высчитывать разницу с текущей датой. По сути для внешнего использования ничего не меняется, но внутри происходит магия.

Много слышу, что за функциональным программированием будущее

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