Unity порядок в проекте. Данные

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

Поэтому чтобы избежать лишней работы в будущих проектах и сделать их структуру максимально читаемой я решил заняться упорядочиванием данных в проекте. Вот к чему я пришёл.

Я разделил данные на три вида:

1. Игровой контент
2. Данные игровой сессии
3. Данные уровня

Остановлюсь поподробнее на каждом из пунктов.

Игровой контент

Работа с этим типом данных производится при помощи инструментов unity практически на 100%.

• Префабы объектов с их настройками
• Наполнение уровней
• Интерфейс пользователя
• Текстурки картинки и всё прочее

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

Unity предоставляет множество удобных инструментов для работы с контентом.

Данные игровой сессии

На этом пункте хотелось бы заострить внимание.

Глобально - это вся информация которая представляет прогресс игрока в игре. Она постоянно меняется и сохраняется во внешнем хранилище, либо в файловой системе, либо на удалённом сервере.

• Количество игровой валюты
• Предметы инвентаря
• Скины и прочие ресурсы которые принадлежат игроку
• Всякого рода настройки

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

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

Также этот класс является интерфейсом для доступа к данным из любых объектов проекта.

Например. Главное меню игры. Нужно отобразить сколько у игрока золота.

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

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

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

Итак, что у нас есть: статические данные (контент), изменяемые данные в течение всей сессии игры (от момента открытия приложения, до его закрытия). Теперь переходим ещё немного глубже.

Данные уровня

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

Как правило это:

• HP игрока
• ресурсы
• очки
• сколько осталось врагов и прочее

Под эту информацию я планирую выделять просто определённое место в скриптах. По соседству с данными контента. Обязательно помещать их в специально созданный регион.

Здесь важно отметить, что если нам нужны какие-то параметры из контента, то лучше их задублировать в отдельном поле. Это под вопросом, т.к. я ещё не совсем проработал всю концепцию.