Это да. После LeoECS количество годных ECS-фреймворков для шарпа начало увеличиваться: Actors, Morpeh, ME.ECS, DefaultECS... Такая тенденция не может не радовать.
Хочу заметить, что "с ECS беда" конкретно в DOTS, сам по себе ECS как паттерн штука хорошая и в большинстве фреймворков не требует танцев с бубном, но юнитеки ради гипер-производительность очень переусложнили фреймворк
Но это почти никак не влияет на основной тезис статьи: если проект не требует технологий UE5, то зачем тратить на разработку больше при практически одинаковом(зависит от специалистов) результате?
Позволю себе не согласиться.
В 18 лет я бросил универ на первом курсе. Программирование изучал исключительно в школе, да и то был паскаль. После универа поработал слесарем-ремонтником(почти сантехник) год и трактористом два, совсем не думая о программировании и даже не планируя им заниматься.
Но потом в мои 22 трактористу внезапно захотелось делать игры и для этого я начал изучать Java. Месяца два-три исключительно вникал в синтаксис и пытался понять как работают объектно-ориентированные языки, но таки с горем пополам написал крестики-нолики в консоли. Потом узнал про Unity. Увидел, что C# почти то же самое что и Java и быстренько трансформировался на шарпы.
Следующие пол года делал свою первую игру(двумерный космосим) на сколько хватало знаний, попутно пополняя знания C# с помощью Metanit и гугла. Пытался собрать комьюнити вокруг игры, но неудачно. И тут один знакомый программист сказал «Ты же умеешь кодить, целую игру запилил, зачем ты до сих пор возишься в тракторном масле? Ищи работу!». Ещё пол года искал первую работу, с третьей попытки таки нашёл место(правда не геймдев).
И вот, спустя три года, я опытный Middle+ Unity-разработчик с зарплатой в 6 раз больше, чем когда я начал изучать Java. Свои игры, к сожалению, больше не делаю, ибо с воображением и дизайном у меня туго, да и свободного времени не так много, но тем не менее получаю удовольствие от создания игр.
Но я абсолютно согласен с утверждением, что хорошая мотивация — наше ВСЁ. Если учиться разработке исключительно ради хорошего заработка и не получать от процесса удовольствие, то это вряд ли к чему приведёт.
Дорогой товарищ, вы наступили на достаточно частое заблуждение. Вы путаете два совершенно разных(хоть и близких) архитектурных подхода: Entity-Component-System(ECS, о котором эта статья) и Entity-Component(EC). Они хоть концептуально и близки, но совершенно разные на практике.
Почти все перечисленные вами варианты, в особенности Unity и UE4, по умолчанию предлагают именно EC-подход. Там есть условный GameObject/Actor(сущность) и есть его свойства(компоненты). Сама по себе сущность — абстракция, которая просто есть, а компоненты одновременно содержат и данные, и логику, которая обрабатывает эти самые данные. Собсно это допущение и порождает в итоге god-objects, тк так проще писать и проще думать. Когда у компонента напрямую вызывается Update() — это явный признак того, что перед нами именно EC.
Ключевая же особенность ECS — строгое отделение данных от их процессинга + линейный(конвейерный) способ обработки данных. Все иные ситуации, где перечисленных свойств не наблюдается, уже не являются ECS. Update(), в случае ECS, вызывается ИСКЛЮЧИТЕЛЬНО у систем, а внутри систем уже и происходит вся логическая магия. Системы, в свою очередь, не являются какими-либо хранителями состояния и, в идеале, не должны хранить каких-либо данных(но это допускается).
Unity в рамках DOTS предлагает разработчикам перейти с EC-подхода на чистый ECS, но и без DOTS для Unity(и C# в частности) уже предостаточно ECS-фреймворков, с которыми очень комфортно работать. Для C++ ECS-фреймворков тоже предостаточно, стоит только пройтись по гитхабу. Однако плюсовые фреймворки стоят немного в стороне от UE4, но уже появляются люди и проекты, которые хотят это исправить.
Движков, которые написаны изначально под использование ECS-подхода, можно пересчитать по пальцам, доступных общественности — на пальцах одной руки. Но они, к сожалению, пока только развиваются и еще далеки от идеала.
Надеюсь мне удалось развеять ваше заблуждение и вы таки попробуете ECS-подход на своих проектах. В него сложно влиться по началу, но стоит только вкусить этот божественный плод — больше не слезешь :)
Сама по себе архитектура никак не влияет на количество лапши, которую нужно писать. А вот конкретный фреймворк — уже влияет.
Svetlo ECS — ИМХО, рекордсмен по количеству лапши
Unity ECS — требует уже немного меньше необходимой лапши(хотя это еще хз)
Entitas — еще меньше лапши, но в обмен на кодогенерацию
Однако есть и всякие опенсорсные альтернативы, которые стараются делать максимально простой и понятный API — LeoECS и Morpeh. Вот в них количество кода будет на несколько строк больше, чем в аналогичном коде на монобехах, зато взамен они дают лучшую модульность, тестируемость и расширяемость, по сравнению с любыми вариантами на монобехах.
Позволю себе не согласиться. Именно таким образом, как «раньше», я и оказался в IT два года назад.
1) Освоил азы C#/Unity
2) Устроился на работу, прокачал знание C# while(true){
3) Сменил работу
4) Прокачал знание C#/Unity, выработал некоторые свои идеи }
Плюсую. Юнитеховский фреймворк пока далек от удобной разработки. Без ссылочных типов в компонентах очень больно работать, особенно в нынешнем рантайме Unity. А в будущем это добавит геморрою при использовании кастомных C#-либ.
Мне больше всего в работе зашел фреймворк от Leopotam, но тут на вкус и цвет. Лучше попробовать все, чем позже решить, что выбранный чем-то не устраивает.
Следующий коммент написан для людей, которые только планируют открыть себе славный мир ECS.
Из-за таких статей создается ложное впечатление, что основной плюс ECS — производительность, но это совершенно не так. Выигрыш в производительности лишь приятное последствие этого архитектурного паттерна. ИМХО, основной его плюс — удобство работы с ним в рамках архитектуры проекта(ессесно, только когда начнешь им думать, а не пробовать), он решает те же проблемы, что и SOLID, но иным образом.
Да, я тоже недавно на Harmony наткнулся, но интересно есть ли еще какие-то способы и не совсем понимаю что со стороны разработчика нужно сделать, что бы можно было свободно делать моды через Harmony
Это да. После LeoECS количество годных ECS-фреймворков для шарпа начало увеличиваться: Actors, Morpeh, ME.ECS, DefaultECS... Такая тенденция не может не радовать.
Хочу заметить, что "с ECS беда" конкретно в DOTS, сам по себе ECS как паттерн штука хорошая и в большинстве фреймворков не требует танцев с бубном, но юнитеки ради гипер-производительность очень переусложнили фреймворк
Но это почти никак не влияет на основной тезис статьи: если проект не требует технологий UE5, то зачем тратить на разработку больше при практически одинаковом(зависит от специалистов) результате?
В 18 лет я бросил универ на первом курсе. Программирование изучал исключительно в школе, да и то был паскаль. После универа поработал слесарем-ремонтником(почти сантехник) год и трактористом два, совсем не думая о программировании и даже не планируя им заниматься.
Но потом в мои 22 трактористу внезапно захотелось делать игры и для этого я начал изучать Java. Месяца два-три исключительно вникал в синтаксис и пытался понять как работают объектно-ориентированные языки, но таки с горем пополам написал крестики-нолики в консоли. Потом узнал про Unity. Увидел, что C# почти то же самое что и Java и быстренько трансформировался на шарпы.
Следующие пол года делал свою первую игру(двумерный космосим) на сколько хватало знаний, попутно пополняя знания C# с помощью Metanit и гугла. Пытался собрать комьюнити вокруг игры, но неудачно. И тут один знакомый программист сказал «Ты же умеешь кодить, целую игру запилил, зачем ты до сих пор возишься в тракторном масле? Ищи работу!». Ещё пол года искал первую работу, с третьей попытки таки нашёл место(правда не геймдев).
И вот, спустя три года, я опытный Middle+ Unity-разработчик с зарплатой в 6 раз больше, чем когда я начал изучать Java. Свои игры, к сожалению, больше не делаю, ибо с воображением и дизайном у меня туго, да и свободного времени не так много, но тем не менее получаю удовольствие от создания игр.
Но я абсолютно согласен с утверждением, что хорошая мотивация — наше ВСЁ. Если учиться разработке исключительно ради хорошего заработка и не получать от процесса удовольствие, то это вряд ли к чему приведёт.
Почти все перечисленные вами варианты, в особенности Unity и UE4, по умолчанию предлагают именно EC-подход. Там есть условный GameObject/Actor(сущность) и есть его свойства(компоненты). Сама по себе сущность — абстракция, которая просто есть, а компоненты одновременно содержат и данные, и логику, которая обрабатывает эти самые данные. Собсно это допущение и порождает в итоге god-objects, тк так проще писать и проще думать. Когда у компонента напрямую вызывается Update() — это явный признак того, что перед нами именно EC.
Ключевая же особенность ECS — строгое отделение данных от их процессинга + линейный(конвейерный) способ обработки данных. Все иные ситуации, где перечисленных свойств не наблюдается, уже не являются ECS. Update(), в случае ECS, вызывается ИСКЛЮЧИТЕЛЬНО у систем, а внутри систем уже и происходит вся логическая магия. Системы, в свою очередь, не являются какими-либо хранителями состояния и, в идеале, не должны хранить каких-либо данных(но это допускается).
Unity в рамках DOTS предлагает разработчикам перейти с EC-подхода на чистый ECS, но и без DOTS для Unity(и C# в частности) уже предостаточно ECS-фреймворков, с которыми очень комфортно работать. Для C++ ECS-фреймворков тоже предостаточно, стоит только пройтись по гитхабу. Однако плюсовые фреймворки стоят немного в стороне от UE4, но уже появляются люди и проекты, которые хотят это исправить.
Движков, которые написаны изначально под использование ECS-подхода, можно пересчитать по пальцам, доступных общественности — на пальцах одной руки. Но они, к сожалению, пока только развиваются и еще далеки от идеала.
Надеюсь мне удалось развеять ваше заблуждение и вы таки попробуете ECS-подход на своих проектах. В него сложно влиться по началу, но стоит только вкусить этот божественный плод — больше не слезешь :)
Svetlo ECS — ИМХО, рекордсмен по количеству лапши
Unity ECS — требует уже немного меньше необходимой лапши(хотя это еще хз)
Entitas — еще меньше лапши, но в обмен на кодогенерацию
Однако есть и всякие опенсорсные альтернативы, которые стараются делать максимально простой и понятный API — LeoECS и Morpeh. Вот в них количество кода будет на несколько строк больше, чем в аналогичном коде на монобехах, зато взамен они дают лучшую модульность, тестируемость и расширяемость, по сравнению с любыми вариантами на монобехах.
Позволю себе не согласиться. Именно таким образом, как «раньше», я и оказался в IT два года назад.
1) Освоил азы C#/Unity
2) Устроился на работу, прокачал знание C#
while(true){
3) Сменил работу
4) Прокачал знание C#/Unity, выработал некоторые свои идеи
}
И не опенсорсная ли она у вас?
Мне больше всего в работе зашел фреймворк от Leopotam, но тут на вкус и цвет. Лучше попробовать все, чем позже решить, что выбранный чем-то не устраивает.
Из-за таких статей создается ложное впечатление, что основной плюс ECS — производительность, но это совершенно не так. Выигрыш в производительности лишь приятное последствие этого архитектурного паттерна. ИМХО, основной его плюс — удобство работы с ним в рамках архитектуры проекта(ессесно, только когда начнешь им думать, а не пробовать), он решает те же проблемы, что и SOLID, но иным образом.