> В один момент я почти поверил в то, что никто не использует удалённую сборку, или это что-то элементарное, но именно отсутствие внятной документации и немногочисленные статьи с устаревшей информацией и вынудили меня написать этот материал, который, надеюсь, поможет читателям оптимизировать процесс сборки кросс-платформенных приложений.
1. Во-первых, совершенно незачем использовать ручную конфигурацию rsync'а, когда достаточно дать remote control для юзера. См. docs.unrealengine.com/en-US/Platforms/Mobile/iOS/Windows/index.html, конфигурация для удаленной сборки уже давно превратилась в «пройди по доке и все работает».
2. Описанный вариант это НЕ оптимальный вариант :) Да, никто (ок, 99%) не использует удаленную сборку таким образом для целей продакшна. Это костыль, оставшийся от UE3 и нужный скорее для экспериментов и проектов с минимумом C++ кода, который как бы есть, но время его сборки — незначительно.
Потому что:
— если тебе нужно дебажить и профайлить билд: ты идешь к маку и аттачишься к нему через Xcode
— если тебе нужен билд на «поиграть/потестить» или «на релиз»: ты делаешь сборку через CI/CD и получаешь либо ипашку, либо апдейт в файрбейзе/аппцентре.
Более того, remote build:
— не собирает шейдаки в бинари, они идут в текстовом виде
— у него нет инкрементальной компиляции, полная пересборка every time
— не поддерживает сборку плагинов или проектов, использующие статик либы (никаких «ашек»)
Т.е. такой билд не предназначен ни для дебага, ни отладки, ни релиза.
В любом случае, статье плюсик, как минимум это пример альтернативной конфигурации и настройки rsync'а, что бывает полезно :)
Каким бы простым код не был в чтении, он должен быть покрыт тестами
… или как отличить веб-программиста от не веб. Покрытие тестами — возможно на практике лишь в небольшом количестве областей практического применения, но почему-то часто трактуется как икона «тесты обязательны» :)
Как пользователь — я, если честно, в ужасе, если это то, что привело к такому вот обсуждению и статье. Особенно доставил горизонтальный свайп на три экрана.
Надо сказать описана прям классическая ситуация «как делать не надо», характерная во многом именно для нашего рынка: три менеджера «лезущих в кнопки» и дизайнер. Уволили дизайнера, сделаем сами. Ыть!
В первую очередь — вы делаете продукт весьма технического назначения, задача которого — удобно и наглядно отобразить информацию для пользователя.
Увы, нет. Количество багов, костылей и «особенностей» с этим связанных — зашкаливает. В последней версии стало лучше (наконец-то перестали теряться ключи), но путь к этому был полон боли.
О, самое страшное, что я видел в Фигме — дизайн интерфейса для компьютерной игры и внутриигрового магазина. Я не знаю каким молотком надо втолковывать, что большинство свистоперделок «для веба» не катят и не поддерживаются почти нигде кроме веба :)
Программирование в подавляющем числе случаев — это нифига не алгоритмы, а решение прикладных задач. Поэтому наше образование «по матчасти» даёт хорошие результаты в исключительных случаях (олимпиадники и так далее), но в среднем — так себе.
И уж особенно если говорить про школу — этот Паскаль и иже с ними настолько далеки от реальности, что обьяснить ребёнку зачем оно надо (соответсвенно и мотивировать) — это уже даже задача вторая. Первая — не отбить желание на старте, используя допотопный и не нужный стек технологий, который без шаманизма даже и не запустишь.
Плагин звучит очень здорово, нет ли планов сделать его общедоступным? :) (т.к. проблема близка, идея примерно такая же, только приходится делать это всё ручками)
пысы. Есть доступный ресурс с хоть сколько детальными пайплайнами/процессами по разработке или напрямую разработке в UE?
На самом деле многое описано в официальной документации. Если же речь про артовый пайплайн, то он по большому счёту от движка не зависит, и можно читать любые материалы.
1. GetAllActorsOfClass стоит воспринимать как табу для всего, что имеет хоть какой-то период, отличный от «пару раз за игру».
2. Прежде чем кидать дорогие большие капсульные трейсы, было бы неплохо определить, а персонаж вообще есть на экране в теории?
3. Кидание капсулы мало того, что дорогое, но и будет давать артефакты по скрытию предметов близко к камере, что в случае, например, FPS, будет печальным. Может стоило обойтись трейсами в некие реперные точки?
P.S. — если вы пишете под анриал, использовать не-ue4 кодестайл — призрак дурного тона.
Я бы назвал ваше решение несколько, гм, не оптимальным. Или даже примером «как делать не надо». Даже простой трейс из камеры вперёд был бы на порядок (или два) легче, давая в общем-то тот же самый результат. Зачем вы перебираете объекты в принципе? :(
Другая физическая модель, другая архитектура. Мы не ставили задачи создать «компонент широкого пользования для физических моделек», у нас вполне себе выверенное решение конкретных целей, с кучей шишек, набитых продом :)
> В один момент я почти поверил в то, что никто не использует удалённую сборку, или это что-то элементарное, но именно отсутствие внятной документации и немногочисленные статьи с устаревшей информацией и вынудили меня написать этот материал, который, надеюсь, поможет читателям оптимизировать процесс сборки кросс-платформенных приложений.
1. Во-первых, совершенно незачем использовать ручную конфигурацию rsync'а, когда достаточно дать remote control для юзера. См. docs.unrealengine.com/en-US/Platforms/Mobile/iOS/Windows/index.html, конфигурация для удаленной сборки уже давно превратилась в «пройди по доке и все работает».
2. Описанный вариант это НЕ оптимальный вариант :) Да, никто (ок, 99%) не использует удаленную сборку таким образом для целей продакшна. Это костыль, оставшийся от UE3 и нужный скорее для экспериментов и проектов с минимумом C++ кода, который как бы есть, но время его сборки — незначительно.
Потому что:
— если тебе нужно дебажить и профайлить билд: ты идешь к маку и аттачишься к нему через Xcode
— если тебе нужен билд на «поиграть/потестить» или «на релиз»: ты делаешь сборку через CI/CD и получаешь либо ипашку, либо апдейт в файрбейзе/аппцентре.
Более того, remote build:
— не собирает шейдаки в бинари, они идут в текстовом виде
— у него нет инкрементальной компиляции, полная пересборка every time
— не поддерживает сборку плагинов или проектов, использующие статик либы (никаких «ашек»)
Т.е. такой билд не предназначен ни для дебага, ни отладки, ни релиза.
В любом случае, статье плюсик, как минимум это пример альтернативной конфигурации и настройки rsync'а, что бывает полезно :)
… или как отличить веб-программиста от не веб. Покрытие тестами — возможно на практике лишь в небольшом количестве областей практического применения, но почему-то часто трактуется как икона «тесты обязательны» :)
Надо сказать описана прям классическая ситуация «как делать не надо», характерная во многом именно для нашего рынка: три менеджера «лезущих в кнопки» и дизайнер. Уволили дизайнера, сделаем сами. Ыть!
В первую очередь — вы делаете продукт весьма технического назначения, задача которого — удобно и наглядно отобразить информацию для пользователя.
Увы, нет. Количество багов, костылей и «особенностей» с этим связанных — зашкаливает. В последней версии стало лучше (наконец-то перестали теряться ключи), но путь к этому был полон боли.
Всё, что мы хотели знать об оптимизации, но боялись спросить
И уж особенно если говорить про школу — этот Паскаль и иже с ними настолько далеки от реальности, что обьяснить ребёнку зачем оно надо (соответсвенно и мотивировать) — это уже даже задача вторая. Первая — не отбить желание на старте, используя допотопный и не нужный стек технологий, который без шаманизма даже и не запустишь.
На самом деле многое описано в официальной документации. Если же речь про артовый пайплайн, то он по большому счёту от движка не зависит, и можно читать любые материалы.
2. Прежде чем кидать дорогие большие капсульные трейсы, было бы неплохо определить, а персонаж вообще есть на экране в теории?
3. Кидание капсулы мало того, что дорогое, но и будет давать артефакты по скрытию предметов близко к камере, что в случае, например, FPS, будет печальным. Может стоило обойтись трейсами в некие реперные точки?
P.S. — если вы пишете под анриал, использовать не-ue4 кодестайл — призрак дурного тона.