Структура проекта

Привет, ‎коллеги.‏ ‎Пора ‎переходить ‎от ‎описания ‎девлога‏ ‎к ‎описанию‏ ‎проекта.‏ ‎В ‎этой ‎статье‏ ‎я ‎расскажу‏ ‎про ‎структуру ‎проекта:

Порядок ‎файлов‏ ‎и‏ ‎папок, ‎почему‏ ‎именно ‎так,‏ ‎какие ‎еще ‎варианты ‎бывают
Общая ‎архитектура‏ ‎кода
Советы‏ ‎по ‎организации‏ ‎кода ‎в‏ ‎проектах
Порядок ‎инициализации

Файловый ‎порядок

В ‎целом ‎мы‏ ‎на‏ ‎работе‏ ‎использовали ‎два‏ ‎подхода ‎по‏ ‎организации ‎файлов‏ ‎в‏ ‎проекте: ‎сортировать‏ ‎в ‎папки ‎по ‎типу ‎файлов‏ ‎или ‎по‏ ‎смысловой‏ ‎общности ‎(аля ‎ассет‏ ‎или ‎игровая‏ ‎механика). ‎Все ‎скрипты ‎лежат‏ ‎в‏ ‎одной ‎папе,‏ ‎а ‎все‏ ‎текстуры ‎в ‎другой? ‎Это ‎сортировка‏ ‎по‏ ‎типу ‎файлов.‏ ‎Если ‎же‏ ‎все ‎текстуры, ‎материалы, ‎анимации ‎и‏ ‎скрипты‏ ‎относятся‏ ‎к ‎одной‏ ‎игровой ‎механике‏ ‎и ‎лежат‏ ‎в‏ ‎папке ‎с‏ ‎игровой ‎механикой, ‎то ‎это ‎второй‏ ‎тип ‎порядка‏ ‎в‏ ‎проекте.

Долгое ‎время ‎мы‏ ‎придерживались ‎первого‏ ‎варианта, ‎но ‎на ‎практике‏ ‎рано‏ ‎или ‎поздно‏ ‎приходишь ‎к‏ ‎следующим ‎выводам:

В ‎процессе ‎разработки ‎ты‏ ‎работаешь‏ ‎не ‎с‏ ‎файлами ‎как‏ ‎таковыми, ‎а ‎с ‎игровой ‎механикой‏ ‎(с‏ ‎файлами,‏ ‎которые ‎к‏ ‎ней ‎относятся).‏ ‎Жутко ‎неудобно‏ ‎искать‏ ‎скрипт ‎в‏ ‎одной ‎папке, ‎править ‎шейдер ‎в‏ ‎другой ‎папке,‏ ‎далеко‏ ‎от ‎первой. ‎Ты‏ ‎вроде ‎работаешь‏ ‎над ‎одним ‎кирпичиком ‎проекта‏ ‎(над‏ ‎одной ‎игровой‏ ‎механикой), ‎а‏ ‎файлы ‎раскиданы ‎по ‎всему ‎проекту.‏ ‎Это‏ ‎жутко ‎неудобно.
Если‏ ‎ты ‎скачиваешь‏ ‎готовые ‎ассеты ‎с ‎Ассет ‎Стора,‏ ‎то‏ ‎они‏ ‎скачиваются ‎именно‏ ‎в ‎выше‏ ‎изложенном ‎виде‏ ‎–‏ ‎отдельная ‎папка‏ ‎игровой ‎механики, ‎внутри ‎которой ‎все,‏ ‎что ‎к‏ ‎ней‏ ‎относится: ‎скрипты, ‎текстуры,‏ ‎анимации, ‎звуки.
Так‏ ‎и ‎так ‎ты ‎используешь‏ ‎оба‏ ‎подхода, ‎но‏ ‎в ‎разных‏ ‎масштабах. ‎Глобально ‎папки ‎сформированы ‎по‏ ‎игровым‏ ‎механикам, ‎но‏ ‎внутри ‎этих‏ ‎папок ‎есть ‎папки ‎Scripts, ‎Sources,‏ ‎Prefabs.

Совет.‏ ‎С‏ ‎самого ‎начала‏ ‎и ‎до‏ ‎конца ‎работы‏ ‎на‏ ‎игрой ‎придерживайтесь‏ ‎какого-то ‎порядка ‎и ‎не ‎переставайте‏ ‎его ‎соблюдать.‏ ‎Несортированные‏ ‎файлы ‎и ‎непродуманная‏ ‎архитектура ‎накапливается‏ ‎и ‎с ‎каждым ‎разом‏ ‎и‏ ‎все ‎больше‏ ‎усложняет ‎процесс‏ ‎разработки. ‎Тебе ‎попросту ‎больше ‎не‏ ‎хочется‏ ‎в ‎этом‏ ‎всем ‎разбираться.‏ ‎Книга ‎Роберта ‎Мартина ‎«Чистый ‎код»,‏ ‎как‏ ‎мне‏ ‎показалось, ‎прежде‏ ‎всего ‎учит‏ ‎придерживаться ‎порядка.‏ ‎А‏ ‎какой ‎именно‏ ‎порядок, ‎это ‎уже ‎вам ‎решать.‏ ‎Придерживайтесь.

Структура ‎кода

