Неделя 6 (ноябрь 1): Загрузка конфигов из гуглотаблиц.

Оглавление

Оказалось что конфиги в виде JSONа нечитаемы и нередактируемы. И даже нетабличный вид является не самой большой проблемой. Проблемой оказалось привязывание к цифровым айдишникам (вообще не знаю почему я не смог просто начать использовать строковой тип для айдишников) и энумы в виде цифр — нечитаемы. Плюс к тому многовато всего было захардкожено. Это стало критически неудобно и я стал искать способ редактировать конфиги более удобным редактором.

Тут было два варианта: делать свой, целиком контролируемый редактор, на самой юните, либо переходить на таблицы экселя или гуглодоков.

Недостатком создания редактора в юните заключается запредельная сложность разработки собственных интерфейсов — кастомных эдиторов — работающих в условиях самого юнитевого редактора. На мой вкус их делать значительно сложнее чем интерфейсы для игры — там больше свободы и возможностей.

Основным же недостатком гугла является невозможность сделать заполняемые поля. Механизм Data Validation близок к тому что нужно, но не совсем. Мне нужно чтобы данные выбирались из разных источников… когда выбор типа объекта (например, постройка или рецепт), приводит к тому, что айдишник объекта берется из соответствующей таблицы (построек или рецептов).

На 20й неделе конфиг бонусов переживет серьезные изменения: бонус получит возможность принадлежать не только рецепту, но и предмету. Одинаковые слова в столбце ownerId могут ввести в заблуждение: их смысл зависит от BonusOwnerType. Если типа владельца бонуса — рецепт, то Hammer обозначает название рецепта. Если же тип владельца бонуса — артикул, то Hammer уже означает название предмета. И при заполнении такой таблицы становится легко ошибиться. Конечно, значительно облегчат жизнь префиксы, как в столбце BonusType. Но от глупых ошибок, возникающих из-за невнимательности, они не защитят.

***

В общем, если бы плагин Odin — Inspector and Serializer появился у меня на месяц раньше, у меня был бы собственный редактор данных с сохранением в JSONе или вообще в scriptable objectе (к чему я в итоге все равно пришел). Но программирование собственного интерфейса для редактора юнити я не осилил и пришлось обратиться ко второму варианту решения проблемы: я начал смотреть на загрузку данных из внешних таблиц. И остановился я на QuickSheet, потому что он был бесплатным, с открытым кодом и, главное, несмотря на свою антикварность, он работал.

Особенностью плагинов, загружающих данные из гуглодоков является то, что гуглодоки не так просто эти данные отдают. Необходима не очень казуальная настройка прав доступа. А учитывая что Google очень любит менять свои интерфейсы, описания того как все настроить довольно быстро устаревают. Примерно раз в пару лет. Ну и в отличии от других плагинов QuickSheet имел актуальное описание настройки. Собственно, поэтому он и работал, в отличии от других.

Но почти вся неделя у меня ушла на то, чтобы заставить этот плагин не просто работать, а работать как мне нужно.

Проблема заключалась вот в чем: плагин устроен так, что при настройке нескольких scriptable objectов, связанных с подключением к гуглдокам и сбором информации о столбцах гуглдочной таблицы, происходила генерация непосредственно класса данных и запись собственно данных в очередной scriptable object (да, плагин их довольно много генерирует). Но во-первых, у меня уже были классы данных, созданные ранее для работы с конфигами на JSONе. А во-вторых, мне нужно было добиться от плагина генерации полей класса данных в правильном с моей точки зрения формате (там множество сугубо эстетических заморочек типа названия полей с маленькой буквы и добавления слова Data в конце).

Само по себе это оказалось не слишком сложно: плагин генерировал классы на основе текстовых шаблонов, которые можно было относительно просто подкорректировать. Но дело в том, что проверить работоспособность всего механизма можно только если в проекте нет ошибок. А ошибки были по причине того, что мне нужно было подготовить замену старых классов данных (удалить их из проекта, что само по себе приводило бы к ошибкам) новыми, которые еще не были созданы по причине того, что генератор не работал из-за ошибок.

Догадаться использовать новый, пустой проект в качестве заготовки — не мое.

Оглавление