Comments
Что поделаешь… приходится много чего дописывать самому. Без своих и 3-х лиц екстеншенов Юнити почти не стоит ничего — большой катящийся ком, наследие начала развития 3д-движков.
Спасибо за статью и инструмент, обязательно попробую его, как раз стоял вопрос об удобном способе представить базу в редакторе.
Не самый удачный способ по ряду причин(нет подписи у полей, при большом количестве переменных нужных геймдизу линия не будет помещаться на экране). Сам стараюсь делать кастомный эдитор и в каждом классе описывать его GUI. Если кому интересно расскажу.

Согласен с тем, что OneLine не нужно использовать абсолютно везде. Я специально выбрал пример с массивом: он хорошо показывает, как быстро увеличивается длина строки. Однако многим базам данных в играх OneLine придает вполне сносный и удобный вид.


Мой опыт разработки лежит в области мобильных игр, и на одну базу данных, которая не вместилась бы в экран, приходится несколько мелких, где у каждого элемента лишь 2-3 простых поля.


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

Очень даже интересно. Не знаю как тут принято, но буду благодарен за уделенное время
Но… зачем? Гораздо проще использовать для этого google sheets (с combobox-ами и листами для выбора, с первичной проверкой данных), а из редактора сливать их через csv / json. Там и комментарии можно прикрутить и все, что угодно, включая сборку в один список из нескольких листов.
Каким образом в Google Sheets Вы проставите ссылки на наследников UnityEngine.Object вроде префабов, шейдеры, анимации и т.д?

Вещи, вроде списков строк для локализаций, вполне удобно импортировать из гуглтаблиц, но ими мир баз данных в разработке игр не ограничивается.
А в чем проблема? Дизайнер вообще не должен напрямую что-то указывать и создавать в проекте — это гарантированно ведет к появлению статей «как почистить проект, чтобы он не занимал столько места». Дизайнеру достаточно оперировать сущностями, которые он может выбрать из фиксированного списка через combobox в гугло-таблицах. Эти списки забиваются программером после реализации их в проекте, у дизайнера просто нет доступа на запись в них.
Примеры:
habrastorage.org/webt/59/ec/b4/59ecb40202b82038774726.png
habrastorage.org/webt/59/ec/b4/59ecb4e1755d1237482621.png
Это все дампится в csv, потом прокатывается скриптом в редакторе и гонится в json. Первая строка определяет имя поля, вторая — тип кавычек вокруг, либо игнорирование поля (например, комментарии).
Когда мы писали на самописном движке, мы также работали через гугл доки. Но какой смысл выносить разработку из Unity в браузер? Только чтобы оградить мозг геймдизайнера от базовых знаний о редакторе Unity?

Я работал в команде, где художники хотели стать лучше и учились. И они разбирались в том, кто такие шейдеры, и зачем нужны батчинг мешей и спрайт пакер.

Хотя я разрабатывал в небольшой команде из 15 человек, и даже там (и в соседних проектах) встречались члены, не желающие учиться и ломающие процесс разработки (и увеличивающие размеры билдов, если уж на то пошло). Но с единичными случаями обломовщины лучше бороться иными способами, чем просто «посадить всех не-программистов» в песочницу и пусть там копошатся).

UPD: не ответил на вопрос «в чем проблема»: проблема в опечатках (в Ваших примерах столбцы Name, Description, Image, Script — не выпадающие списки, а строки, набранные от руки) и постоянной синхронизации дока и скрипта.
К сожалению, чем дальше использую юнити, тем больше убеждаюсь, что чем меньше используется ее средств — тем лучше. Внутренние форматы могут меняться, апи может меняться — все это ведет к некорректному поведению тулзов (необходимости постоянно мониторить, что отпало в новом апдейте юнити) и потенциальной потере данных. Поэтому чем больше внешних данных, которые можно перегонять простейшими тулзами без UI в те же собственные текстовые / бинарные форматы внутри юнити для ручной загрузки — тем лучше / стабильнее оно работает (пайплайн переносим между проектами / версиями юнити без боли).
проблема в опечатках (в Ваших примерах столбцы Name, Description, Image, Script — не выпадающие списки

Поля в данном случае забиты не дизайнером и фиксированы как заголовки + все данные проверяются в editor-скрипте импорта с быстрым остановом на любой ошибке и дампом в лог. Смысл в том, чтобы дать инструмент для модификации контента вне юнити и не парить никому мозг с потенциально некорректным поведением кастомных инспекторов в юнити / неработающим undo и т.п спецификой. Внешние редакторы дают воспроизводимость данных, в случае google sheets — откат каждой операции с логированием в истории.
он просто делает поле публичным добавляет к полю [SerializeField]
Кстати об этом. Официальные доки юнити по поводу SerializeField пишут «You will almost never need this.», как бы намекая нам, что движок предполагает ненормальное программирование.

GUILayout чтобы рассчитать размеры рисуемых полей, вызывает метод OnGUI дважды
Это еще что. Совершенно замечательная ситуация вырисовывается, когда нужно сделать перекрывающиеся элементы интерфейса (например панели). А порядок отрисовки и проверки событий ввода у виджетов в юнити совпадает, следовательно первым обработает событие виджет который на самом дальнем плане.
Тоже не раз сталкивался с порядком отрисовки в интерфейсах Unity. С какого-то момента я просто перестал думать «Сейчас быстренько сделаю эту фичу», а перешел к более пессимистичному «Интересно, что нового я узнаю об особенностях Unity?»
Only those users with full accounts are able to leave comments. Log in, please.