Все‏ ‎Unity-проекты‏ ‎– ‎это ‎монолитное‏ ‎приложение. Внутри ‎же‏ ‎мы ‎можем ‎использовать ‎различные‏ ‎подходы,‏ ‎например, ‎MVC и‏ ‎его ‎разновидности‏ ‎или ‎ECS (в ‎Unity ‎встроен ‎DOTS).

Совет.‏ ‎Не‏ ‎забывайте ‎пользоваться‏ ‎пространствами ‎имен, очень‏ ‎помогает ‎организовать ‎работу ‎кода. ‎Еще‏ ‎вариант,‏ ‎к‏ ‎которому ‎я‏ ‎не ‎склонился‏ ‎– ‎это‏ ‎AssemblyDefinition. Как‏ ‎по ‎мне,‏ ‎подобный ‎способ ‎неудобен ‎из-за ‎чувствительной‏ ‎настройки. ‎А‏ ‎еще‏ ‎ты ‎можешь ‎долгое‏ ‎время ‎не‏ ‎понимать ‎почему ‎не ‎компилируется‏ ‎код,‏ ‎и ‎кто‏ ‎на ‎кого‏ ‎должен ‎ссылаться. ‎Звучит ‎как ‎отговорка,‏ ‎но‏ ‎я ‎не‏ ‎пришел ‎к‏ ‎этому ‎способу, ‎просто ‎использую ‎пространства‏ ‎имен.

В‏ ‎проекте‏ ‎есть ‎общее‏ ‎пространство ‎имен‏ ‎IndieBroGames, ‎внутри‏ ‎которого‏ ‎есть ‎остальные.‏ ‎Например, ‎IndieBroGames.Common ‎содержит ‎в ‎себе‏ ‎мою ‎накопленную‏ ‎базу‏ ‎скриптов, ‎база ‎формировалась‏ ‎в ‎процессе‏ ‎работы ‎над ‎другими ‎проектами,‏ ‎включает‏ ‎мои ‎наработки,‏ ‎измененные ‎версии‏ ‎других ‎скриптов ‎и ‎чужого ‎опыта.‏ ‎Это‏ ‎пространство ‎имен‏ ‎не ‎имеет‏ ‎зависимостей ‎от ‎конкретного ‎проекта ‎и‏ ‎используется‏ ‎в‏ ‎каждом ‎проекте‏ ‎в ‎одностороннем‏ ‎порядке.

А ‎есть‏ ‎пространство‏ ‎имен ‎IndieBroGames.Soulskiller,‏ ‎к ‎которому ‎относятся ‎скрипты ‎этой‏ ‎игры. ‎Это‏ ‎пространство‏ ‎имен ‎может ‎использовать‏ ‎скрипты ‎из‏ ‎IndieBroGames. ‎Common. ‎Здесь ‎формируется‏ ‎конкретная‏ ‎реализация ‎игровых‏ ‎механик, ‎относящихся‏ ‎только ‎к ‎этой ‎игре.

Под ‎IndieBroGames.Soulskiller‏ ‎лежат‏ ‎остальные ‎пространства‏ ‎имен, ‎которые‏ ‎отсортированы… ‎по ‎игровым ‎механикам, ‎как‏ ‎папки,‏ ‎в‏ ‎которых ‎и‏ ‎лежат ‎эти‏ ‎скрипты. ‎Например,‏ ‎поведение‏ ‎противников ‎основано‏ ‎на ‎машине ‎состояний ‎(об ‎этом‏ ‎поговорим ‎чуть‏ ‎позже),‏ ‎где ‎машина ‎состояний‏ ‎находится ‎в‏ ‎пространстве ‎имен ‎IndieBroGames.Common.StateMachineSystem, ‎а‏ ‎состояния‏ ‎противников ‎унаследованы‏ ‎от ‎абстрактного‏ ‎класса ‎State.

Порядок ‎инициализации

Начало ‎начал ‎в‏ ‎игре‏ ‎– ‎это‏ ‎первая ‎сцена‏ ‎для ‎инициализации ‎ядра ‎из ‎пространства‏ ‎имен‏ ‎IndieBroGames.‏ ‎Common. ‎По‏ ‎сути ‎Core‏ ‎– ‎это‏ ‎точка,‏ ‎в ‎которой‏ ‎инициализируются ‎все ‎основные ‎системы, ‎а‏ ‎также ‎это‏ ‎фасад для‏ ‎доступа ‎ко ‎всем‏ ‎этим ‎системам.

Ядро‏ ‎включает ‎систему ‎сохранения, ‎локализацию,‏ ‎асинхронный‏ ‎загрузчик ‎сцен,‏ ‎механику ‎паузы‏ ‎и ‎некоторые ‎другие ‎вещи.

Вторая ‎сцена‏ ‎–‏ ‎инициализация ‎ядра‏ ‎проекта ‎и‏ ‎выбор ‎предварительных ‎настроек ‎– ‎языка‏ ‎локализации,‏ ‎громкости‏ ‎и ‎вибрации.

Ядро‏ ‎проекта, ‎по‏ ‎аналогии, ‎содержит‏ ‎в‏ ‎себе ‎вещи,‏ ‎к ‎которым ‎нужен ‎доступ ‎в‏ ‎процессе ‎игры.‏ ‎Только‏ ‎те ‎вещи, ‎которые‏ ‎относятся ‎к‏ ‎этому ‎проекту.

После ‎всех ‎инициализаций‏ ‎запускается‏ ‎сцена ‎с‏ ‎убежищем ‎главного‏ ‎героя, ‎охотника ‎на ‎нечисть.