Каюсь, немного преувеличил) Хотя если бы игра была про стрижку газона, то большую часть бюджета вполне можно было бы потратить на траву. В нашем же проекте она скорее как декорация, поэтому ее количество старались как можно больше ограничивать левел дизайном. Основной частью нашего геймплея были орды юнитов, поэтому вместо использования SkinnedMesh с аниматором я запекал анимации в текстуры и проигрывал их шейдером. Про это тоже думаю сделать на досуге заметку.
Красивое. Надеюсь дожить до проекта, в котором потребуется сделать нечто подобное. В данном конкретном проекте красивая трава смотрелась бы слишком инородно.
Да, некоторая оптимизация со стороны меша могла бы сильно помочь. В вариантах с GameObjects мы бы могли заметно сократить их количество. В варианте прямой отрисовки мы бы смогли уменьшить размер передаваемого в GPU буфера позиций. Но как-то так получилось, что изначальный меш, который я собрал в ProBuilder для тестов, остался в игре навсегда, без привлечения моделлеров. Трава все же не была самоцелью.
От себя хочу добавить вариант “неуважение к читателю”. Когда автор поста не отвечает на вопросы в комментариях, начинает грубить и срываться в истерику. По мне пост на хабре подразумевает некоторую дискуссию. И если ты к ней не готов, то стоит ли тогда что-либо публиковать? Тем более неадекват в комментариях сразу же снижает ценность поста в глазах общественности. Из ярких представителей могу назвать относительно недавнюю серию (кажется их было больше 1) постов про какой-то авторский алгоритм сортировки.
Так а в чем удобство? Вы одним махом обрубаете кучу прелестей современных IDE, при этом связность кода понижается совсем слегка.
Когда одному из компонентов понадобится изменить функционал так, что некая его «переменная» приобретёт совершенно иной смысл, то вы оставите ей прежнее имя (которое более не соответствует действительности) или будете все же переименовывать? Разумеется под именем я подразумеваю ключ переменной в вашем словаре.
И раз уж вы тут производительность упомянули: доступ по строке в словаре отнюдь не бесплатный, в вашем решении имеет место быть боксинг (возможен даже в очень больших количествах, если например в апдейтах обращаться к общему состоянию), зачем-то определён Update в базовом классе (кстати зачем?).
Для уменьшения связности кода я бы в первую очередь предложил пересмотреть архитектуру. Ну а далее ECS и/или DI.
Когда начались перебои в работе телеграмма, мы маленькой студией из 15 человек перешли на self hosted Mattermost. Коробочная интеграция с гитлабом, плагин для редмайна, плагин в проведения опросов в каналах. В общем горя не знаем с тех пор. Шероховатости есть, но страдать не приходится.
Тут много про это написали уже, одно важное уточнение для всех: в бесплатной версии пуши идут через их Test Push Notification Service, который не гарантирует production level uptime, но все же работает вполне прилично. Не супер надежно и нет полной гарантии приватности, но работает. Для приватности кстати там можно выключить отправку самого сообщения внутри пуша. В таком случае пуш будет сообщать только о факте нового сообщения.
Форвардинг насколько я помню действительно кривой. Переправляется не само сообщение, а ссылка на него. Соотвественно если сообщение было в приватном канале, то человек вне канала не сможет ее открыть.
Я понимаю, что со стороны это выглядит так: «чувак наделал костылей и пытается их продвинуть». Костыльность самостоятельной сериализации/десериализации настроек впрочем не отрицаю, но способа лучше я не нашел. Причины:
1. Основная. Хотелось иметь UI для более менее гибкой конфигурации. Чтобы не вникая в API и не отслеживая изменения в нем (а ребята из Unity любят его менять) можно было добавить какой-то новый вариант билда. Чтобы любой джун, не тратя время на гугление, мог открыть настройки проекта, натыкать необходимое в них, проверить их корректность без сборки билда и сохранить этот вариант. Чтобы для понимания настроек конкретного варианта было достаточно переключиться в него и для этого не нужно было изучать чужой спагетти код (который джуны любят копипастить со стэка прям кусками). В документации юнити пример с кодом подстановки иконок под android и ios едва влезает в экран, натыкать иконки в родном UI от Unity труда не составит. Опять же PlayerSettings это код и его нужно поддерживать. А мне хочется писать код для игр, а не для их сборки.
2. Когда я пришел к такому решению, я подумал, что может быть и не лишней будет возможность конфигурирования настроек, недоступных через PlayerSettings. Например Fixed timestemp или настройки физики или инпута. Самому никогда подобного не требовалось, но вдруг гипотетически захочется и будут на то причины. Why not?
Мне самому гораздо больше нравится идея подсовывать настройки без записи на диск, это гораздо правильнее, но вот так…
Убедительно или по-прежнему не очень?)
Прошу прощения, в данный момент все действительно больше похоже на техническое превью. Толковый readme и wiki на гитхабе я только собираюсь оформить. А так же добавить плагин в ассет стор. Сейчас же я с радостью помогу вам. На гитхабе лежит library project, все зависимости там автоматически вытягиваются через nuget, поэтому можно просто клонировать репу и собрать (хотя наверное не без приседаний, нужно настроить BuildVariants.csproj.user, указать где лежит юнити и куда копировать файлы после сборки). Далее скопировать все dll в любую Editor папку в проекте.
Но в процессе написания этого комментария я понял, что лучше сделать релиз на гитхабе, который просто можно скачать вот здесь. Само окно плагина находится в Window/BuildVariants
1. Вы правы. Но каждый раз убеждать заказчиков, что им это нужно, не менее утомительно чем собирать самому руками.
2. Прошу прощения, я действительно по причине из п.1 не работал с cloud build. И сходу не нагуглил. Как там можно поменять иконку для конкретного билда? И там можно наследовать конфигурации друг от друга?
3. А заказчику и не нужно лезть в настройки. Проект отдается со всеми преднастроенными конфигурациями. Заказчик играется с балансом, меняет арт. А потом одной кнопкой получает все билды. И не отвлекает нас на такие мелочи.
4. Наша внутренняя инфраструктура во многом завязана на локальный gitlab, быстро и удобно. CI я хотел бы оставить там же.
5. В самом начале статьи я упомянул, что данная проблема в принципе имеет множество разных решений. Просто по своим причинам я выбрал такое. У кого-то их может и не быть. А у кого-то может. Поэтому решил поделиться. Свобода выбора вроде как.
1. Платно. Не всем подходит.
2. А он позволяет подменять ассеты и поддерживать разные конфигурации?
3. Для аутсорсовых проектов удобнее передать все с таким вот плагином, чтобы заказчик сам легко и просто мог собирать нужные ему билды.
Вот по этим причинам хотелось весь озвученный функционал засунуть в сам проект, чтобы он был самодостаточен в т.ч. по вопросам сборки.
В моем комментарии не столько про саму инверсию было, сколько про то, что не все делается классами и наследованием.
А если один класс должен реализовывать несколько разных интерфейсов?
Каюсь, немного преувеличил) Хотя если бы игра была про стрижку газона, то большую часть бюджета вполне можно было бы потратить на траву. В нашем же проекте она скорее как декорация, поэтому ее количество старались как можно больше ограничивать левел дизайном. Основной частью нашего геймплея были орды юнитов, поэтому вместо использования SkinnedMesh с аниматором я запекал анимации в текстуры и проигрывал их шейдером. Про это тоже думаю сделать на досуге заметку.
Красивое. Надеюсь дожить до проекта, в котором потребуется сделать нечто подобное. В данном конкретном проекте красивая трава смотрелась бы слишком инородно.
Да, некоторая оптимизация со стороны меша могла бы сильно помочь. В вариантах с GameObjects мы бы могли заметно сократить их количество. В варианте прямой отрисовки мы бы смогли уменьшить размер передаваемого в GPU буфера позиций. Но как-то так получилось, что изначальный меш, который я собрал в ProBuilder для тестов, остался в игре навсегда, без привлечения моделлеров. Трава все же не была самоцелью.
От себя хочу добавить вариант “неуважение к читателю”. Когда автор поста не отвечает на вопросы в комментариях, начинает грубить и срываться в истерику. По мне пост на хабре подразумевает некоторую дискуссию. И если ты к ней не готов, то стоит ли тогда что-либо публиковать? Тем более неадекват в комментариях сразу же снижает ценность поста в глазах общественности. Из ярких представителей могу назвать относительно недавнюю серию (кажется их было больше 1) постов про какой-то авторский алгоритм сортировки.
Так а в чем удобство? Вы одним махом обрубаете кучу прелестей современных IDE, при этом связность кода понижается совсем слегка.
Когда одному из компонентов понадобится изменить функционал так, что некая его «переменная» приобретёт совершенно иной смысл, то вы оставите ей прежнее имя (которое более не соответствует действительности) или будете все же переименовывать? Разумеется под именем я подразумеваю ключ переменной в вашем словаре.
И раз уж вы тут производительность упомянули: доступ по строке в словаре отнюдь не бесплатный, в вашем решении имеет место быть боксинг (возможен даже в очень больших количествах, если например в апдейтах обращаться к общему состоянию), зачем-то определён Update в базовом классе (кстати зачем?).
Для уменьшения связности кода я бы в первую очередь предложил пересмотреть архитектуру. Ну а далее ECS и/или DI.
Когда начались перебои в работе телеграмма, мы маленькой студией из 15 человек перешли на self hosted Mattermost. Коробочная интеграция с гитлабом, плагин для редмайна, плагин в проведения опросов в каналах. В общем горя не знаем с тех пор. Шероховатости есть, но страдать не приходится.
Тут много про это написали уже, одно важное уточнение для всех: в бесплатной версии пуши идут через их Test Push Notification Service, который не гарантирует production level uptime, но все же работает вполне прилично. Не супер надежно и нет полной гарантии приватности, но работает. Для приватности кстати там можно выключить отправку самого сообщения внутри пуша. В таком случае пуш будет сообщать только о факте нового сообщения.
Форвардинг насколько я помню действительно кривой. Переправляется не само сообщение, а ссылка на него. Соотвественно если сообщение было в приватном канале, то человек вне канала не сможет ее открыть.
1. Основная. Хотелось иметь UI для более менее гибкой конфигурации. Чтобы не вникая в API и не отслеживая изменения в нем (а ребята из Unity любят его менять) можно было добавить какой-то новый вариант билда. Чтобы любой джун, не тратя время на гугление, мог открыть настройки проекта, натыкать необходимое в них, проверить их корректность без сборки билда и сохранить этот вариант. Чтобы для понимания настроек конкретного варианта было достаточно переключиться в него и для этого не нужно было изучать чужой спагетти код (который джуны любят копипастить со стэка прям кусками). В документации юнити пример с кодом подстановки иконок под android и ios едва влезает в экран, натыкать иконки в родном UI от Unity труда не составит. Опять же PlayerSettings это код и его нужно поддерживать. А мне хочется писать код для игр, а не для их сборки.
2. Когда я пришел к такому решению, я подумал, что может быть и не лишней будет возможность конфигурирования настроек, недоступных через PlayerSettings. Например Fixed timestemp или настройки физики или инпута. Самому никогда подобного не требовалось, но вдруг гипотетически захочется и будут на то причины. Why not?
Мне самому гораздо больше нравится идея подсовывать настройки без записи на диск, это гораздо правильнее, но вот так…
Убедительно или по-прежнему не очень?)
Но в процессе написания этого комментария я понял, что лучше сделать релиз на гитхабе, который просто можно скачать вот здесь. Само окно плагина находится в Window/BuildVariants
2. Прошу прощения, я действительно по причине из п.1 не работал с cloud build. И сходу не нагуглил. Как там можно поменять иконку для конкретного билда? И там можно наследовать конфигурации друг от друга?
3. А заказчику и не нужно лезть в настройки. Проект отдается со всеми преднастроенными конфигурациями. Заказчик играется с балансом, меняет арт. А потом одной кнопкой получает все билды. И не отвлекает нас на такие мелочи.
4. Наша внутренняя инфраструктура во многом завязана на локальный gitlab, быстро и удобно. CI я хотел бы оставить там же.
5. В самом начале статьи я упомянул, что данная проблема в принципе имеет множество разных решений. Просто по своим причинам я выбрал такое. У кого-то их может и не быть. А у кого-то может. Поэтому решил поделиться. Свобода выбора вроде как.
2. А он позволяет подменять ассеты и поддерживать разные конфигурации?
3. Для аутсорсовых проектов удобнее передать все с таким вот плагином, чтобы заказчик сам легко и просто мог собирать нужные ему билды.
Вот по этим причинам хотелось весь озвученный функционал засунуть в сам проект, чтобы он был самодостаточен в т.ч. по вопросам сборки.
Процитированное вами упрощение алгоритма было сделано как раз в квантовой версии. Насколько я понял, версия Тана не уступает по качеству рекомендаций