Потому как бухгалтеров заменяют программы(программисты). То же касается многих других проф. Сколько надо было раньше бухгалтеров, а сколько сейчас? Они всё ещё нужны, т.к. местами тормозит прогресс налоговая(через банки). Переводы, консультанты, продаваны - уже. Остаются только особые вещи, типа откатов - тут живой продаван нужен. Гиды и курьеры - тут шасси нужно, ну и это делается. Склады - то же что с бухгалтерами.
А вот врача, учителя и т.д. - тут тормозит инерция мышления, требования коммуникации и правовые последствия. Примерно то же же не даёт в области права применять ИИ. Но есть, например, архитектура. Что там по ИИ? А те же проблемы, что и с 3D, и с 2D картинками. Сделать можно, даже красиво, но доработать до качества - нет. Местами в этих секторах уже прошли путь от повсеместного использования ИИ, затем перешли к ИИ и доработке, а потом уже дошли до такого же отказа от него - потому как ИИ выходит дороже и менее качественно, т.к. всё равно требует качественного спеца и не делает это итеративно.
Если вы видите, что ИИ где-то не применяют, то это не оттого, что это ещё не пробовали. А оттого, что это пока что ни у кого не получилось или уже отчасти сделано, но вы не в теме
Благо у продавцов есть начальник и если всё же хакните, их решения так же отменят
Вот ни разу. Если договор уже составлен, то отменить его будет совсем не простой задачей, даже если по нему тебе за товар сама компания должна платить. А в более адекватных пределах и вовсе невозможно без дачи взятки
Пока никак не регулируется ИИ, отвечает за всё что скажет ИИ тот кто его допустил к клиентам(считай, составлению договоров, лечению и т.д.). Это такой же предпринимательский и прочий риск как и любой другой
Старфилд может и не так фатально тормозит, но жрёт ресурсы и тормозит очень даже сильно на новом железе среднего ценового сегмента(5060 и тд). И совсем не в 4к и 120 фреймрейта, даже и не на максималках. При том, графика не сказать что прям хороша в большей части игры
Разве что хорошо форматирует. Красиво) Но логика строится на тех задачах, что уже были где-то найдены. Однако, ошибается постоянно. Последнее что делал - задача по физике для 9 класса, нужно посчитать силу действующую на 2 опоры и балку на них висящую, с учётом выхода балки за 1 из опор. Пока решается в лоб - всё ок. Решить другим способом? Ни за что. Когда добавил момент, что часть балки имеет нулевой или иной вес, то решить не может, вообще никак. Хотя, с ~50 раза получилось добиться правильного выполнения, но для этого пришлось расписать алгоритм целиком и очень подробно. Nолько тогда ИИшка смогла повторить его. Но что если чуть поменять условия? Опять по новой) То же со старыми либами или новыми. Поменялась работа - они ничего сделать не могут. О старых, похоже, просто нет примеров использования. Вот для того, чтобы причесать код можно использовать
<< Просто «километр оптики» — это не только бухта кабеля. Это еще и землеотвод и опоры>> Вот вообще нет. НА текущие опоры кладут часто, или роют, или через канал. В общем способов уйма. А отдельные опоры чтобы ставили - не видел ни разу. Землеотвод дорогой там тоже не нужен - места полно, как правило, и мб вообще уже есть куда приткнуться. За рубль, если вообще нужно.
Вот как раз недавно было, тарифы около 1к., клиентов считают заранее, оборудование в довесок за 3к-5к надо докупить + первичный взнос не малый. В сёлах же дворов может быть и более 1к. Но в данном случае было около сотни, а тащить надо было от соседней деревни в 5-10км.
Я работал в компании с такими вот штуками. Там задачи так ставили, + критерии для QA. В результате весь промпт разрабы игнорили. Он был до омерзения полон не технических деталей, процентов на 70, 15% были отсебятиной и 15% изначального запроса
Это почти чистый галлюциноген ИИ по нормативке, который формально можно сделать, но это увеличит срок разработки в несколько раз
Так же пытались ТЗ от аналитиков сделать, структуру составили, пытались как-то наполнить и т.д. И выглядело это очень хорошо и похоже на правду со стороны(директорат был в восторге похоже). Но на деле было то же самое, что и выше писал. Только в большом тексте заметить это было на много сложнее, потому как текст внешне не противоречив, понятен, +схемки какие-то, даже с виду логически верные. Но чуть подумаешь и опытному человеку сразу видно, что это чушь
Я в геймдеве писал именно полноценные модели, которые держали весь код БЛ. Ни 1 класса на 10 к строк кода ни разу не было. Даже на 1к были только очень редкие специализированные классы, например, обработчики матриц и векторов, что обязательно надо делать в 1 методе, из-за чего они были весьма длинные и тяжёлые. А БЛ в геймдеве обычно много сложнее чем на любом беке сайтов, что я видел.
При этом не делал впадая в другую крайность - отдельный класс на каждый чих. Впрочем, как и тут в команду логику я не выносил) Грамотно спроектировать участвующие сущности в классы, да и всё.
Про кучу зависимостей - часто видел как раз с контроллерами. Там на входе using или import на десятки строк норма, а в некоторых и больше ста встречал. Разделение же по логике требует высокий уровень понимания разделения ответственности, но даёт минимум сторонних зависимостей
Ну, справедливости ради, VRS можно было самому прописать. Нвидиа говорит о крайне малом применении, и то практически всегда только VR игры, так что не велика потеря. От какой там индустрии отставание? Хотя оно есть, но явно не в таком виде
В прочих движках часто доступ к DX прямой, т.е. фактически это просто перекладывание, а не реализация абстраций.
А вообще интересно, какие, например, проблемы? Я не копался очень глубоко, и пока не замечал таких проблем асинхронностью. Однако, юнька и не позволяет её кастомизировать, только использовать как есть, подстраиваясь под движок. А если идти ещё дальше, то тут уже точки синхронизации упираешься, которые в юньке не полностью управляемы. Но до такого я ни разу не доходил ещё. В последнее встречал только что графику делали как придётся, заботясь об оптимизации в последний момент(
" самым спорным практикам ООП, когда данные и код связываются вместе" Это как раз не спорно) Это логично - код исполнения и сигнатура данных вместе, т.к. код работает именно с ними, а вместе они и дают самостоятельный объект. А вот разделять их тот ещё мазохизм. Зачем, если потом обрабатывать всё равно будешь эти же данные? Нет, не просто разложили, а именно что перекомпоновали и выделили участвующие объекты, сделали классификацию, чем разграничили ответственность. Логика уже была разложена по папочкам, проект делали не новички без опыта. Только в такой структуре уже нужны были папочки для папочек) Что и делали. Из-за чего были дубли логики, а некоторая логика имела привычку делать 100500 проверок, которые повторялись для многих элементов.
Паттерны - инструмент для недоучек. Когда нужно быстро подготовить программиста. А инструмент применять надо к месту, для этого должен быть старший, что будет вести.
Переход на SSD и внедрение DirectStorage изменили подход к загрузке данных: исчезли традиционные экраны загрузки, ассеты подгружаются быстрее, миры стали более цельными...
Основное узкое место таковой загрузки - оперативная память, а не SSD. Ну и сама реализация программно - управление памятью. + это не везде работает, поэтому нельзя делать только для такой конфигурации. И такой чушью вся статья заполнена. Как обзор маркетинга от компаний индустрии.
По движкам то же самое. Про анрил толком не скажу, не в курсе как он развивался. А вот Unity упоролась в другую, т.е. отличную от привычной COP(OOP) парадигму, которая позволяет управлять тысячами объектов не разбираясь в особенностях работы языка программирования - DOTS(DataOP). И потеряла на это больше 5 лет. И cделала это крайне плохо - применимость плохая, а сложность поддержки высокая. Условно, 1 строчка на старом варианте превращается в 3 с DOTS. Имхо, в маркетинг этой идеи влито больше на порядки, чем бюджеты игр выпущенных на этой всё ещё сырой технологии. А сейчас по факту вынуждена поддерживать, считай, 2 движка, а не 1.
Дорожает т.к. нужно делать что-то новые, приносить новый опыт. На деле игры очень сильно развиваются, именно они долгое время двигали прогресс. И суть тут в том, что сделать просто как раньше уже мало. А это всегда новая разработка. Анрил из коробки или Юнька - ничего не умеют. RT пока ещё идёт как опция, поэтому по факту надо делать 2 вида освещения. Там ещё путают RT и люмен. Да и RT не подходит там, где нужна высокая кинематографичность, т.е. прямое управление освещением, а не реалистичное.
Нанит вот хз. Но сразу же он имеет кучу ограничений, т.е. не везде применим и имеет особенности работы, т.е. это не просто загрузил без лодов и всё хорошо. У меня есть большие сомнения, что он делает в статике картинку так же эффективно как LOD, и скорее всего он всегда требует выскопроизводительной карты даже для небольшого экрана и невысокой частоты кадров(при повсеместном использовании) .Т.е. это скорее инструмент для, например, зданий. Которые надо отобразить и за километр, так постепенно пока не зайдёшь внутрь.
PS: статья лажа, имхо от того, кто вообще не в теме, т.е. гпт + обработка мб
Эта картинка ложная. Так невозможно разместить клавиатуру. Локти удобнее не под 90, а чуть больше. Хз, может быть под 90 тоже можно, но тогда клавиатура должна быть прям у живота, на высоте подлокотников и стола, т.е. ровно в них. Либо, если плечи не ровно вертикально, то уже не удобно держать руку, она будет в напряжении.
Вот эти все прямые углы от ОКР-щика какого, похоже. Длительное нахождение в таком виде - это прямой путь к куче заболеваний. Человек не такой ровный. И нагрузка как раз в таких положениях не распределяется по разным частям тела, а наоборот, заставляет напрячься.
PS: отдельно отмечу хорошо показанную точку нижнего отдела спины)
Тут вопрос чем именно ломается. Изменение в логических операторах или последовательностях всё же много чаще, чем изменение принципов. А это как раз ломает уже построенную архитектуру ECS. И такое изменение может потребовать проработки всей группы из-за высокой связности. Тут уже писал, имхо, ECS хорош как раз там, где такой сложной логики нет, а классификация вообще не требует последовательного выполнения. Но не редко сложная логика в таком виде приводит к дополнительным вычислениям и данным, дабы реализовать те же условия логики как часть данных.
Так, многие и про *-варианты не слышали) Тут знать терминологию не надо, чтобы понять суть. А она вообще в другом
Любая новая когнитивная деятельность поначалу неудобна) ECS так же поначалу часто неудобен почти для всех, не важно что там с ООП. Да даже само по себе программирование то ещё неудобство)
В таких вещах хорошо смотреть как удобно это читается, чинится, изменяется. И вот в первых двух неудобств у ООП нет вовсе. Изменения посложнее, но если не требуют перепроектирования, то так же крайне просты. И, что не маловажно, изменения совпадают с дизайном(ТЗ) большинства людей.
Это не пример выжившего лётчика, а как раз вполне обыденный. Если убрать шелуху, которую присваивают постфактум людям, то можно заметить, что как раз выбивающиеся из правил двигают что-то в мире, в т.ч. науку. А из "отличников" % таких людей ни чуть не отличается, хотя у них часто куда лучше среднего стартовые возможности и доступ к лучшему образованию.
Там выше человек писал, о том как было бы замечательно провести сегрегацию людей по школьным знаниям. Принудительно
Когда у тебя объекты из РПГ, где каждый имеет свою особую логику, то легко увидеть, что SIMD работает на 1-2 объектах, а дополнительные цепочки вызовов функций на порядок больше, потому как создаётся огромное кол-во классов с ~1 логическим действием.
Про критику не соглашусь. В некоторых случаях порядок не важен и так можно выстраивать архитектуру - это лучший способ. Но так не всегда получается, и тогда нужно иметь чёткий порядок. А если не получается в условиях типа case в ООП, то нужно вводить дополнительные переменные и делать лишний прогон. Да и в целом, как задать порядок в сложной логике, которая описывается несколькими документами? Я тут не на столько компетентен, но сейчас подозреваю, что лучше вводить булевы переменные для таких случаев, а не контролировать порядок явно. А это падение производительности, но сильное упрощение проектирования.
О какой эффективности проходов по данным говорить, если контроллер требует действий над 1-10 объектами? Тут не то, что SIMD, тут вообще такое выполнение убивает эффективность использования кеша проца, и особенно предсказаний. А где прям много объектов, ну хотя бы 1к+, выигрыш действительно существенный. Но много ли таких ситуаций? До ECS такое решали просто - массивчик, проход по нему внутри цикла. И тот же SIMD можно обеспечить. Хранить и пользоваться такими данными сложно, но часто это конечная логика для C# кода, так что можно было и без ECS запустить 10к юнитов с анимацией на Unity PC. Схожим образом, например, работают(или работали) партиклы.
Про "гибко и безопасно управлять логикой" вообще мимо. Именно с логикой(условиями), у ECS прям проблемно. Перелопатить кучу данных - это да, легко. А вот управление логикой разбивается на кучу частей, которые могут очень неожиданно отработать. Фрагментация логики приводит к неожиданному поведению систем в целом. Что уж, порой без некоторых новых инструментов отладки это было вообще не реально. Хотя иногда это даже в плюс, но не когда требуется чёткое поведение. И тем более, не когда читаешь код и тебе человеки говорят о баге, а ты ещё и не знаешь с сотню систем которые затрагивают это место.
По мне так ECS хороша для какой-нить RTS в части логики юнитов, рендеринга в целом и им подобных. Т.е. где все действия ограничены и почти не содержат условий в принципе или условия сами проистекают из их особенностей(классификации).
Потому как бухгалтеров заменяют программы(программисты). То же касается многих других проф. Сколько надо было раньше бухгалтеров, а сколько сейчас? Они всё ещё нужны, т.к. местами тормозит прогресс налоговая(через банки). Переводы, консультанты, продаваны - уже. Остаются только особые вещи, типа откатов - тут живой продаван нужен. Гиды и курьеры - тут шасси нужно, ну и это делается. Склады - то же что с бухгалтерами.
А вот врача, учителя и т.д. - тут тормозит инерция мышления, требования коммуникации и правовые последствия. Примерно то же же не даёт в области права применять ИИ. Но есть, например, архитектура. Что там по ИИ? А те же проблемы, что и с 3D, и с 2D картинками. Сделать можно, даже красиво, но доработать до качества - нет. Местами в этих секторах уже прошли путь от повсеместного использования ИИ, затем перешли к ИИ и доработке, а потом уже дошли до такого же отказа от него - потому как ИИ выходит дороже и менее качественно, т.к. всё равно требует качественного спеца и не делает это итеративно.
Если вы видите, что ИИ где-то не применяют, то это не оттого, что это ещё не пробовали. А оттого, что это пока что ни у кого не получилось или уже отчасти сделано, но вы не в теме
Благо у продавцов есть начальник и если всё же хакните, их решения так же отменят
Вот ни разу. Если договор уже составлен, то отменить его будет совсем не простой задачей, даже если по нему тебе за товар сама компания должна платить. А в более адекватных пределах и вовсе невозможно без дачи взятки
Пока никак не регулируется ИИ, отвечает за всё что скажет ИИ тот кто его допустил к клиентам(считай, составлению договоров, лечению и т.д.). Это такой же предпринимательский и прочий риск как и любой другой
Старфилд может и не так фатально тормозит, но жрёт ресурсы и тормозит очень даже сильно на новом железе среднего ценового сегмента(5060 и тд). И совсем не в 4к и 120 фреймрейта, даже и не на максималках. При том, графика не сказать что прям хороша в большей части игры
Разве что хорошо форматирует. Красиво) Но логика строится на тех задачах, что уже были где-то найдены.
Однако, ошибается постоянно. Последнее что делал - задача по физике для 9 класса, нужно посчитать силу действующую на 2 опоры и балку на них висящую, с учётом выхода балки за 1 из опор. Пока решается в лоб - всё ок. Решить другим способом? Ни за что. Когда добавил момент, что часть балки имеет нулевой или иной вес, то решить не может, вообще никак. Хотя, с ~50 раза получилось добиться правильного выполнения, но для этого пришлось расписать алгоритм целиком и очень подробно. Nолько тогда ИИшка смогла повторить его. Но что если чуть поменять условия? Опять по новой)
То же со старыми либами или новыми. Поменялась работа - они ничего сделать не могут. О старых, похоже, просто нет примеров использования. Вот для того, чтобы причесать код можно использовать
<< Просто «километр оптики» — это не только бухта кабеля. Это еще и землеотвод и опоры>>
Вот вообще нет. НА текущие опоры кладут часто, или роют, или через канал. В общем способов уйма. А отдельные опоры чтобы ставили - не видел ни разу.
Землеотвод дорогой там тоже не нужен - места полно, как правило, и мб вообще уже есть куда приткнуться. За рубль, если вообще нужно.
Вот как раз недавно было, тарифы около 1к., клиентов считают заранее, оборудование в довесок за 3к-5к надо докупить + первичный взнос не малый. В сёлах же дворов может быть и более 1к. Но в данном случае было около сотни, а тащить надо было от соседней деревни в 5-10км.
Я работал в компании с такими вот штуками. Там задачи так ставили, + критерии для QA. В результате весь промпт разрабы игнорили. Он был до омерзения полон не технических деталей, процентов на 70, 15% были отсебятиной и 15% изначального запроса
Это почти чистый галлюциноген ИИ по нормативке, который формально можно сделать, но это увеличит срок разработки в несколько раз
Так же пытались ТЗ от аналитиков сделать, структуру составили, пытались как-то наполнить и т.д. И выглядело это очень хорошо и похоже на правду со стороны(директорат был в восторге похоже). Но на деле было то же самое, что и выше писал. Только в большом тексте заметить это было на много сложнее, потому как текст внешне не противоречив, понятен, +схемки какие-то, даже с виду логически верные. Но чуть подумаешь и опытному человеку сразу видно, что это чушь
Я в геймдеве писал именно полноценные модели, которые держали весь код БЛ. Ни 1 класса на 10 к строк кода ни разу не было. Даже на 1к были только очень редкие специализированные классы, например, обработчики матриц и векторов, что обязательно надо делать в 1 методе, из-за чего они были весьма длинные и тяжёлые. А БЛ в геймдеве обычно много сложнее чем на любом беке сайтов, что я видел.
При этом не делал впадая в другую крайность - отдельный класс на каждый чих. Впрочем, как и тут в команду логику я не выносил) Грамотно спроектировать участвующие сущности в классы, да и всё.
Про кучу зависимостей - часто видел как раз с контроллерами. Там на входе using или import на десятки строк норма, а в некоторых и больше ста встречал. Разделение же по логике требует высокий уровень понимания разделения ответственности, но даёт минимум сторонних зависимостей
Ну, справедливости ради, VRS можно было самому прописать. Нвидиа говорит о крайне малом применении, и то практически всегда только VR игры, так что не велика потеря. От какой там индустрии отставание? Хотя оно есть, но явно не в таком виде
В прочих движках часто доступ к DX прямой, т.е. фактически это просто перекладывание, а не реализация абстраций.
А вообще интересно, какие, например, проблемы? Я не копался очень глубоко, и пока не замечал таких проблем асинхронностью. Однако, юнька и не позволяет её кастомизировать, только использовать как есть, подстраиваясь под движок. А если идти ещё дальше, то тут уже точки синхронизации упираешься, которые в юньке не полностью управляемы. Но до такого я ни разу не доходил ещё. В последнее встречал только что графику делали как придётся, заботясь об оптимизации в последний момент(
А где такая работа, что там нет задач для стажёров или джунов? Я в геймдеве до тупой кодинг постоянно вижу, в вебе и прочих CRM его вообще тонны
" самым спорным практикам ООП, когда данные и код связываются вместе"
Это как раз не спорно) Это логично - код исполнения и сигнатура данных вместе, т.к. код работает именно с ними, а вместе они и дают самостоятельный объект. А вот разделять их тот ещё мазохизм. Зачем, если потом обрабатывать всё равно будешь эти же данные?
Нет, не просто разложили, а именно что перекомпоновали и выделили участвующие объекты, сделали классификацию, чем разграничили ответственность.
Логика уже была разложена по папочкам, проект делали не новички без опыта. Только в такой структуре уже нужны были папочки для папочек) Что и делали. Из-за чего были дубли логики, а некоторая логика имела привычку делать 100500 проверок, которые повторялись для многих элементов.
Паттерны - инструмент для недоучек. Когда нужно быстро подготовить программиста. А инструмент применять надо к месту, для этого должен быть старший, что будет вести.
Переход на SSD и внедрение DirectStorage изменили подход к загрузке данных: исчезли традиционные экраны загрузки, ассеты подгружаются быстрее, миры стали более цельными...
Основное узкое место таковой загрузки - оперативная память, а не SSD. Ну и сама реализация программно - управление памятью. + это не везде работает, поэтому нельзя делать только для такой конфигурации. И такой чушью вся статья заполнена. Как обзор маркетинга от компаний индустрии.
По движкам то же самое. Про анрил толком не скажу, не в курсе как он развивался. А вот Unity упоролась в другую, т.е. отличную от привычной COP(OOP) парадигму, которая позволяет управлять тысячами объектов не разбираясь в особенностях работы языка программирования - DOTS(DataOP). И потеряла на это больше 5 лет. И cделала это крайне плохо - применимость плохая, а сложность поддержки высокая. Условно, 1 строчка на старом варианте превращается в 3 с DOTS. Имхо, в маркетинг этой идеи влито больше на порядки, чем бюджеты игр выпущенных на этой всё ещё сырой технологии. А сейчас по факту вынуждена поддерживать, считай, 2 движка, а не 1.
del
Дорожает т.к. нужно делать что-то новые, приносить новый опыт. На деле игры очень сильно развиваются, именно они долгое время двигали прогресс. И суть тут в том, что сделать просто как раньше уже мало. А это всегда новая разработка. Анрил из коробки или Юнька - ничего не умеют. RT пока ещё идёт как опция, поэтому по факту надо делать 2 вида освещения. Там ещё путают RT и люмен. Да и RT не подходит там, где нужна высокая кинематографичность, т.е. прямое управление освещением, а не реалистичное.
Нанит вот хз. Но сразу же он имеет кучу ограничений, т.е. не везде применим и имеет особенности работы, т.е. это не просто загрузил без лодов и всё хорошо. У меня есть большие сомнения, что он делает в статике картинку так же эффективно как LOD, и скорее всего он всегда требует выскопроизводительной карты даже для небольшого экрана и невысокой частоты кадров(при повсеместном использовании) .Т.е. это скорее инструмент для, например, зданий. Которые надо отобразить и за километр, так постепенно пока не зайдёшь внутрь.
PS: статья лажа, имхо от того, кто вообще не в теме, т.е. гпт + обработка мб
Эта картинка ложная. Так невозможно разместить клавиатуру. Локти удобнее не под 90, а чуть больше. Хз, может быть под 90 тоже можно, но тогда клавиатура должна быть прям у живота, на высоте подлокотников и стола, т.е. ровно в них. Либо, если плечи не ровно вертикально, то уже не удобно держать руку, она будет в напряжении.
Вот эти все прямые углы от ОКР-щика какого, похоже. Длительное нахождение в таком виде - это прямой путь к куче заболеваний. Человек не такой ровный. И нагрузка как раз в таких положениях не распределяется по разным частям тела, а наоборот, заставляет напрячься.
PS: отдельно отмечу хорошо показанную точку нижнего отдела спины)
Как раз в универе многие этому и учатся. Ну или в этом возрасте. Так что самое то для обучения
Тут вопрос чем именно ломается. Изменение в логических операторах или последовательностях всё же много чаще, чем изменение принципов. А это как раз ломает уже построенную архитектуру ECS. И такое изменение может потребовать проработки всей группы из-за высокой связности. Тут уже писал, имхо, ECS хорош как раз там, где такой сложной логики нет, а классификация вообще не требует последовательного выполнения. Но не редко сложная логика в таком виде приводит к дополнительным вычислениям и данным, дабы реализовать те же условия логики как часть данных.
Так, многие и про *-варианты не слышали) Тут знать терминологию не надо, чтобы понять суть. А она вообще в другом
Любая новая когнитивная деятельность поначалу неудобна) ECS так же поначалу часто неудобен почти для всех, не важно что там с ООП. Да даже само по себе программирование то ещё неудобство)
В таких вещах хорошо смотреть как удобно это читается, чинится, изменяется. И вот в первых двух неудобств у ООП нет вовсе. Изменения посложнее, но если не требуют перепроектирования, то так же крайне просты. И, что не маловажно, изменения совпадают с дизайном(ТЗ) большинства людей.
Это не пример выжившего лётчика, а как раз вполне обыденный. Если убрать шелуху, которую присваивают постфактум людям, то можно заметить, что как раз выбивающиеся из правил двигают что-то в мире, в т.ч. науку. А из "отличников" % таких людей ни чуть не отличается, хотя у них часто куда лучше среднего стартовые возможности и доступ к лучшему образованию.
Там выше человек писал, о том как было бы замечательно провести сегрегацию людей по школьным знаниям. Принудительно
Когда у тебя объекты из РПГ, где каждый имеет свою особую логику, то легко увидеть, что SIMD работает на 1-2 объектах, а дополнительные цепочки вызовов функций на порядок больше, потому как создаётся огромное кол-во классов с ~1 логическим действием.
Про критику не соглашусь. В некоторых случаях порядок не важен и так можно выстраивать архитектуру - это лучший способ. Но так не всегда получается, и тогда нужно иметь чёткий порядок. А если не получается в условиях типа case в ООП, то нужно вводить дополнительные переменные и делать лишний прогон.
Да и в целом, как задать порядок в сложной логике, которая описывается несколькими документами? Я тут не на столько компетентен, но сейчас подозреваю, что лучше вводить булевы переменные для таких случаев, а не контролировать порядок явно. А это падение производительности, но сильное упрощение проектирования.
О какой эффективности проходов по данным говорить, если контроллер требует действий над 1-10 объектами? Тут не то, что SIMD, тут вообще такое выполнение убивает эффективность использования кеша проца, и особенно предсказаний. А где прям много объектов, ну хотя бы 1к+, выигрыш действительно существенный. Но много ли таких ситуаций? До ECS такое решали просто - массивчик, проход по нему внутри цикла. И тот же SIMD можно обеспечить. Хранить и пользоваться такими данными сложно, но часто это конечная логика для C# кода, так что можно было и без ECS запустить 10к юнитов с анимацией на Unity PC. Схожим образом, например, работают(или работали) партиклы.
Про "гибко и безопасно управлять логикой" вообще мимо. Именно с логикой(условиями), у ECS прям проблемно. Перелопатить кучу данных - это да, легко. А вот управление логикой разбивается на кучу частей, которые могут очень неожиданно отработать. Фрагментация логики приводит к неожиданному поведению систем в целом. Что уж, порой без некоторых новых инструментов отладки это было вообще не реально. Хотя иногда это даже в плюс, но не когда требуется чёткое поведение. И тем более, не когда читаешь код и тебе человеки говорят о баге, а ты ещё и не знаешь с сотню систем которые затрагивают это место.
По мне так ECS хороша для какой-нить RTS в части логики юнитов, рендеринга в целом и им подобных. Т.е. где все действия ограничены и почти не содержат условий в принципе или условия сами проистекают из их особенностей(классификации).