Мы все паки качаем в отдельный проект и мигрируем только то, что нужно. Исключение составляют паки, которые используются в нескольких новых локациях, которые собираются левел-дизайнером из того, что есть в паке. Потом просто отдельно чистим.
Насчет миграции в отдельную папку да, любопытный способ. Правда из-за того, что старая папка удаляется, нет возможности потом отдельно доперенести ассеты, которые не захватила основная миграция.
Например в нашем проекте есть куча дата-ассетов, которые никак не референсятся. И их анриал считает за тех, что не используются. На деле же они чуть ли не основу нашего мета-геймплея составляют. Такие вещи, пришлось бы отдельно мигрировать.
Впрочем, мы сами никогда миграцией не пользуемся. Нам проще прочистить проект другими двумя способами.
В 4.26 в UObject нет переменной bReplicates. Возможно, её не было и раньше и это ошибка в статье. Не помню точно.
На текущий момент в самом UObject ничего подобного не нужно дописывать, достаточно записать bReplicates = true в Актор и/или SetIsReplicatedByDefault(true) в Компонент, который реплицирует Object'ы
Далеко не всегда понятна эффективность трекинга времени по часам при разработке.
Лично я не приверженец трекинга по часам по следующим причинам:
1) Нужны лишние телодвижения, что бы вбить время. Не всем это нравится или просто забывается.
2) Иногда это давит, и кажется, что ты в заложниках какой-то бюрократической системы.
3) Трекинг никак не защищает от обмана. Разработчик может проставить 8 часов, но на деле работать 5 часов. Такое даже путать лидов может.
4) Трекинг времени в разработке не подходит для аналитики выполнения конкретных задач. Во первых, в следующий раз разработчик сделает туже задачу быстрее или даже скопипастит готовые участки. Во вторых, новые задачи нельзя оценивать с расчетом на прошлый трекинг времени, так как задача другая, проблемы неизвестны и так далее. Менеджеров собьет с толку, а разработчик все равно поставит эстимейт основываясь на личном опыте.
На мой взгляд лучше трекать спринты, эпики, релизы и т.п., выявляя слабые стороны разработчиков на среднесроке и долгосроке. Понимать, где эстимейты и сроки были упущены, по каким причинам и так далее. Так же среднесрочный трекинг времени позволяет лучше планировать риски. Например планировать возможность заболевания разработчика или же запас времени на баги не получится при краткосрочном планировании. Только при планировании на чуть большие куски работы.
При этом есть минус. Лиду или ПМу нужно тратить отдельно время на анализ спринтов и релизов.
А вот трекинг времени по часам для всяких художников, UI дизайнеров и прочим людям, чья задача может различаться, но процесс и время выполнения примерно одно и тоже. Например задизайнить окошко длится 10 часов. При этом не важно, что за окошко, оно всегда у человека выходит +- 10 часов. ПМу тогда не нужно уже спрашивать, сколько это займет, он сам может спланировать 10 часов на будущие окошки.
В остальном я не понимаю цель трекинга по часам. Считаю это каким-то пережитком прошлого.
1 2 3 — универ. 4 5 6 — сами, 7 8 — курсы. Оставшиеся двое могли заниматься с преподавателем или вообще не учились на IT, а попали, как написано выше, случайно.
Смотрю на своих коллег в офисе, смотрю на своих знакомых коллег… все уже переступили эту вилку.
Очень сильно зависит от области. Например у нас в Геймдеве действительно все молодые, чем, скажем, в банках или типо того. Но вообще согласен, стата не совсем точная. Либо это из-за малой выборки, либо же молодое поколение и области с низким порогом входа размыло эту стату.
30-40% берут издатели, которые занимаются сообществом, маркетингом, юридическими аспектами, подготовкой к релизу, иногда технической поддержкой и предоставляют сервера. Эти проценты обоснованы.
У эпла же 30% просто за проведение платежей… Ну это звучит как выбор без выбора.
Apple может сосредоточить свои силы на улучшении качества и увеличении количества программных продуктов, привлекая все новых разработчиков.
Кажется там итак уже все, кому это нужно :) Если вы делаете мобильную игру, вам нет смысла не выпускаться в AppStore, так как оттуда идет 70% выручки. Примерно тоже самое и с приложениями. Так что с точки зрения бизнеса, они ничего не выйграют, если позволят проводить сторонние платежи.
С другой стороны, на дворе 21.2 й век, давно пора сделать динамическое роялти в зависимости от того, что разработчик использует. Например я не использую TestFlight, даю тестировать напрямую, эппл не дает мне фичер (как стим), сам эпл не способствует продвижению приложения и оно теряется в поиске. Эппл не дает мне аналитику (пользуюсь сторонней, слава богу это можно). В общем-то, эпл дает мне только плащадку для загрузки и сервис для платежей.
Кажется, что за такое они должны брать не больше 10%, так как ради увеличения своей прибыли я должен делать все сам. Но вот если бы я все это использовал, и они давали фичер-пулл, то вот тогда я вообще не против заплатить 30%.
Мы и сами работаем на ПК, однако у нас CI стоит на мак-миниках, и мы собираем С++ проекты. Более того, там так же есть сишарповские генераторы.
Все это от движка, и, по правде говоря, вглудь я не лез. Однако неизвестно, будет ли это все работать…
Мне так же интересно, будет ли вообще поддерживаться старая архитектура в плане сборки. Условно говоря, если и за 2 года перейдут на новую архитектуру, то ещё годика 3-4 мы сможем собирать на старых миниках. Если все так, то в целом это все не так сртрашно.
Мне больше интересно, что будет с инструментами разработчиков, особенно игр. Например Unity или Unreal Engine. В частности речь идет о редакторах, средах сборки и прочим.
Может ли такой резкий переход означать, что первое время некоторые инструменты станут попросту недоступны или сильно затруднительны? Например малоизвестные движки или компоненты Android SDK, заточенные под определенную архитектуру.
По правде говоря, такой способ даже для тестов не сильно-то годиться. Куда удобнее использовать CI, зайти в браузере на страничку и нажать Build. Билд скачать сразу с нужного девайса минут через 5, чем грузить его вручную на телефон с ПК через провод. Особенно когда должно протестить игру сразу несколько человек.
Мы используем Мак-миник с Jenkins. Собираем на нем сразу Android и iOS. Удаленную сборку не использовали никогда, так как для разных платформ получаются разные пайплайны. А так все быстренько и удобно. Если не используете, очень советую.
Единственное, настроить сервер и сборку Unreal Engine таким образом небольшой гемор, но это один раз, когда не знаешь, что делать.
Нужно убрать «влюбить клиента в пилотную версию продукта» из топика. Половина статьи о картинках, другая о том, как выбрать фичи. А по топику думаешь, что будет что-нибудь про дизайн MVP продукта или как его позиционировать…
Я бы предложил написать о том, как готовить MVP, как его тестировать и анализировать, где искать ЦА и тестировщиков. И все в таком духе. Куда полезнее обсуждений о неправильности картинок.
В качестве плюсов, вероятно, стоит упомянуть лучшее использование памяти, так как при обработке системой нужных компонентов, вы не тяните за собой ненужные данные, что уменьшает вероятность, например, промахов кеша.
Тем не менее, в конкретно вашем примере, вы обрабатываете Entity целиком, когда нужно обрабатывать только сами компоненты, иначе вы не получаете такого преимущества и выполнение становится медленнее. Да и тестирование становится чуть сложнее, так как для этого вам приходится все равно создавать и тянуть ещё и Entity, но при этом не так очевидно, так как на вход подаются не компоненты, из-за чего мы не знаем, что именно необходимо для тестирования.
Хотя у меня не так много глубоких знаний по ECS или я что-то не правильно растолковал, могу ошибаться. Жду комментов по этому поводу.
Блупринты, обычно, просто мерджатся, так же, как и код.
А вот с остальными ассетами проблемнее. Если работать через Гит, то лучше просто договориться, что бы люди не работали над, скажем, одними и теми же картами.
Если стоит другая система контроля версий, то легче просто лочить файлы.
Предполагаю, что перед тем, как задуматься об этой теме, стоит задуматься и о негативных последствиях продления жизни для всего человечества в общем.
Из примеров, которые с определенной вероятностью(!) возможны:
проблема перенаселения и вытекающие проблемы из этого;
финансовые и экономические проблемы в том случае, если средство против старения окажется труднодоступным;
этические проблемы связанные с тем, что человек в какой-то момент передумал жить долго
Ну и так далее…
Мы все паки качаем в отдельный проект и мигрируем только то, что нужно. Исключение составляют паки, которые используются в нескольких новых локациях, которые собираются левел-дизайнером из того, что есть в паке. Потом просто отдельно чистим.
Насчет миграции в отдельную папку да, любопытный способ. Правда из-за того, что старая папка удаляется, нет возможности потом отдельно доперенести ассеты, которые не захватила основная миграция.
Например в нашем проекте есть куча дата-ассетов, которые никак не референсятся. И их анриал считает за тех, что не используются. На деле же они чуть ли не основу нашего мета-геймплея составляют. Такие вещи, пришлось бы отдельно мигрировать.
Впрочем, мы сами никогда миграцией не пользуемся. Нам проще прочистить проект другими двумя способами.
В 4.26 в UObject нет переменной bReplicates. Возможно, её не было и раньше и это ошибка в статье. Не помню точно.
На текущий момент в самом UObject ничего подобного не нужно дописывать, достаточно записать bReplicates = true в Актор и/или SetIsReplicatedByDefault(true) в Компонент, который реплицирует Object'ы
Лично я не приверженец трекинга по часам по следующим причинам:
1) Нужны лишние телодвижения, что бы вбить время. Не всем это нравится или просто забывается.
2) Иногда это давит, и кажется, что ты в заложниках какой-то бюрократической системы.
3) Трекинг никак не защищает от обмана. Разработчик может проставить 8 часов, но на деле работать 5 часов. Такое даже путать лидов может.
4) Трекинг времени в разработке не подходит для аналитики выполнения конкретных задач. Во первых, в следующий раз разработчик сделает туже задачу быстрее или даже скопипастит готовые участки. Во вторых, новые задачи нельзя оценивать с расчетом на прошлый трекинг времени, так как задача другая, проблемы неизвестны и так далее. Менеджеров собьет с толку, а разработчик все равно поставит эстимейт основываясь на личном опыте.
На мой взгляд лучше трекать спринты, эпики, релизы и т.п., выявляя слабые стороны разработчиков на среднесроке и долгосроке. Понимать, где эстимейты и сроки были упущены, по каким причинам и так далее. Так же среднесрочный трекинг времени позволяет лучше планировать риски. Например планировать возможность заболевания разработчика или же запас времени на баги не получится при краткосрочном планировании. Только при планировании на чуть большие куски работы.
При этом есть минус. Лиду или ПМу нужно тратить отдельно время на анализ спринтов и релизов.
А вот трекинг времени по часам для всяких художников, UI дизайнеров и прочим людям, чья задача может различаться, но процесс и время выполнения примерно одно и тоже. Например задизайнить окошко длится 10 часов. При этом не важно, что за окошко, оно всегда у человека выходит +- 10 часов. ПМу тогда не нужно уже спрашивать, сколько это займет, он сам может спланировать 10 часов на будущие окошки.
В остальном я не понимаю цель трекинга по часам. Считаю это каким-то пережитком прошлого.
1 2 3 — универ. 4 5 6 — сами, 7 8 — курсы. Оставшиеся двое могли заниматься с преподавателем или вообще не учились на IT, а попали, как написано выше, случайно.
Очень сильно зависит от области. Например у нас в Геймдеве действительно все молодые, чем, скажем, в банках или типо того. Но вообще согласен, стата не совсем точная. Либо это из-за малой выборки, либо же молодое поколение и области с низким порогом входа размыло эту стату.
У эпла же 30% просто за проведение платежей… Ну это звучит как выбор без выбора.
Кажется там итак уже все, кому это нужно :) Если вы делаете мобильную игру, вам нет смысла не выпускаться в AppStore, так как оттуда идет 70% выручки. Примерно тоже самое и с приложениями. Так что с точки зрения бизнеса, они ничего не выйграют, если позволят проводить сторонние платежи.
С другой стороны, на дворе 21.2 й век, давно пора сделать динамическое роялти в зависимости от того, что разработчик использует. Например я не использую TestFlight, даю тестировать напрямую, эппл не дает мне фичер (как стим), сам эпл не способствует продвижению приложения и оно теряется в поиске. Эппл не дает мне аналитику (пользуюсь сторонней, слава богу это можно). В общем-то, эпл дает мне только плащадку для загрузки и сервис для платежей.
Кажется, что за такое они должны брать не больше 10%, так как ради увеличения своей прибыли я должен делать все сам. Но вот если бы я все это использовал, и они давали фичер-пулл, то вот тогда я вообще не против заплатить 30%.
Все это от движка, и, по правде говоря, вглудь я не лез. Однако неизвестно, будет ли это все работать…
Мне так же интересно, будет ли вообще поддерживаться старая архитектура в плане сборки. Условно говоря, если и за 2 года перейдут на новую архитектуру, то ещё годика 3-4 мы сможем собирать на старых миниках. Если все так, то в целом это все не так сртрашно.
Может ли такой резкий переход означать, что первое время некоторые инструменты станут попросту недоступны или сильно затруднительны? Например малоизвестные движки или компоненты Android SDK, заточенные под определенную архитектуру.
Мы используем Мак-миник с Jenkins. Собираем на нем сразу Android и iOS. Удаленную сборку не использовали никогда, так как для разных платформ получаются разные пайплайны. А так все быстренько и удобно. Если не используете, очень советую.
Единственное, настроить сервер и сборку Unreal Engine таким образом небольшой гемор, но это один раз, когда не знаешь, что делать.
Я бы предложил написать о том, как готовить MVP, как его тестировать и анализировать, где искать ЦА и тестировщиков. И все в таком духе. Куда полезнее обсуждений о неправильности картинок.
В качестве плюсов, вероятно, стоит упомянуть лучшее использование памяти, так как при обработке системой нужных компонентов, вы не тяните за собой ненужные данные, что уменьшает вероятность, например, промахов кеша.
Тем не менее, в конкретно вашем примере, вы обрабатываете Entity целиком, когда нужно обрабатывать только сами компоненты, иначе вы не получаете такого преимущества и выполнение становится медленнее. Да и тестирование становится чуть сложнее, так как для этого вам приходится все равно создавать и тянуть ещё и Entity, но при этом не так очевидно, так как на вход подаются не компоненты, из-за чего мы не знаем, что именно необходимо для тестирования.
Хотя у меня не так много глубоких знаний по ECS или я что-то не правильно растолковал, могу ошибаться. Жду комментов по этому поводу.
Конечно не забывайте проверить на то, что каст прошел.
Действительно, в 4.23 изменили кое что.
Убран параметр void* Parameters
В остальном нужно смотреть, что у вас за ошибки.
А вот с остальными ассетами проблемнее. Если работать через Гит, то лучше просто договориться, что бы люди не работали над, скажем, одними и теми же картами.
Если стоит другая система контроля версий, то легче просто лочить файлы.
Из примеров, которые с определенной вероятностью(!) возможны:
проблема перенаселения и вытекающие проблемы из этого;
финансовые и экономические проблемы в том случае, если средство против старения окажется труднодоступным;
этические проблемы связанные с тем, что человек в какой-то момент передумал жить долго
Ну и так далее…