Архитектура приложения(игры) на Unity

Почитав коменты.... вообще я не согласен с мнением что в случае с юнити поможет "чистый код". У юнити есть свои особенности и они буквально заставляют программиста писать неправильно или строить проект неправильно. Читал я чистый код и юнити меня все равно заставлял во многих местах писать неправильно и учится на собственных ошибках.

Уверен, что лучше читать конкретную литературу которая будет рассказывать конкретно про юнити. Тем более, что НЕВОЗМОЖНО написать код который бы не противоречил каким-то паттернам. Даже читая "чистый код" можно увидеть множество правил которые противоречат одно второму в рамках одной книги (что, к слову, автор так же выделял!). Нету универсального правильного подхода - всегда будут компромисы при написании кода.

Из того что сходу вспомню по вопросу(не совсем про архитектуру, скорее в целом советы), так это:

• Не использовать старый GUI, а лишь новый юай на канвасе
• Не использовать захардкодженные кнопки управления, для этого есть Input manager или как-то так
• По мере необходимости использовать DontDestroyOnLoad - например когда нужно всегда держать в памяти теперешние настройки при переходе между уровнями. Все что нужно тебе на разных сценах не должно выгружаться из памяти что бы потом заново загружаться.
• используй асинхронную загрузку сцен
• минимально использовать поля инспектора в которые ты привязываешь обьект на сцене или префаб. Лучше если ты их будешь искать в скрипте в Start/Awake на сцене или же в самом проэкте искать префаб кодом. Будут постоянно отвалитваться если проэкт чуть больше однодневки и будешь тратить много времени впустую.
• Использовать движения на основе физики - обойдешь много багов. Переходи на нефизическое движение исключительно в крайних случаях.
• Ищи скрипты-компоненты всегда в Start/Awake. Если ты делаешь GetComponent<> в другом месте - практически наверняка ты делаешь что-то не так и это приведет к тормозам
• Если тебе нужно менеджить обьекты - лучше сохраняй ссылку на них в каком-то скрипте менеджере. Достать обьект из этого менеджера быстрее чем заново искать этот же обьект по сцене в большинстве случаев.
• никогда не применяй Try Catch - тормоза на пустом месте. Заменяй на if else
• Используй атрибуты к параметрам (вроде [Range(1, 6)] ) - они облегчают жизнь. Но помни об особенности юнити - применяя атрибут ты можешь словить неожиданное поведение. Например изменив дефолтное значение в коде, оно не поменяется в инспекторе.
• Если один компонет требует наличие другого - обязательно используй атрибут required component
• Чем меньше связность между обьектами - тем лучше.