Сидят две курицы в курятнике, одна другую спрашивает: "вот я яица несу по рубль двадцать, а ты?" Вторая ей не без гордости отвечает "А я по рубль тридцать". " И как стоит оно того ради десяти хозяйских копеек жопу рвать?".
А вообще если серьезно, то проблема низкой производительности труда она имхо проистекает и у программистов и в других отраслях от понимания что после увольнения уже завтра будет найдена работа за такие ж деньги, а может ещё и лучше. Желание впрягатся по полной у людей возникает только когда они понимают что другую такую же работу они не найдут поэтому надо держатся за эту обеими руками. Это такая стратегия оптимизации КПД усилий к профиту, иное поведенип иррационально при "рыночной" зарплате и дифиците кадров.
Плоховато описана проблематика, которую пытается решить этот подход. Бойлерплейтный однотипный код при обьявлении компонентов? Ну допустим, а чем предложенный подход лучше тех же сниппетов? Пока выглядит так что вы пытаетесь заменить один бойлерплейт другим велосипедным.
Есть анекдот такой - встречаются два друга один другому жалуется что работы нету. Второй ему говорит давай у меня работать будешь. Вот тут комната в офисе и в ней большая кнопка и телефон. Когда я буду звонить тебе по телефону ты будешь кнопку жать и все, а прибыль пополам поделим. Ударили по рукам, начали работать. Владелец звонит пару раз в день, работник кнопку жмет, так прошли недели, месяцы и начал работник задумыватся "Почему кнопку только я жму, а прибыль пополам?"
Да я вкурсе про командный буфер, в демке выше все структурные изменния так же через него происходили сотнями каждый кадр. Писать в него можно многопоточно, изменния действительно применяются в гланом потоке но это происходит очень быстро.
Ну ок если в Ваших руках он плохо скейлится остаётся только посочувствовать.
Я не знаю почему он у вас оказался медленным тут надо в код смотреть и искать где именно Вы ошиблись. Когда я писал проект в котором активно взаимодействовали (перестреливались) тысячи объектов одновременно там была просто тьма тмущая ecs-событий и создавалось/уничтожалось много сущностей каждый кадр и всё это отлично работало без тормозов даже на телефоне десятилетней давности.
В статье несколько сумбурно описана проблематика из-за чего не очень понятно во имя чего автор всё это затеял. Создание энтитей и навешивание на них компонентов десятками и сотнями каждый кадр это нормальная тема в ECS и фреймворки для таких задач хорошо оптимизированы. Плюс непонятно зачем пихать в джобы вещи которые происходит очень редко и вообще никак не аффектят перфоманс, а затем жаловаться на бойлерплейт.
Вообще для разруливания логики между объектами разных "типов" в ECS существуют фильтры. Если нам нужно например написать кастомную логику интеракшена с допустим дверью то мы заводим под это систему и пишем в ней фильтр который отбирает сущности с компонентами Door и Interacted и пишем туда свою кастомную логику, посути это и есть аналог виртуального метода. Судя по статье автор об этом знает, на этом и следовало остановится дабы остатся в рамках ecs-way.
Что касается ивентов они в ECS так же реализуются через ентити с компонентом события, который отлавливается системой в обычном порядке и обрабатываются.
В общем мотивационная часть осталась для меня загадкой, что за проблему автор пытался решить...
По поводу того, что в зенжекте много функционала я согласен, но не согласен с тем, что это плохо. Большая часть перечисленного не обязательна к использованию, но если оно понадобилось то уже под рукой готовое и протестированное на сотнях проектов.
Ну и я вцелом не согласен что лучше писать свой велосипед на любой чих потому что он комуто-там (прежде всего автору) понятен. Прелесть использования широко распространенных библиотек и фреймворков как раз в том что новый разработчик если знаком с тем же зенжектом может сразу плюс минус идти в бой, даже на относительно крупном проекте. Но нет никаких шансов нанять инженера который раньше уже катался на всех ваших велосипедах, которые вы напишете для реализации давно решенных задач.
Мне кажется стоило назвать цикл статей в духе "Отказываемся от zenject и пишем свой велосипед", оно бы лучше отражало суть написаного. Но я так и не увидел мотивационную часть, а зачем? Какие преимущества важные для данного проекта мы получили отказавшись от библиотеки, которая является в некотором смысле индустриальным стандартом di-фреймворка в юнити и написав свой велосипед? Во имя чего всё это?
Интересно, если бы энергоэффективность учитывала количество энергии затраченной мозгом для написания бенчмарков, то как бы выглядели таблицы? А если бы время было бы временем написания всех бенчмарков? Почему в исследовании языков игнорируются значимые для бизнеса свойства технологий? Тайм ту маркет, стоимость рабочей силы, обьем задач которые можно решить на условную 1000$ вложенную в зарплаты?
Не могли бы вы в следующей статье уделить больше внияния сравнению разных видов архитектур? Ладно зенжект, допустим мы не хотим тащить di-фреймворк в проект, но и без него можно композишен рут организовать, вынести модель из монобехов оставив там только представление и события движка, сервисную модель организовать и т.д. Вы как-то сходу в карьер начали мемную архитектуру на монобехах задвигать, сделайте шаг назад и объясните почему так, в чем преимущества и ограничения этого варианта (они конечно есть как и у любого решения в программировании) по сравнению с другими подходами ну хотя бы обзорно. Опять же было бы неплохо рассказать зачем вообще нужна архитектура, кубики ж можно и без неё двигать, на какие важные вопросы она должна давать ответы, где и какие профиты даёт с точки зрения разработки, где и за счёт чего экономия/ускорение разработки происходит. Ну и т.д.
Давно хотел узнать откуда вообще взялась эта приставка к HR "бизнес партнер"? Почему партнер? У них что доля в компании? Вроде такие же наемные работники как и любые другие. Почему программисты например не бизнес партнеры?
Мне кажется что если проблем на производстве небыло и люди отвечавшие за стабильность работы завода работали всего 15%, то это не проблема, а достижение прежней структуры и команды? Более того с точки зрения теории игр в этом и заключались их критерий "выигрыша" и стратегия победы - если они сделают работу качественно и все будет работать хорошо, то они будут работать меньше, а получать столько же. В новой структуре эта стратегия перестала работать. Ну а то что у эффективных менеджеров свои критерии и стратегии победы это и так понятно.
Чат.жпг создай такую картинку!
Затраты прямо пропорциональны времени проведенному разработчиками в браузерах на этих субботниках.
Спасибо, что поделились опытом. Полезная пища для размышлений.
А корень проблемы извечный в том, что коргеймплей и управление надо начинать тестировать на пользователях как можно раньше, а не через год разработки.
Странно что упомянули Вигерса но не упомянули BABOK
Сидят две курицы в курятнике, одна другую спрашивает: "вот я яица несу по рубль двадцать, а ты?" Вторая ей не без гордости отвечает "А я по рубль тридцать". " И как стоит оно того ради десяти хозяйских копеек жопу рвать?".
А вообще если серьезно, то проблема низкой производительности труда она имхо проистекает и у программистов и в других отраслях от понимания что после увольнения уже завтра будет найдена работа за такие ж деньги, а может ещё и лучше. Желание впрягатся по полной у людей возникает только когда они понимают что другую такую же работу они не найдут поэтому надо держатся за эту обеими руками. Это такая стратегия оптимизации КПД усилий к профиту, иное поведенип иррационально при "рыночной" зарплате и дифиците кадров.
Плоховато описана проблематика, которую пытается решить этот подход. Бойлерплейтный однотипный код при обьявлении компонентов? Ну допустим, а чем предложенный подход лучше тех же сниппетов? Пока выглядит так что вы пытаетесь заменить один бойлерплейт другим велосипедным.
Есть анекдот такой - встречаются два друга один другому жалуется что работы нету. Второй ему говорит давай у меня работать будешь. Вот тут комната в офисе и в ней большая кнопка и телефон. Когда я буду звонить тебе по телефону ты будешь кнопку жать и все, а прибыль пополам поделим. Ударили по рукам, начали работать. Владелец звонит пару раз в день, работник кнопку жмет, так прошли недели, месяцы и начал работник задумыватся "Почему кнопку только я жму, а прибыль пополам?"
Да я вкурсе про командный буфер, в демке выше все структурные изменния так же через него происходили сотнями каждый кадр. Писать в него можно многопоточно, изменния действительно применяются в гланом потоке но это происходит очень быстро.
Ну ок если в Ваших руках он плохо скейлится остаётся только посочувствовать.
Я не знаю почему он у вас оказался медленным тут надо в код смотреть и искать где именно Вы ошиблись. Когда я писал проект в котором активно взаимодействовали (перестреливались) тысячи объектов одновременно там была просто тьма тмущая ecs-событий и создавалось/уничтожалось много сущностей каждый кадр и всё это отлично работало без тормозов даже на телефоне десятилетней давности.
Вот можете полюбопытствовать: https://www.youtube.com/shorts/NERogo5dyoQ
Этот проект так же писался на DOTS-е причём древнющей версии, новые версии подозреваю еще производителней.
В статье несколько сумбурно описана проблематика из-за чего не очень понятно во имя чего автор всё это затеял. Создание энтитей и навешивание на них компонентов десятками и сотнями каждый кадр это нормальная тема в ECS и фреймворки для таких задач хорошо оптимизированы. Плюс непонятно зачем пихать в джобы вещи которые происходит очень редко и вообще никак не аффектят перфоманс, а затем жаловаться на бойлерплейт.
Вообще для разруливания логики между объектами разных "типов" в ECS существуют фильтры. Если нам нужно например написать кастомную логику интеракшена с допустим дверью то мы заводим под это систему и пишем в ней фильтр который отбирает сущности с компонентами Door и Interacted и пишем туда свою кастомную логику, посути это и есть аналог виртуального метода. Судя по статье автор об этом знает, на этом и следовало остановится дабы остатся в рамках ecs-way.
Что касается ивентов они в ECS так же реализуются через ентити с компонентом события, который отлавливается системой в обычном порядке и обрабатываются.
В общем мотивационная часть осталась для меня загадкой, что за проблему автор пытался решить...
По статье выглядит так что автор пытается изобрести вот эту штуку https://www.youtube.com/watch?v=raQ3iHhE_Kk
Не сказал бы что такой подход дюже популярен, но простые игры на нём делать дейсвительно можно.
По поводу того, что в зенжекте много функционала я согласен, но не согласен с тем, что это плохо. Большая часть перечисленного не обязательна к использованию, но если оно понадобилось то уже под рукой готовое и протестированное на сотнях проектов.
Ну и я вцелом не согласен что лучше писать свой велосипед на любой чих потому что он комуто-там (прежде всего автору) понятен. Прелесть использования широко распространенных библиотек и фреймворков как раз в том что новый разработчик если знаком с тем же зенжектом может сразу плюс минус идти в бой, даже на относительно крупном проекте. Но нет никаких шансов нанять инженера который раньше уже катался на всех ваших велосипедах, которые вы напишете для реализации давно решенных задач.
Управления жизненным циклом приложения и создание точки инициализации можно через бутстрап сцену сделать. Зенжект тут ничем не мешает совершенно.
Мне кажется стоило назвать цикл статей в духе "Отказываемся от zenject и пишем свой велосипед", оно бы лучше отражало суть написаного. Но я так и не увидел мотивационную часть, а зачем? Какие преимущества важные для данного проекта мы получили отказавшись от библиотеки, которая является в некотором смысле индустриальным стандартом di-фреймворка в юнити и написав свой велосипед? Во имя чего всё это?
Интересно, если бы энергоэффективность учитывала количество энергии затраченной мозгом для написания бенчмарков, то как бы выглядели таблицы? А если бы время было бы временем написания всех бенчмарков? Почему в исследовании языков игнорируются значимые для бизнеса свойства технологий? Тайм ту маркет, стоимость рабочей силы, обьем задач которые можно решить на условную 1000$ вложенную в зарплаты?
Не могли бы вы в следующей статье уделить больше внияния сравнению разных видов архитектур? Ладно зенжект, допустим мы не хотим тащить di-фреймворк в проект, но и без него можно композишен рут организовать, вынести модель из монобехов оставив там только представление и события движка, сервисную модель организовать и т.д. Вы как-то сходу в карьер начали мемную архитектуру на монобехах задвигать, сделайте шаг назад и объясните почему так, в чем преимущества и ограничения этого варианта (они конечно есть как и у любого решения в программировании) по сравнению с другими подходами ну хотя бы обзорно. Опять же было бы неплохо рассказать зачем вообще нужна архитектура, кубики ж можно и без неё двигать, на какие важные вопросы она должна давать ответы, где и какие профиты даёт с точки зрения разработки, где и за счёт чего экономия/ускорение разработки происходит. Ну и т.д.
Давно хотел узнать откуда вообще взялась эта приставка к HR "бизнес партнер"? Почему партнер? У них что доля в компании? Вроде такие же наемные работники как и любые другие. Почему программисты например не бизнес партнеры?
Учись чат.жпг, а то так и будешь всю жизнь ключи подавать!
Мне кажется что если проблем на производстве небыло и люди отвечавшие за стабильность работы завода работали всего 15%, то это не проблема, а достижение прежней структуры и команды? Более того с точки зрения теории игр в этом и заключались их критерий "выигрыша" и стратегия победы - если они сделают работу качественно и все будет работать хорошо, то они будут работать меньше, а получать столько же. В новой структуре эта стратегия перестала работать. Ну а то что у эффективных менеджеров свои критерии и стратегии победы это и так понятно.