От дизайна к архитектуре реализации
Суть дизайна
Игровые механики - это некие правила игры, которые часто выражаются в том или ином поведении игровых объектов.
Игровая Механика = Игровые Правила + Поведение Игровых Объектов
Игровые объекты в Unity - это вообще что угодно, что лежит в сцене, даже если это ничего не делает и никак не выглядит.
Игровой Объект - контейнер, существующий в Игровом Пространстве.
А нас интересует именно агентная сущность, которая собой выражает игровую механику - переносчик взаимодействия, как в физике, емое, поэтому она не только что-то делает, т.е. имеет игровое поведение, но и как-то выглядит - имеет эстетику, поэтому так и назовем - Игровая Сущность.
Игровая Сущность = Игровой Объект + Игровое Поведение + Эстетика.
Игровое поведение в Unity задается с помощью компонентов на игровых объектах. Так мы получаем переносчика игровой механики.
Игровое поведение - Игровой Объект с компонентом, задающим его поведение и выражающим игровую механику.
Под эстетикой я подразумеваю все, что не является непосредственно частью игровой механики, но помогает в восприятии ее работы: анимации, визуальные эффекты, звуковые эффекты, спрайты, меши, текстуры. Но чтобы хоть что-то из этого дошло до игрока, оно должно быть в сцене в Unity, а значит, принадлежать тому или иному Игровому Объекту.
Эстетика - Игровой Объект, имеющий визуальный или звуковой элемент.
Подводя итог: игровая механика выражается в игровых правилах и их переносчиках - игровых сущностях, которые состоят из игровых объектов с игровым поведением и эстетиками.
Игровая Механика = Игровые Правила + (Игровые Объекты + Игровое Поведение + Эстетики)
Вот на основании этого и будет строить архитектуру игровых проектов. Но…
Дизайн и реализация отличаются друг от друга
Дизайн игры состоит из игровых объектов, игровых механик, элементов эстетики, интерфейса - пользовательского ввода и системного вывода. Этих сущностей не хватает, чтобы реализовать механику.
Чего-то не хватает, мостика между дизайном и реализацией, информации, которой в дизайне нет, но она необходима при реализации.
Опыт показывает, что часто необходима дополнительная сущность, которая находится как бы снаружи и контролирует некоторые процессы - контроллер. Контроллер не относится к игровым механикам, но обеспечивает их связь с игровой сценой и жизненным циклом движка.
Игровой движок - сам по себе является фреймворком для разработки игры
Прежде чем изучать архитектурные паттерны, необходимо убедиться в их необходимости. Может быть игровой движок уже сам по себе является достаточной архитектурной основой для удобного создания игры? Ведь он для этого и создан! Попробовать не придумывать фреймворк на фреймворке, а добавить в движок то, что необходимо - кастомную логику игровых механик.
Игровые объекты - есть в движке! Компоненты являются удобным механизмом присваивания любых необходимых элементов поведения игровых объектов.
Игровые Механики - за редким исключением не представлены в базе движка, потому что они почти всегда уникальны для данной игры, поэтому они создаются в виде собственных классов. Игровые механики выражены в глобальных правилах и ситуативном поведении игровых сущностей.
Игровые сущности - объекты, которые представлены в игровой сцене, обладают функциональной частью, которая выражает некую игровую механику, и эстетической. Поэтому игровые сущности состоят из трех игровых объектов: контейнер, функциональная часть, эстетическая часть.
Эстетика - игровые объекты, задающие визуал: модели, спрайты, визуальные и звуковые эффекты, анимации. Могут существовать сами по себе и в составе игровых сущностей.
UI - интерфейс в широком понимании, пользовательский ввод и системный вывод. Ловит пользовательский ввод, передает его имплементатору, слушает глобальные (?) игровые механики.
Имплементатор - связывает игровую механику с игровыми сущностями и с интерфейсом, является тем недостающим элементом, который служит мостиком между дизайном и реализацией.