Comments 10
Cloud build? =-o
1. Платно. Не всем подходит.
2. А он позволяет подменять ассеты и поддерживать разные конфигурации?
3. Для аутсорсовых проектов удобнее передать все с таким вот плагином, чтобы заказчик сам легко и просто мог собирать нужные ему билды.
Вот по этим причинам хотелось весь озвученный функционал засунуть в сам проект, чтобы он был самодостаточен в т.ч. по вопросам сборки.
2. А он позволяет подменять ассеты и поддерживать разные конфигурации?
3. Для аутсорсовых проектов удобнее передать все с таким вот плагином, чтобы заказчик сам легко и просто мог собирать нужные ему билды.
Вот по этим причинам хотелось весь озвученный функционал засунуть в сам проект, чтобы он был самодостаточен в т.ч. по вопросам сборки.
1. Очень дешево
2. Есть AssetBundle и директивы препроцессора
3. Еще больше его запутать кучей настроек в этой надстройке? очень умное решение :-)
2. Есть AssetBundle и директивы препроцессора
3. Еще больше его запутать кучей настроек в этой надстройке? очень умное решение :-)
1. Вы правы. Но каждый раз убеждать заказчиков, что им это нужно, не менее утомительно чем собирать самому руками.
2. Прошу прощения, я действительно по причине из п.1 не работал с cloud build. И сходу не нагуглил. Как там можно поменять иконку для конкретного билда? И там можно наследовать конфигурации друг от друга?
3. А заказчику и не нужно лезть в настройки. Проект отдается со всеми преднастроенными конфигурациями. Заказчик играется с балансом, меняет арт. А потом одной кнопкой получает все билды. И не отвлекает нас на такие мелочи.
4. Наша внутренняя инфраструктура во многом завязана на локальный gitlab, быстро и удобно. CI я хотел бы оставить там же.
5. В самом начале статьи я упомянул, что данная проблема в принципе имеет множество разных решений. Просто по своим причинам я выбрал такое. У кого-то их может и не быть. А у кого-то может. Поэтому решил поделиться. Свобода выбора вроде как.
2. Прошу прощения, я действительно по причине из п.1 не работал с cloud build. И сходу не нагуглил. Как там можно поменять иконку для конкретного билда? И там можно наследовать конфигурации друг от друга?
3. А заказчику и не нужно лезть в настройки. Проект отдается со всеми преднастроенными конфигурациями. Заказчик играется с балансом, меняет арт. А потом одной кнопкой получает все билды. И не отвлекает нас на такие мелочи.
4. Наша внутренняя инфраструктура во многом завязана на локальный gitlab, быстро и удобно. CI я хотел бы оставить там же.
5. В самом начале статьи я упомянул, что данная проблема в принципе имеет множество разных решений. Просто по своим причинам я выбрал такое. У кого-то их может и не быть. А у кого-то может. Поэтому решил поделиться. Свобода выбора вроде как.
проект видимо для тех кто близок к написанию своего такого
ни подробностей про установку, ни требуемых зависимостей итд
ни подробностей про установку, ни требуемых зависимостей итд
Прошу прощения, в данный момент все действительно больше похоже на техническое превью. Толковый readme и wiki на гитхабе я только собираюсь оформить. А так же добавить плагин в ассет стор. Сейчас же я с радостью помогу вам. На гитхабе лежит library project, все зависимости там автоматически вытягиваются через nuget, поэтому можно просто клонировать репу и собрать (хотя наверное не без приседаний, нужно настроить BuildVariants.csproj.user, указать где лежит юнити и куда копировать файлы после сборки). Далее скопировать все dll в любую Editor папку в проекте.
Но в процессе написания этого комментария я понял, что лучше сделать релиз на гитхабе, который просто можно скачать вот здесь. Само окно плагина находится в Window/BuildVariants
Но в процессе написания этого комментария я понял, что лучше сделать релиз на гитхабе, который просто можно скачать вот здесь. Само окно плагина находится в Window/BuildVariants
Еще раз. Зачем писать плагин, который сереализует\десереализует ProjectSettings файл на диске.
Чем неподходит ясное API предоставляемое Unity через PlayerSettings и вложенные классы PlayerSettings.* вкупе с вызовом .unity.exe -batchmode -executeMethod *билд с настройками под каждую платформу*
?
Чем неподходит ясное API предоставляемое Unity через PlayerSettings и вложенные классы PlayerSettings.* вкупе с вызовом .unity.exe -batchmode -executeMethod *билд с настройками под каждую платформу*
?
Я понимаю, что со стороны это выглядит так: «чувак наделал костылей и пытается их продвинуть». Костыльность самостоятельной сериализации/десериализации настроек впрочем не отрицаю, но способа лучше я не нашел. Причины:
1. Основная. Хотелось иметь UI для более менее гибкой конфигурации. Чтобы не вникая в API и не отслеживая изменения в нем (а ребята из Unity любят его менять) можно было добавить какой-то новый вариант билда. Чтобы любой джун, не тратя время на гугление, мог открыть настройки проекта, натыкать необходимое в них, проверить их корректность без сборки билда и сохранить этот вариант. Чтобы для понимания настроек конкретного варианта было достаточно переключиться в него и для этого не нужно было изучать чужой спагетти код (который джуны любят копипастить со стэка прям кусками). В документации юнити пример с кодом подстановки иконок под android и ios едва влезает в экран, натыкать иконки в родном UI от Unity труда не составит. Опять же PlayerSettings это код и его нужно поддерживать. А мне хочется писать код для игр, а не для их сборки.
2. Когда я пришел к такому решению, я подумал, что может быть и не лишней будет возможность конфигурирования настроек, недоступных через PlayerSettings. Например Fixed timestemp или настройки физики или инпута. Самому никогда подобного не требовалось, но вдруг гипотетически захочется и будут на то причины. Why not?
Мне самому гораздо больше нравится идея подсовывать настройки без записи на диск, это гораздо правильнее, но вот так…
Убедительно или по-прежнему не очень?)
1. Основная. Хотелось иметь UI для более менее гибкой конфигурации. Чтобы не вникая в API и не отслеживая изменения в нем (а ребята из Unity любят его менять) можно было добавить какой-то новый вариант билда. Чтобы любой джун, не тратя время на гугление, мог открыть настройки проекта, натыкать необходимое в них, проверить их корректность без сборки билда и сохранить этот вариант. Чтобы для понимания настроек конкретного варианта было достаточно переключиться в него и для этого не нужно было изучать чужой спагетти код (который джуны любят копипастить со стэка прям кусками). В документации юнити пример с кодом подстановки иконок под android и ios едва влезает в экран, натыкать иконки в родном UI от Unity труда не составит. Опять же PlayerSettings это код и его нужно поддерживать. А мне хочется писать код для игр, а не для их сборки.
2. Когда я пришел к такому решению, я подумал, что может быть и не лишней будет возможность конфигурирования настроек, недоступных через PlayerSettings. Например Fixed timestemp или настройки физики или инпута. Самому никогда подобного не требовалось, но вдруг гипотетически захочется и будут на то причины. Why not?
Мне самому гораздо больше нравится идея подсовывать настройки без записи на диск, это гораздо правильнее, но вот так…
Убедительно или по-прежнему не очень?)
Поддерживаю, самому приходилось заниматься проектами, которые собирались под несколько разных платформ (пк, айос, андроид), разные маркеты (аппстор, гуглстор, самсунгстор), разную монетизацию (премиум/ф2п), разными фичами (с мультиплеером/без). Это все в рамках одного проекта, и API Юнити там явно не хватало. Плюс встречались очень специфичные вещи. Например, одна из СДК для мобильной аналитики тупо не давала собирать билд под ПС4. Ее приходилось физически убирать из проекта перед таким билдом (настройки плагина в инспекторе не помогали). Это, конечно, скорее косяк СДК, но пока они его поправят, могут пройти годы, а билды иногда каждый день нужно собирать, так что собственная автоматизация тут спасает.
Sign up to leave a comment.
Упрощаем сборку билдов в Unity3D