Уже довольно давно появились assembly definitions, части кода можно выделять в отдельные assembly. Это ускоряет процесс разработки (компилируется только измененённые), а также даёт возможность разбить проект на куски и настроить кто от кого зависит.
AssetPostprocessor'ы лучше скомпилировать и подключать как DLL особенно если используется кеш-сервер (сейчас наверно можно через asmdef). Дело в том, что они не выполняются если в их assembly есть ошибки. И если у вас одновременно новый ассет и ошибки в коде, то на кеш сервер уходит ассет для которого post processor не был вызван. И потом может внезапно выплыть на билд машине.
Также была забавная проблема с AssetPostprocessor'ом. На одном из релизов вдруг поменялись хеши у кучи asset bundle'ов. Для пользователей это гигабайты перекачки. Оказалось в одной из используемых нами внешних библиотек добавили AssetPostprocessor для сцен. Он как бы ничего особо не делал, просто был. Но Unity ведь не знает об этом. Изменён пост процессинг ресурса, значит ресурс импортится по-другому, вот тебе новый хеш.
Я в райдер перешёл с Visual Studio (и куча коллег заодно). Навигация по коду несравнимо быстрее. Рефакторинг удобней. Отличная поддержка систем контроля версий, чтоб вообще не вылезать из него.
Я сейчас начал Lubunt'ы новые пробовать. То не работает кнопка на тачпаде, то звука нет. Остановился на 16.04. В ней после установки 190Mb всего на старте отъедается (в прошлый раз наверно понаставил всякого).
Попробовал BunsenLabs Lithium, из коробки после старта те же 350-400Мб. Можно, наверно, заморочится с настройкой, но времени жалко да и не нужно особо.
Я перебирал разные системы на древнем Asus EEE PC с Atom'ом и 2Gb оперативки (больше поставить нельзя). Остановился на Lubuntu + XFCE. 380мб занято после загрузки системы. Работать в консоли и с утилитками можно. Но после загрузки браузера с парой вкладок память забивается практически вся. 2Gb для современного интернета не хватает категорически.
Я как раз после тормозов терминала начал исследовать. В терминале убунта стоит дефолтным профилем.
Первый запуск — секунды две-три. Потом почти мгновенно. 3900x + nvme
Если закрыть все инстансы wsl и немного подождать (чтобы wsl --list --verbose писал что все stopped, это не сразу происходит), то следующий запуск снова тормозит.
Перешёл на WSL2. Старт происходит с задержкой ~2 секунды. Бесит ужасно. Гуглил, менял всякие префсы, отключал поиск x11 и звука — ничего не помогает.
Пришлось откатиться на WSL1.
Используете ли triangle strips? Хотя с оптимизированной сеткой это нетривиальная задача.
И вот в этих местах нет «дырок»? Там по сути разрыв в топологии. Может «дребезжать» на больших расстояниях.
Баг в давнишней игре под старые телефоны (brew). В игре можно было менять цвет одежды персонажа. Тестеры обнаружили, что если выбрать русский язык, то цвет одежды менялся слабо и всегда был какой-то серый и тусклый. Баг долго отпинывали, потом решили разобраться.
Вообщем после исследования обнаружилось, что слово «продолжить» несколько длиннее слова «continue» и своим хвостом залезает в кусок памяти с цветом одежды.
Как уже заметили, проще для дата-классов использовать ScriptableObject. Урок от Unity как им пользоваться как раз для таких задач.
Вообще, в больших проектах дизайнерам проще работать с Excel'ем. Забивать туда сотни и тысячи item'ов, высчитывать по странным формулам цену, графики рисовать и прочее. Потом всё это экспортится в xml или json. Хотя можно прямо из xls читать. Некоторые вообще по сети из google spreadsheet конфиги тянут.
Читал байку про один банк, там охранник сидел рядом с критичными данными. На корпусе был нарисован крестик, куда стрелять из дробовика, если вдруг что.
Немного дополню.
Уже довольно давно появились assembly definitions, части кода можно выделять в отдельные assembly. Это ускоряет процесс разработки (компилируется только измененённые), а также даёт возможность разбить проект на куски и настроить кто от кого зависит.
AssetPostprocessor'ы лучше скомпилировать и подключать как DLL особенно если используется кеш-сервер (сейчас наверно можно через asmdef). Дело в том, что они не выполняются если в их assembly есть ошибки. И если у вас одновременно новый ассет и ошибки в коде, то на кеш сервер уходит ассет для которого post processor не был вызван. И потом может внезапно выплыть на билд машине.
Также была забавная проблема с AssetPostprocessor'ом. На одном из релизов вдруг поменялись хеши у кучи asset bundle'ов. Для пользователей это гигабайты перекачки. Оказалось в одной из используемых нами внешних библиотек добавили AssetPostprocessor для сцен. Он как бы ничего особо не делал, просто был. Но Unity ведь не знает об этом. Изменён пост процессинг ресурса, значит ресурс импортится по-другому, вот тебе новый хеш.
Отключение UMIP не помогает. Такой вот лаг на 3 секунды.
Первый запуск — секунды две-три. Потом почти мгновенно. 3900x + nvme
Если закрыть все инстансы wsl и немного подождать (чтобы wsl --list --verbose писал что все stopped, это не сразу происходит), то следующий запуск снова тормозит.
Пришлось откатиться на WSL1.
Если проект большой, то можно в докере подмонтировать глобальный volume для промежуточных файлов сборки. Чтобы не пересобирать каждый раз с нуля.
И вот в этих местах нет «дырок»? Там по сути разрыв в топологии. Может «дребезжать» на больших расстояниях.
Вообщем после исследования обнаружилось, что слово «продолжить» несколько длиннее слова «continue» и своим хвостом залезает в кусок памяти с цветом одежды.
Вообще, в больших проектах дизайнерам проще работать с Excel'ем. Забивать туда сотни и тысячи item'ов, высчитывать по странным формулам цену, графики рисовать и прочее. Потом всё это экспортится в xml или json. Хотя можно прямо из xls читать. Некоторые вообще по сети из google spreadsheet конфиги тянут.
Хм, правда при этом он теряет возможность одновременного редактирования множества объектов даже при указанном [CanEditMultipleObjects]
Нарисовало, но уж очень медленно. Compile and render (который по F6), вообще не дождался. А вообще крутая штука.