dollar

В Update() смотреть системное время, зная момент отсчёта.

Желательно все события (если их больше одного) повесить на проверку системного времени в единственном месте.

Можно, но зачем?

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

Хотя, если это что-то очень очень простое типа визуальной новеллы, то вполне вариант, почему бы и нет.

Для начала нужно определиться с целью игры.

Зачем вы делаете игру?

Если для того, чтобы потренироваться или просто пощупать геймдев, то, возможно, цель УЖЕ достигнута. Если же для того, чтобы игра принесла денег, то с изложенным вами бекграундом вам до этой цели, как до луны. В приносящей деньги мобильной игре программирования дай бог 20%.

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

1. Сделать так, чтобы игра запускалась и работала в Unity.
   
2. Опубликовать готовую игру в сторе (Google Play пока для вас проще будет).
   

Из вопроса не ясно, на каком этапе у вас затык. Начните с первого этапа. Пустой экран должен у вас запускаться из коробки. То есть нужно просто запустить пустой проект. Дальше нужно разбираться с тем, как работает Unity - что может интерфейс, что предоставляет API и т.д. Тупо копировать чужой код не нужно. Копировать можно только с понимаем, что делает каждая строчка и каждый символ этого кода. То есть чужой код можно рассматривать, как пример. А дальше на его основе делать свой код. И даже если вы вставляете чужой код в свою игру без изменений, вы должны понимать, как он работает, чтобы он заработал именно у вас и не поломал игру, и сам не поломался при интеграции в игру.

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

По-хорошему нужно даже событие не смены текстуры, а более осмысленное в соответствии с логикой игры. Например, если у объекта есть несколько состояний, то хорошо бы иметь переменную (свойство) с этим состоянием и соответствующее событие на смену состояния. Текстуры тогда будут вообще ни при чем.

Не совсем понятно, какую цель вы преследуете. Исходя из вашего слова "профитнее" (т.е. по-русски "выгоднее") её можно трактовать по-разному.

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

2) Если вы рассматриваете свои игры, как дополнительные пункты в резюме программиста, то по сути и не важно, игры это или что-то другое. Здесь будет играть роль ваш опыт программирования (опять же просто количество лет), плюс опыт работы в команде. Чуть бОльшую роль имеют софт скилы при составлении резюме и прохождении собеседования. В остальном идеи из предыдущего пункта тоже применимы - то есть количество достойных проектов, считающихся достижениями, которые не стыдно показать.

3) Если выгода для вас означает собственно продажа своих игр, то эта цель сильно пересекается и первым пунктом, с той лишь разницей, что вы максимизируете прибыль (причем, для себя). Аналогично первому пункту, это сложная тема, и нужно уметь во многое, что одиночке не под силу. А если вы хотите свою команду (а не вхождение в чужую), то также нужен солидный бюджет. Программирования здесь будет еще меньше, точнее лично у вас на это просто не будет времени. Но этому пункту противоречат ваши слова "для саморазвития и дропа на гитхаб", что как бы намекает, что деньги непосредственно с игр вам не нужны.

4) Наконец, если вы хотите заниматься буквально саморазвитием, то есть повышать качество кода и снижать количество багов в нем, то нужно заморочиться конкретно на этом. Опять же, игры здесь ни при чем. Нужно наводить порядок в голове, приучать себя к хорошему оформлению кода и т.д. Опыт, конечно, тоже идет в плюс, но тупо опыта не достаточно. А точных рецептов здесь нет. Начать можно даже с гугления наивной фразы "как писать код без ошибок", а дальше как пойдет, это долгий путь. Но сразу скажу, что это имеет мало отношения к коммерческой выгоде. То есть даже если вы участвуете в ААА-проекте, где отсутствие багов критично, никто не пустит ваш код в продакшн сразу после написания. Ошибаются все, даже профи.

P.S. На уровне джуна можно быть только помощником. То есть хорошо зная лишь теорию, получать замечания от более опытных товарищей, которые отвечают за успех. Хотя деление это довольно условно. Пет-проекты могут как способствовать росту, так и просто отнимать время, смотря что и как качать.

Привет, товарищ!
Хотел сказать, что мне ник твой не понравился. Стремный какой-то.
Всё остальное на высоте. Реально, классный вопрос задал.
Я подписался на тебя.

Код:

isGrounded = Physics2D.OverlapCircle(groundCheck.position, checkRadius, whatIsGround);

Не работает, потому что сразу же после этого вызывается функция CheckGround(), в которой переменная isGrounded снова перезаписывается:

Collider2D[] colliders = Physics2D.OverlapCircleAll(transform.position, 0.6F);
isGrounded = colliders.Length > 1;

Поэтому первую строчку вообще не будем рассматривать, эта пустышка, которая ничего не делает, только процессор нагружает лишний раз. Разберем, что же происходит в последних строках.
Вы считаете количество коллайдеров в круговой области. И если оно больше 1, то isGrounded будет true.
Видимо, около стены вы также считаете стену. Поэтому наличие стены делает isGrounded = true.
В чем здесь логика, вам виднее.
Исправляйте. :)

Поэкспериментируйте с функцией ScreenToWorldPoint().
Также есть ScreenPointToRay().
Далее, имея координату в 3D пространстве, можно уже легко считать поворот персонажа в сторону этой точки.

Учтите, что координаты - вещественные числа.

Возможно, у вас высота персонажа 0.00000000138456827364. То есть выше нуля. И если вы проверяете тупо сравнением (a > 0), то персонаж получается висит в воздухе. Нужно либо округлять, либо вносить поправку на погрешность, хотя бы до 4-5-го знака:
(a - 0.0001 > 0)

Затем, что этот движок помогает в разработке.
И разработка игры (и последующее ее развитие) не сводится к написанию кода.

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

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

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

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

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

Если вопрос про то, как боты будут ходить в произвольном графе, то это всевозможные алгоритмы поиска пути, из которых наиболее классическим (и основой для других) является A* (Astar).

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

Основные ресурсы это:

1. Официальная документация
   
2. learn.unity.com. Понимаю, что вы не любите видео, но за денежку можно получить чуть более индивидуальный подход.
   

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

Засунуть его в другую ветку?
Общий Родитель -> в нём Бар и Перс.
Координаты меняем общего родителя.
Флипаем перса.
Как-то так.