На самом деле основные проблемы, которые хотелось подчеркнуть, были именно организационными, а по поводу производительности мысли были лишь о том, что высокая производительность не стоит такой запутанной организации. Но мне тут уже нормально так насыпали аргументов, что производительность вообще не важна, а организация на самом деле и есть основное преимущество.
Я с этим не согласен, но создать целую статью лишь с болью про организацию, особенно без хороших альтернатив (а сложные ООП проекты не будут так же содержать серебрянных пуль) я не готов.
Поэтому прошу прощения за неоправданные ожидания, в следующий раз постараюсь лучше. В комментариях накидали много статей, в том числе разбирающих недостатки.
В моем опыте скорее аккуратный КОП является близким к идеалу. Но есть несколько важных нюансов, в частности размер команды, количество в ней ГД и то, как принято работать с игрой с точки зрения ГД - есть ли полноценный левел дизайн и работают ли технические художники и неспециалисты с уровнями и префабами. Либо они допущены только до конфигураций. В первом случае сосредоточиться на правильной декомпозиции и удобстве для последних на порядок важнее любой архитектуры и стандартные компоненты, ну ОК.
Глубокие иерархии (наследования) однозначно зло. А вот иерархии объектов очень нужны (в смысле когда один класс использует напрямую другие - отряд - юнит - оружие - пуля).
В этом контексте обычные способы декомпозиции предлагаемые ECS (типично иметь компонент-позицию, здоровье и компоненты-флаги, к примеру) превращают проект в сложную комбинацию эффектов, понять которые крайне сложно.
Из описаний выше с Match-3 примером как раз потребовалось осознать, что ECS подход сам по себе не поможет. А помогла логическая декомпозиция того, из чего состоит реальная фишка на состояние, эффект и взаимодействие. Условно на триггер и эффект, которые можно сочетать независимо. Без этого код рос условиями каждый-к-каждому в том числе в ECS рос бесконтрольно и рожал много ошибок. Классический ООП тоже тут в общем то так же споткнулся бы.
Сейчас Я бы лучше использовал что-то типа анемичного объектного подхода, не пытаясь тащить инфраструктуру какого то ECS подхода.
Для проблемы веревки и проблемы декомпозиции вообще есть на самом деле простое решение - правило владения. Решать должен тот, кто знает про все свои детали. Соответственно в примере с веревкой ни юнит не содержит веревку, ни веревка - юнит, соответственно они не должны решать, как им взаимодействовать. Кто тогда должен решать - другой вопрос, на который этот принцип ответа не дает)
Поинт всей статьи в том, что про то, как объект качается на веревке, придется задумываться в любом случае. Сказать, что ECS решит это за вас, безо всяких орг практик, дисциплины и организации - портал в маленький ад. Только ад не такой, как переусложненное ООП, а другой, когда ты не можешь найти концов и краев и все пули застревают в веревках, потому что при пролете на самом деле качаются на них.
Для тру ООП как его многие представляют чрезмерная архитектурная космонавтика еще более характерна. И плохая декомпозиция. Но ярых фанатов в геймдеве я видел мало. Но ООП призывает начать с этого и признает проблему плохой декомпозиции. Собственно и ECS и многие паттерны для этого и нужны - потому что рефакторить больно.
Но ECS конечно же призывает к ультрадекомпозиции. Посмотрите на представленные статьи - они буквально говорят о том, что надеваем прыгательный компонент и у нас все прыгает. Совершенно без контекста того, как самые разные объекты могут взаимодействовать с прыганием тоже треш получится
Возможно биас вызван тем, что для ООП даже маленькие проекты изначально делаются с не очень качественной декомпозицией. Ничего не мешает делать компонентную структуру на обычных unity компонентах, разделить их на маленькие части и комбинировать.
Но одна из важных мыслей моей статьи - ECS не решает эту проблему автоматически. Так же и не приносит особых преимуществ на ранних стадиях - просто не используй ООП и пиши как попало, получишь ту же "все ко всем" декомпозицию
Мне кажется, что "если просто разделить данные и логику" - вот это тоже не правда. Это подается как простое решение, фигячь как хочешь, всегда понятно, что и где добавить. Проблема в том, что это не решает архитектурных проблем в организационной части. Архитектура это не только что у меня есть данные и код, архитектура конкретной игры - это конкретно ваши сущности, ваши пули, юниты и что там еще есть. Если это организовано само по себе разделение на логику и данные никак не влияет на то, что пуля должна наносить ущерб. Мы использовали ECS как раз для match 3 и когда речь зашла про возможное взаимодействие каждого с каждым ECS был организован так же сложно. Тут ООП подход ломается влегкую, Я согласен, но решение находится на организационной стороне, нужно придумать хороший список абстракций, возможно разделить процесс на триггер и эффект и тому подобное. Решение которое не зависит от деталей организации. И когда ты к нему приходишь, все равно придётся переписывать.
Вместе с тем статьи по ECS описывают все так, как будто проблемы не существует, надо лишь избавиться от ООП и все станет легко и приятно. Вместе с тем, данные с процессами вместе соединяют не просто так. Есть несколько представлений, со стороны которых можно работать - со стороны состояния и со стороны процесса. И штуки как корутины, асинки, колбеки и прочие реактивные библиотеки придуманы для того, чтобы держать близко контекст процесса - действие за действием, которые можно обозреть. ECS представляет все как один шаг тысячи ног одновременно, что может привести к аду, когда ты пытаешься понять поведение сущности. В теоретическом абстрактном мире системы могут быть написаны независимо, чтобы можно было понять что происходит только по компоненту и системам, использующим его. На практике чтобы понять поведение условно юнита, нужно развернуть в голове целый граф из многих компонентов и систем в нужном порядке, понять важные и не важные части и только потом получить данные, чтобы внести изменения. ООП не идеален, но буквально заточен на эту изоляцию. ECS концептуально ее отвергает.
Возможно вы правы и во многих статьях упор действительно делается прежде всего на композицию и решение архитектурных проблем. Тем не менее преимущества производительности подчеркивались тоже с ранних пор и многочисленные реализации, включая Unity ECS или ecs на rust напирают на это. Я встречал это многократно и про это же говорит типичная реализация, в которой entity - это идентификатор, а не объект, а системы предназначены для обработки данных батчами. По сути без этого ECS можно сделать на обычной юнити, просто используя GO и компоненты с публичными полями. Эти реализации тащат определенные правила - обычно для систем сущности выбираются неким специальным механизмом фильтров, вызывающим систему только на определенном наборе компонент / единичном компоненте. А работа с ссылками на сущности в обязательном порядке обрастает экстра кодом проверки наличия компонента на этой сущности. И то и другое вместе с овердекомпозицией серьезно запутывает код.
Но это действительно может быть важной частью моих проблем с ECS, хотя я критикую и организационную часть. С таким определением в других фреймворках таких проблем может и нет.
Мой гет в том, что пилить и поддерживать на нем гораздо проще только прототип. А дальше это становится кучей кода с компонентным аналогом event-hell, который очень тяжело понимать и обслуживать, потому что инструментов организации, помимо нейминга, практически нет.
Хм, а можно вопрос, вы разрабатываете проекты один или в команде?
Моя проблема с ECS в том, что нельзя изменить все в произвольном направлении из-за когнитивной сложности - буквально крайне тяжело понять, как работает условная абстракция, если ее писал не ты. То есть такая проблема везде есть, конечно же, просто в ецс с произвольным разделением чтобы понять поведение, условно, юнита, нужно в голове поднять целый граф объекта - все компоненты позиции, здоровья, статусы и флаги. И несколько систем, обязательно в нужном порядке, потому что порядок, очевидно, критичен. В итоге любой процесс (скажем, получение урона, вместе со всеми деталями - просчетом доп типов урона, смертью персонажа, анимацией попадания и прочего) размазано по десятку систем. По факту компоненты флажки используются как переменные связывания вместо функций по порядку или событий. В итоге на ровном месте ты получаешь аналог event-hell.
У меня есть стойкое ощущение, что люди живут с этим event-hell и такие "I'm fine", просто потому, что не знают, что есть методологии, как уменьшить это. Но это ведь сложно - правильные архитектуры нужно делать.
В итоге на самом деле решения на ECS имеют архитектуру - это просто нотации и договоренности в команде, может документация, что за чем следует и какие окончания у компонентов, заведующих событиями. И так как инструментальных решений организовать это нет или мало, на самом деле это увеличивает требования к архитектуре. Если же ты вываливаешься за пределы упорядоченных систем, например если нужны сложные связи или дерево - это как писать на сырых ссылках в C++, тебе нужно проверять каждый объект на наличие компонент и возможность обработки.
И да, Entitas очень сосредоточен на производительности - он использует массивы структур, сложную систему запросов для выбора систем обработки компонентов и кодогенерацию. Мой основной опыт это Entitas и несколько самописных решений, Я не использовал Unity-ECS в коммерческих проектах.
Это отчасти правда, но я не согласен с этим потому, что изначально эта архитектура была ассоциирована с решением проблем производительности.
Cама концепция систем сосредоточена на пакетной обработке компонентов, иначе их бы можно было бы назвать командами и применять к отдельной паре компонентов. Есть известная цитата про нарезку хлеба (с которой я не согласен). Вторичная система индексации, когда у вас есть Entity и это просто индекс, так же направлена на это, иначе можно было бы просто использовать ссылку на объект entity. Все это вместе дает свою философию доступа к объектам, которая отличается от просто доступа по ссылке.
Если бы речь шла только про декомпозицию и отделение данных от логики, вы бы могли (и можете) организовать это на обычных компонентах unity + системах, в этом смысле она и так entity-component.
Но в целом, значительная часть моей критики и направлена на то, что ультрадекомпозиция и отделение данных от логики по умолчанию - это плохое решение, которое в долгосрочной перспективе сделает проект крайне сложным для обслуживания. Так что да, Я критикую и эту часть тоже)
Вы не правы в том, что производительность не ассоциирована с ECS. Практически все ее упоминания или реализации на этом сосредоточены и так было с момента ее создания. Cама концепция систем сосредоточена на пакетной обработке компонентов, иначе их бы можно было бы назвать командами и применять к отдельной паре компонентов. Есть известная цитата про нарезку хлеба (с которой я не согласен). Вторичная система индексации, когда у вас есть Entity и это просто индекс, так же направлена на это, иначе можно было бы просто использовать ссылку на объект entity.
Безусловно важным фактором является и разделение логики и данных - и, на самом деле, я критикую это не в последнюю очередь как способ создать реально сложные и плохо обслуживаемые решения, когда из-за позднего связывания порядка систем и очень сильной декомпозиции элементов просто тяжело понять, что происходит.
Остальные факторы могут быть достигнуты без ECS:
Composition over inheritance является хорошей практикой и в современном ООП сообществе, глубокие иерархии очень хрупкие. По сути обычная среда Unity - это composition over inheritance, это, можно сказать, entity-component архитектура.
Для достижения гибкости не нужна полная ECS, достаточно просто компонентов и Data-Driven дизайна, когда игровые сущности можно собирать из кусочков ориентируясь на данные. Именно поэтому все современные движки это так или иначе дерево узлов и компоненты на них.
Анемичный дизайн, когда логика и данные развязаны, тоже много где характерен и для него не требуется волшебства.
Хранимое состояние - опять же, для этого нужны какие то общие методы сериализации и десериализации объектов, а не вся архитектура.
Не в последнюю очередь моя статья про то, что разделение логики и данных кажется хорошей идеей, но возможно это только кажется. ООП буквально придуман для того, чтобы собрать это вместе по хорошей причине - локальность данных и кода, защита целостного состояния объекта. Безусловно это может мешать, создавать хорошие абстракции непросто, но вы можете регулировать уровень этой локальности. Без этой абстракции создавать хорошие абстракции совершенно нереально. Я бы не сказал, что сложные задачи, где нужны гибкие отношения многих ко многим сильно упрощаются в ecs
Все так, ваши страхи не безосновательны. Видимо нам еще предстоит осознать проблему и придумать новые правила цифровой гигиены и правильных продуктов. Пока же да, то, что вы описали примерно так и работает - манипуляциями и ограничениями, переводом фокуса и запретами. Плохо кароче работает.
Ну не так там все страшно было, но все так, игра на самом деле использовала много ресурсов, которые генерировались на старте и загружались в память как текстуры/модели и т.д. Тормозила она скорее потому, что была бенчмарком и жирненькой, люди не на оптимизацию смотрели все же. Ну и да, речь о молотилке на старте, сама игра была ну скажем современной по тем временам
Андроид под капотом ведь линукс. Можно писать обычные бинарные библиотеки под эти платформы, есть NDK, есть много примеров к нему. Прежде всего он направлен конечно на переиспользование библиотек с других платформ и написание всяких высокоскоростных специализированных библиотек. Гугл не рекомендует его использовать, т.к это не платформонезависимо.
Пока выглядит самым реалистичным вариантом.
На самом деле основные проблемы, которые хотелось подчеркнуть, были именно организационными, а по поводу производительности мысли были лишь о том, что высокая производительность не стоит такой запутанной организации.
Но мне тут уже нормально так насыпали аргументов, что производительность вообще не важна, а организация на самом деле и есть основное преимущество.
Я с этим не согласен, но создать целую статью лишь с болью про организацию, особенно без хороших альтернатив (а сложные ООП проекты не будут так же содержать серебрянных пуль) я не готов.
Поэтому прошу прощения за неоправданные ожидания, в следующий раз постараюсь лучше.
В комментариях накидали много статей, в том числе разбирающих недостатки.
В моем опыте скорее аккуратный КОП является близким к идеалу.
Но есть несколько важных нюансов, в частности размер команды, количество в ней ГД и то, как принято работать с игрой с точки зрения ГД - есть ли полноценный левел дизайн и работают ли технические художники и неспециалисты с уровнями и префабами. Либо они допущены только до конфигураций.
В первом случае сосредоточиться на правильной декомпозиции и удобстве для последних на порядок важнее любой архитектуры и стандартные компоненты, ну ОК.
Глубокие иерархии (наследования) однозначно зло. А вот иерархии объектов очень нужны (в смысле когда один класс использует напрямую другие - отряд - юнит - оружие - пуля).
В этом контексте обычные способы декомпозиции предлагаемые ECS (типично иметь компонент-позицию, здоровье и компоненты-флаги, к примеру) превращают проект в сложную комбинацию эффектов, понять которые крайне сложно.
Из описаний выше с Match-3 примером как раз потребовалось осознать, что ECS подход сам по себе не поможет. А помогла логическая декомпозиция того, из чего состоит реальная фишка на состояние, эффект и взаимодействие. Условно на триггер и эффект, которые можно сочетать независимо.
Без этого код рос условиями каждый-к-каждому в том числе в ECS рос бесконтрольно и рожал много ошибок. Классический ООП тоже тут в общем то так же споткнулся бы.
Сейчас Я бы лучше использовал что-то типа анемичного объектного подхода, не пытаясь тащить инфраструктуру какого то ECS подхода.
Для проблемы веревки и проблемы декомпозиции вообще есть на самом деле простое решение - правило владения.
Решать должен тот, кто знает про все свои детали.
Соответственно в примере с веревкой ни юнит не содержит веревку, ни веревка - юнит, соответственно они не должны решать, как им взаимодействовать.
Кто тогда должен решать - другой вопрос, на который этот принцип ответа не дает)
Поинт всей статьи в том, что про то, как объект качается на веревке, придется задумываться в любом случае.
Сказать, что ECS решит это за вас, безо всяких орг практик, дисциплины и организации - портал в маленький ад.
Только ад не такой, как переусложненное ООП, а другой, когда ты не можешь найти концов и краев и все пули застревают в веревках, потому что при пролете на самом деле качаются на них.
Собственно и недостатки там те же перечислены, как и методы их решения, другой лишь фокус)
Для тру ООП как его многие представляют чрезмерная архитектурная космонавтика еще более характерна.
И плохая декомпозиция.
Но ярых фанатов в геймдеве я видел мало.
Но ООП призывает начать с этого и признает проблему плохой декомпозиции. Собственно и ECS и многие паттерны для этого и нужны - потому что рефакторить больно.
Но ECS конечно же призывает к ультрадекомпозиции. Посмотрите на представленные статьи - они буквально говорят о том, что надеваем прыгательный компонент и у нас все прыгает.
Совершенно без контекста того, как самые разные объекты могут взаимодействовать с прыганием тоже треш получится
Возможно биас вызван тем, что для ООП даже маленькие проекты изначально делаются с не очень качественной декомпозицией.
Ничего не мешает делать компонентную структуру на обычных unity компонентах, разделить их на маленькие части и комбинировать.
Но одна из важных мыслей моей статьи - ECS не решает эту проблему автоматически.
Так же и не приносит особых преимуществ на ранних стадиях - просто не используй ООП и пиши как попало, получишь ту же "все ко всем" декомпозицию
Мне кажется, что "если просто разделить данные и логику" - вот это тоже не правда.
Это подается как простое решение, фигячь как хочешь, всегда понятно, что и где добавить.
Проблема в том, что это не решает архитектурных проблем в организационной части.
Архитектура это не только что у меня есть данные и код, архитектура конкретной игры - это конкретно ваши сущности, ваши пули, юниты и что там еще есть.
Если это организовано само по себе разделение на логику и данные никак не влияет на то, что пуля должна наносить ущерб.
Мы использовали ECS как раз для match 3 и когда речь зашла про возможное взаимодействие каждого с каждым ECS был организован так же сложно. Тут ООП подход ломается влегкую, Я согласен, но решение находится на организационной стороне, нужно придумать хороший список абстракций, возможно разделить процесс на триггер и эффект и тому подобное. Решение которое не зависит от деталей организации.
И когда ты к нему приходишь, все равно придётся переписывать.
Вместе с тем статьи по ECS описывают все так, как будто проблемы не существует, надо лишь избавиться от ООП и все станет легко и приятно.
Вместе с тем, данные с процессами вместе соединяют не просто так.
Есть несколько представлений, со стороны которых можно работать - со стороны состояния и со стороны процесса.
И штуки как корутины, асинки, колбеки и прочие реактивные библиотеки придуманы для того, чтобы держать близко контекст процесса - действие за действием, которые можно обозреть.
ECS представляет все как один шаг тысячи ног одновременно, что может привести к аду, когда ты пытаешься понять поведение сущности.
В теоретическом абстрактном мире системы могут быть написаны независимо, чтобы можно было понять что происходит только по компоненту и системам, использующим его.
На практике чтобы понять поведение условно юнита, нужно развернуть в голове целый граф из многих компонентов и систем в нужном порядке, понять важные и не важные части и только потом получить данные, чтобы внести изменения.
ООП не идеален, но буквально заточен на эту изоляцию. ECS концептуально ее отвергает.
Возможно вы правы и во многих статьях упор действительно делается прежде всего на композицию и решение архитектурных проблем.
Тем не менее преимущества производительности подчеркивались тоже с ранних пор и многочисленные реализации, включая Unity ECS или ecs на rust напирают на это.
Я встречал это многократно и про это же говорит типичная реализация, в которой entity - это идентификатор, а не объект, а системы предназначены для обработки данных батчами.
По сути без этого ECS можно сделать на обычной юнити, просто используя GO и компоненты с публичными полями.
Эти реализации тащат определенные правила - обычно для систем сущности выбираются неким специальным механизмом фильтров, вызывающим систему только на определенном наборе компонент / единичном компоненте.
А работа с ссылками на сущности в обязательном порядке обрастает экстра кодом проверки наличия компонента на этой сущности.
И то и другое вместе с овердекомпозицией серьезно запутывает код.
Но это действительно может быть важной частью моих проблем с ECS, хотя я критикую и организационную часть.
С таким определением в других фреймворках таких проблем может и нет.
ОМГ, а что я тогда использовал?
Структуры и селекторы для классов были, но есть ощущение, что кодогенерация тоже была для гетеров.
Мой гет в том, что пилить и поддерживать на нем гораздо проще только прототип.
А дальше это становится кучей кода с компонентным аналогом event-hell, который очень тяжело понимать и обслуживать, потому что инструментов организации, помимо нейминга, практически нет.
Про веревку это правда.
Но так же легко потом пули на веревках качаются, потому что забыл, что компонент, ответственный за это, переиспользуется там.
Хм, а можно вопрос, вы разрабатываете проекты один или в команде?
Моя проблема с ECS в том, что нельзя изменить все в произвольном направлении из-за когнитивной сложности - буквально крайне тяжело понять, как работает условная абстракция, если ее писал не ты.
То есть такая проблема везде есть, конечно же, просто в ецс с произвольным разделением чтобы понять поведение, условно, юнита, нужно в голове поднять целый граф объекта - все компоненты позиции, здоровья, статусы и флаги.
И несколько систем, обязательно в нужном порядке, потому что порядок, очевидно, критичен.
В итоге любой процесс (скажем, получение урона, вместе со всеми деталями - просчетом доп типов урона, смертью персонажа, анимацией попадания и прочего) размазано по десятку систем.
По факту компоненты флажки используются как переменные связывания вместо функций по порядку или событий.
В итоге на ровном месте ты получаешь аналог event-hell.
У меня есть стойкое ощущение, что люди живут с этим event-hell и такие "I'm fine", просто потому, что не знают, что есть методологии, как уменьшить это.
Но это ведь сложно - правильные архитектуры нужно делать.
В итоге на самом деле решения на ECS имеют архитектуру - это просто нотации и договоренности в команде, может документация, что за чем следует и какие окончания у компонентов, заведующих событиями. И так как инструментальных решений организовать это нет или мало, на самом деле это увеличивает требования к архитектуре.
Если же ты вываливаешься за пределы упорядоченных систем, например если нужны сложные связи или дерево - это как писать на сырых ссылках в C++, тебе нужно проверять каждый объект на наличие компонент и возможность обработки.
Хм, ваша правда, Я спутал entitas и Leo ECS
И да, Entitas очень сосредоточен на производительности - он использует массивы структур, сложную систему запросов для выбора систем обработки компонентов и кодогенерацию.
Мой основной опыт это Entitas и несколько самописных решений, Я не использовал Unity-ECS в коммерческих проектах.
Это отчасти правда, но я не согласен с этим потому, что изначально эта архитектура была ассоциирована с решением проблем производительности.
Cама концепция систем сосредоточена на пакетной обработке компонентов, иначе их бы можно было бы назвать командами и применять к отдельной паре компонентов. Есть известная цитата про нарезку хлеба (с которой я не согласен).
Вторичная система индексации, когда у вас есть Entity и это просто индекс, так же направлена на это, иначе можно было бы просто использовать ссылку на объект entity.
Все это вместе дает свою философию доступа к объектам, которая отличается от просто доступа по ссылке.
Если бы речь шла только про декомпозицию и отделение данных от логики, вы бы могли (и можете) организовать это на обычных компонентах unity + системах, в этом смысле она и так entity-component.
Но в целом, значительная часть моей критики и направлена на то, что ультрадекомпозиция и отделение данных от логики по умолчанию - это плохое решение, которое в долгосрочной перспективе сделает проект крайне сложным для обслуживания.
Так что да, Я критикую и эту часть тоже)
Вы не правы в том, что производительность не ассоциирована с ECS.
Практически все ее упоминания или реализации на этом сосредоточены и так было с момента ее создания.
Cама концепция систем сосредоточена на пакетной обработке компонентов, иначе их бы можно было бы назвать командами и применять к отдельной паре компонентов.
Есть известная цитата про нарезку хлеба (с которой я не согласен).
Вторичная система индексации, когда у вас есть Entity и это просто индекс, так же направлена на это, иначе можно было бы просто использовать ссылку на объект entity.
Безусловно важным фактором является и разделение логики и данных - и, на самом деле, я критикую это не в последнюю очередь как способ создать реально сложные и плохо обслуживаемые решения, когда из-за позднего связывания порядка систем и очень сильной декомпозиции элементов просто тяжело понять, что происходит.
Остальные факторы могут быть достигнуты без ECS:
Composition over inheritance является хорошей практикой и в современном ООП сообществе, глубокие иерархии очень хрупкие.
По сути обычная среда Unity - это composition over inheritance, это, можно сказать, entity-component архитектура.
Для достижения гибкости не нужна полная ECS, достаточно просто компонентов и Data-Driven дизайна, когда игровые сущности можно собирать из кусочков ориентируясь на данные.
Именно поэтому все современные движки это так или иначе дерево узлов и компоненты на них.
Анемичный дизайн, когда логика и данные развязаны, тоже много где характерен и для него не требуется волшебства.
Хранимое состояние - опять же, для этого нужны какие то общие методы сериализации и десериализации объектов, а не вся архитектура.
Не в последнюю очередь моя статья про то, что разделение логики и данных кажется хорошей идеей, но возможно это только кажется.
ООП буквально придуман для того, чтобы собрать это вместе по хорошей причине - локальность данных и кода, защита целостного состояния объекта. Безусловно это может мешать, создавать хорошие абстракции непросто, но вы можете регулировать уровень этой локальности. Без этой абстракции создавать хорошие абстракции совершенно нереально.
Я бы не сказал, что сложные задачи, где нужны гибкие отношения многих ко многим сильно упрощаются в ecs
Все так, ваши страхи не безосновательны.
Видимо нам еще предстоит осознать проблему и придумать новые правила цифровой гигиены и правильных продуктов.
Пока же да, то, что вы описали примерно так и работает - манипуляциями и ограничениями, переводом фокуса и запретами.
Плохо кароче работает.
Ну не так там все страшно было, но все так, игра на самом деле использовала много ресурсов, которые генерировались на старте и загружались в память как текстуры/модели и т.д.
Тормозила она скорее потому, что была бенчмарком и жирненькой, люди не на оптимизацию смотрели все же.
Ну и да, речь о молотилке на старте, сама игра была ну скажем современной по тем временам
Андроид под капотом ведь линукс.
Можно писать обычные бинарные библиотеки под эти платформы, есть NDK, есть много примеров к нему.
Прежде всего он направлен конечно на переиспользование библиотек с других платформ и написание всяких высокоскоростных специализированных библиотек.
Гугл не рекомендует его использовать, т.к это не платформонезависимо.