Я в геймдеве писал именно полноценные модели, которые держали весь код БЛ. Ни 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 в части логики юнитов, рендеринга в целом и им подобных. Т.е. где все действия ограничены и почти не содержат условий в принципе или условия сами проистекают из их особенностей(классификации).
Юзкейсы из чистой архитектуры. DDD про другое, хотя те же юзкейсы можно сказать там есть в Application Layer. Смешивать эти 2 подхода странно. Но применение в таком виде это уже за гранью обоих этих подходов) В обоих случаях БЛ должна быть в модели, в ЧА собсно модель, а в DDD это разные части доменного слоя, как аналог модели это сущности и их агрегаты
В играх часто выходит очень сложная логика, которая не редко умещается буквально в несколько доменов, а то и в 1. Т.е. DDD там по этой же причине толком не применяется - излишне. Чистая архитектура примерно то же самое, хоть она попроще, поменьше, всё равно слишком избыточна. Общие подходы с разделением на схожие части и связи в хороших проектах есть всегда и +- соответствуют этим 2, только без бойлерплейта. Тут почаще можно встретить MVC, например, ну или MVVM. Этого разделения + чуть-чуть смысла, и часто хватает за глаза. Основная сложность всё равно остаётся внутри логики
В цикле статей(маг и воин, 5 частей) такое наследование как раз и должно быть. Он в 5 части раскрывает как это сделать без боли, точнее почему это работает и в чём ошибка была. Но примера в коде не даёт
15-20 лет назад про ООП много говорили. И почти никто не умел. Я это понял чутка позже. Сам я писал вначале в процедурном стиле. Первые компроекты вообще целиком процедурками были. Лет 5-15 назад я прям смотрел на проекты и видел Успешные проекты в геймдеве именно в процедурном стиле. Много видел разговоров про ООП и тп., а проект всё те же процедурки, но с финтифлюшками, функциональщиной, реактивщиной и т.п.. Последний такой видел в распространённой мидикорке или казуалке с прокачкой особняка и т.п. До асинков и аналогов ещё часто встречал колбечное программирование - отдельный вид мазохизма, который, к счастью, совсем почти вымер. Это не как ООП в C# с event-based в норме в то время, или промисами java, а часто именно процедурный стиль
Так вот даже тот последний проект в процедурном держал дубли кода, тащил кучу зависимостей, контроллеры пухли очень сильно и разбираться в этом было так сложно, что разрабы тупо забивали на поиск кода(сотни или тысячи строк сильносвязного кода в 1 классе). Логика была размазана в контроллере, из-за чего происходила циклическая правка багов. Но логика не была размазана между контроллерами, легко было отследить что откуда стартует и что изменяет, и в целом была на месте. Т.е. изначально проект грамотно спроектировали. Только в целом понять как оно работает было почти невозможно, не разбирая код по кирпичику до самого основания. Потихоньку сконвертили многое в ООП и проблема с пониманием как работает та или иная вещь полностью ушла - это стало легко посмотреть прямо в коде, не спрашивая дизайнеров о том, что делали пару лет назад люди, которых уже давно нет. Зависимостей так же стало в разы меньше.
Многие из процедурного так и "не выросли". Не знаю, может даже большинство. Я на собесах ни разу не встречал вопросов о проектировании, например. Инструменты ООП - этого полно. А вот как их применять - почти и не помню такого. Впрочем, по паттернам так же. Вопросы о паттернах есть, а об их применении, условиях, последствиях - нет. Сами собеседующие часто не особо шарят. И сам когда спрашиваю, да хотя бы об алгоритмах, редко кто может сказать про общие принципы, хотя за плечами бывает явно не плохой бек и не мало проектов.
Про 10 классов - это как раз часто не смогли, кроме некоторых случаев подходов, типа интерфейс как контракт
Флаг именно в таком виде, если он не нужен в ECS, может так же реализовываться в ООП. Конкретно указанный случай скорее некорректен, т.к. его быть в целом не должно.
Ну да, планировать надо. В ECS тоже. Только сам ECS подталкивает к этому. Но есть момент, что когда логика становится сложной, то наборы правил тоже становятся очень сложными. Как и отслеживание логики и последовательности изменения состояния. И часто это много сложнее чем в ООП, потому как логика действия и изменения данных проходят большие цепочки контроллеров. Чуть ошибёшься в очерёдности, не добавишь для её контроля и тп - всё поломается. Кстати, и производительность такого кода много меньше, чем в ООП.
Чистые данные без методов - это не про функциональщину) Там, пусть и условно, всегда есть методы для каждого состояния и они как раз условно содержат состояние, точнее меняют текущее. Но и выполняются они не такими группами и позволяют менять состояние целиком. А так можно и ООП назвать похожим, там тоже есть данные и применяемые к ним методы, прям как в FP, но уже есть "сайдэффекты". Всё таки разница в подходах по сравнению с DOP огромна в обоих случаях, и ещё больше в вариантах для Unity
Штраф будет, т.е. его выпишут без твоего на то желания. Дальше только в суд. А судьям всё равно) По этой статье и до ВС доходили не раз, но туда далеко не все дела желающих попадают на рассмотрение. И судьи, как правило, не смотрят такие дела, просто за глаза вынося решения.
Ни капли не выше, если вы в биологии на школьном уровне разбираетесь и можете хотя бы не много разобраться в ответах. Разницы между случайным врачом и гуглом просто нет при случайном же заболевании, даже если не разбираешься более глубоко. К сожалению, сейчас такова действительность
Врач скорее будет лучше только в некоторых обстоятельствах, например, заболевание типичное для местности или качеств больного, специфично для опыта врача, при ведении больного длительное время, и прочих подобных случаях
Я в геймдеве писал именно полноценные модели, которые держали весь код БЛ. Ни 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 в части логики юнитов, рендеринга в целом и им подобных. Т.е. где все действия ограничены и почти не содержат условий в принципе или условия сами проистекают из их особенностей(классификации).
О том и речь - не научились ещё в ООП, а уже используют инструмент, что его ломает
Юзкейсы из чистой архитектуры. DDD про другое, хотя те же юзкейсы можно сказать там есть в Application Layer. Смешивать эти 2 подхода странно.
Но применение в таком виде это уже за гранью обоих этих подходов) В обоих случаях БЛ должна быть в модели, в ЧА собсно модель, а в DDD это разные части доменного слоя, как аналог модели это сущности и их агрегаты
В играх часто выходит очень сложная логика, которая не редко умещается буквально в несколько доменов, а то и в 1. Т.е. DDD там по этой же причине толком не применяется - излишне. Чистая архитектура примерно то же самое, хоть она попроще, поменьше, всё равно слишком избыточна.
Общие подходы с разделением на схожие части и связи в хороших проектах есть всегда и +- соответствуют этим 2, только без бойлерплейта. Тут почаще можно встретить MVC, например, ну или MVVM. Этого разделения + чуть-чуть смысла, и часто хватает за глаза. Основная сложность всё равно остаётся внутри логики
В цикле статей(маг и воин, 5 частей) такое наследование как раз и должно быть. Он в 5 части раскрывает как это сделать без боли, точнее почему это работает и в чём ошибка была. Но примера в коде не даёт
15-20 лет назад про ООП много говорили. И почти никто не умел. Я это понял чутка позже. Сам я писал вначале в процедурном стиле. Первые компроекты вообще целиком процедурками были. Лет 5-15 назад я прям смотрел на проекты и видел Успешные проекты в геймдеве именно в процедурном стиле. Много видел разговоров про ООП и тп., а проект всё те же процедурки, но с финтифлюшками, функциональщиной, реактивщиной и т.п.. Последний такой видел в распространённой мидикорке или казуалке с прокачкой особняка и т.п. До асинков и аналогов ещё часто встречал колбечное программирование - отдельный вид мазохизма, который, к счастью, совсем почти вымер. Это не как ООП в C# с event-based в норме в то время, или промисами java, а часто именно процедурный стиль
Так вот даже тот последний проект в процедурном держал дубли кода, тащил кучу зависимостей, контроллеры пухли очень сильно и разбираться в этом было так сложно, что разрабы тупо забивали на поиск кода(сотни или тысячи строк сильносвязного кода в 1 классе). Логика была размазана в контроллере, из-за чего происходила циклическая правка багов.
Но логика не была размазана между контроллерами, легко было отследить что откуда стартует и что изменяет, и в целом была на месте. Т.е. изначально проект грамотно спроектировали. Только в целом понять как оно работает было почти невозможно, не разбирая код по кирпичику до самого основания.
Потихоньку сконвертили многое в ООП и проблема с пониманием как работает та или иная вещь полностью ушла - это стало легко посмотреть прямо в коде, не спрашивая дизайнеров о том, что делали пару лет назад люди, которых уже давно нет. Зависимостей так же стало в разы меньше.
Многие из процедурного так и "не выросли". Не знаю, может даже большинство. Я на собесах ни разу не встречал вопросов о проектировании, например. Инструменты ООП - этого полно. А вот как их применять - почти и не помню такого. Впрочем, по паттернам так же. Вопросы о паттернах есть, а об их применении, условиях, последствиях - нет. Сами собеседующие часто не особо шарят. И сам когда спрашиваю, да хотя бы об алгоритмах, редко кто может сказать про общие принципы, хотя за плечами бывает явно не плохой бек и не мало проектов.
Про 10 классов - это как раз часто не смогли, кроме некоторых случаев подходов, типа интерфейс как контракт
Флаг именно в таком виде, если он не нужен в ECS, может так же реализовываться в ООП. Конкретно указанный случай скорее некорректен, т.к. его быть в целом не должно.
Ну да, планировать надо. В ECS тоже. Только сам ECS подталкивает к этому. Но есть момент, что когда логика становится сложной, то наборы правил тоже становятся очень сложными. Как и отслеживание логики и последовательности изменения состояния. И часто это много сложнее чем в ООП, потому как логика действия и изменения данных проходят большие цепочки контроллеров. Чуть ошибёшься в очерёдности, не добавишь для её контроля и тп - всё поломается. Кстати, и производительность такого кода много меньше, чем в ООП.
Чистые данные без методов - это не про функциональщину) Там, пусть и условно, всегда есть методы для каждого состояния и они как раз условно содержат состояние, точнее меняют текущее. Но и выполняются они не такими группами и позволяют менять состояние целиком. А так можно и ООП назвать похожим, там тоже есть данные и применяемые к ним методы, прям как в FP, но уже есть "сайдэффекты". Всё таки разница в подходах по сравнению с DOP огромна в обоих случаях, и ещё больше в вариантах для Unity
Штраф будет, т.е. его выпишут без твоего на то желания. Дальше только в суд. А судьям всё равно) По этой статье и до ВС доходили не раз, но туда далеко не все дела желающих попадают на рассмотрение. И судьи, как правило, не смотрят такие дела, просто за глаза вынося решения.
Ни капли не выше, если вы в биологии на школьном уровне разбираетесь и можете хотя бы не много разобраться в ответах. Разницы между случайным врачом и гуглом просто нет при случайном же заболевании, даже если не разбираешься более глубоко. К сожалению, сейчас такова действительность
Врач скорее будет лучше только в некоторых обстоятельствах, например, заболевание типичное для местности или качеств больного, специфично для опыта врача, при ведении больного длительное время, и прочих подобных случаях