Частные реализации архитектуры игр: примеры, советы, опыт

Здравствуйте уважаемы разработчики! На пути GameDev'a постоянно сталкиваюсь с диллемами "На сколько универсальным должно быть игровое ядро", "Какую архитектуру выбрать", "Какими правилами руководствоваться (паттерны, гайдлайны, принципы и т.д.)"

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

И вот как раз на этом начальном этапе можно сильно упростить свою жизнь в ближайшем и не только будущем, если руководствоваться рядом правил.

Главное

Как начинающий разработчик для себя я выделил следующие пункты:

1. КОП (Компонентно Ориентированное Программирование). Проектировать компоненты стоит ещё до написания кода.
2. SOLID собственной персоной, что так сильно запал в душу. Особенно важен с пунктом первым, так как его принципы сильно уменьшают связность.
3. 1 слой абстракций. По моему скромному опыту, если в разработке требуется больше, чем 1 слоёв абстракций, то такой код уже излишне пытается быть универсальным, делая проект сложным ещё до этапа реализации.

Архитектура моих игр как правило представлена следующим образом (не вся, но главная по моему мнению):

- Prefabs <------- модели, спрайты, палетты, тайлсеты, материалы, анимации и т.д. (не касается кода и не имеет своего поведения)
    - Units <----- Enemies, если есть враги. Players, если есть моделька игрока. И т.д.
    - Environment
        - Locations
        - Others
    - Effects
    - Projectiles
- Scripts <------ только описание поведения и его реализации
    - Util <------ абстракции
        - ActionExecutor.cs <------ тот, кто выполняет действие при условиях (childs can be: Attacker, Healer, AbilityCaster, etc.)
        - Damagable.cs
        - Effectable.cs
        - Movable.cs
        - Triggerable.cs
        - TickableEffect.cs <----- общий предок всех эффектов
        - Ability.cs <----- общий предок всех способностей, по совместительству ядро способностей.
    - Environment <------- конкретные реализации статичных объектов
    - Effects <------- конкретные реализации эффектов
    - Abilities <------- конкретные реализации способностей
    - Game <------- ScriptableObject. Сюда отдельно идут инвентари, счётчики, загрузчики и т.д.
    - GUI <------- ScriptableObject. Сюда отдельно идут менюшки для всего (инвентарь, статистика, настройки и т.д.)
    - Units <----- Enemies, если есть враги. Players, если есть объект игрока. И т.д.

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

P.S. Спрашивайте примеры кода, если нужен, за вопросом слежу.

Правка 1: Собственно ничего не сказал по используемым паттернам, но, надеюсь, что у каждого найдётся что посоветывать.

Правка 2: В связи с некорректной формулировкой вопроса я вынужден задать более конкретный, отвечающий требованиям сайта:
Какие принципы разработки утвердились в GameDev, чтобы при возрастании сложности проекта время, затрачиваемое на улучшения\дополнения\модификации возрастало с наименьшей силой? Если единой версии нет, то:
Какие best practice используются при разработке игры на движке Unity, если таковые уже утвердились в сообществе GameDev'a?