Комментарии 14
Согласен с тем, что OneLine не нужно использовать абсолютно везде. Я специально выбрал пример с массивом: он хорошо показывает, как быстро увеличивается длина строки. Однако многим базам данных в играх OneLine придает вполне сносный и удобный вид.
Мой опыт разработки лежит в области мобильных игр, и на одну базу данных, которая не вместилась бы в экран, приходится несколько мелких, где у каждого элемента лишь 2-3 простых поля.
К тому же, я думаю о возможности рисовать поле в несколько строк (хоть это и странно с таким названием). Но пока не знаю, как сделать это простым и удобным. К сожалению, не всегда легко найти компромисс между простотой и функциональность.
Вещи, вроде списков строк для локализаций, вполне удобно импортировать из гуглтаблиц, но ими мир баз данных в разработке игр не ограничивается.
Примеры:
habrastorage.org/webt/59/ec/b4/59ecb40202b82038774726.png
habrastorage.org/webt/59/ec/b4/59ecb4e1755d1237482621.png
Это все дампится в csv, потом прокатывается скриптом в редакторе и гонится в json. Первая строка определяет имя поля, вторая — тип кавычек вокруг, либо игнорирование поля (например, комментарии).
Я работал в команде, где художники хотели стать лучше и учились. И они разбирались в том, кто такие шейдеры, и зачем нужны батчинг мешей и спрайт пакер.
Хотя я разрабатывал в небольшой команде из 15 человек, и даже там (и в соседних проектах) встречались члены, не желающие учиться и ломающие процесс разработки (и увеличивающие размеры билдов, если уж на то пошло). Но с единичными случаями обломовщины лучше бороться иными способами, чем просто «посадить всех не-программистов» в песочницу и пусть там копошатся).
UPD: не ответил на вопрос «в чем проблема»: проблема в опечатках (в Ваших примерах столбцы Name, Description, Image, Script — не выпадающие списки, а строки, набранные от руки) и постоянной синхронизации дока и скрипта.
проблема в опечатках (в Ваших примерах столбцы Name, Description, Image, Script — не выпадающие списки
Поля в данном случае забиты не дизайнером и фиксированы как заголовки + все данные проверяются в editor-скрипте импорта с быстрым остановом на любой ошибке и дампом в лог. Смысл в том, чтобы дать инструмент для модификации контента вне юнити и не парить никому мозг с потенциально некорректным поведением кастомных инспекторов в юнити / неработающим undo и т.п спецификой. Внешние редакторы дают воспроизводимость данных, в случае google sheets — откат каждой операции с логированием в истории.
он простоКстати об этом. Официальные доки юнити по поводу SerializeField пишут «You will almost never need this.», как бы намекая нам, что движок предполагает ненормальное программирование.делает поле публичнымдобавляет к полю [SerializeField]
GUILayout чтобы рассчитать размеры рисуемых полей, вызывает метод OnGUI дваждыЭто еще что. Совершенно замечательная ситуация вырисовывается, когда нужно сделать перекрывающиеся элементы интерфейса (например панели). А порядок отрисовки и проверки событий ввода у виджетов в юнити совпадает, следовательно первым обработает событие виджет который на самом дальнем плане.
Интересная статья, спасибо!
Есть другой вариант. Если не задавать все объекты прямо в одном файле (это касается как json, там и yaml - юнитевских scriptableobject'ов и других форматов), а делать по файлу на сущность, то и мержится это хорошо в VCS и есть стандартные средства работы как с файлами - через Project окошко Unity (поиск, разложение по папкам...). По надобности их можно собрать вместе, бросив в список
public List<CharacterData> characters;
на какой-нибудь рутовый ScriptableObject. Из минусов - кликать нужно, чтобы открыть параметры для настройки. Но можно привыкнуть (или открыть два окна инспектора, один залочив на рутовый SO - лайфхак).
Интеграцию с гугл доками можно запилить по надобности, не нарушая разложения на файлы под VCS. Импорт/Экспорт/Синхронизация. Как мне кажется, формат хранения данных не должен меняться в зависимости от отображения
Надоело писать PropertyDrawer в Unity? Есть способ лучше