Ключевые моменты ECS, о которых не пишут на Википедии. Никита Ильин, Gameplay programmer, Larian

Фестиваль для разработчиков компьютерных и мобильных игр Сибири

[playrix]

Хороший доклад. В общем-то все они примерно одинаковые, про одно и то же, только больше нюансов раскрывают. К какому-то моменту понимаешь, что достаточно насытился, что точнее знания появятся только, когда уже поработаешь с подходом. Однако в этот момент будет куда проще.

[AsusIks]

Сразу понятно стало и про ооп, и про ецс

[myownchannellol]

Хороший спикер, любопытный доклад, особенно для тех, кто не знаком с ECS.
Касательно части про ECS можно придраться, но как введение материал подан хорошо и лаконично. Однако как только разговор переходит на поле ООП, хочется сказать: "вы явно не умеете его готовить".
Здесь ООП выступает как кукла для битья, чтобы усилить достоинства ECS. Причём рассматриваются ситуации и архитектурные решения уровня первого курса университета. Особенно смешно, когда вечно вспоминается этот пресловутый "Character на 10т строк кода". Да говнокод это, самый настоящий. Такой же говнокод можно и в ECS построить, а потом на фоне говорить, какой классный ООП.
В нормальном ООП не будет в классе Character лежать и HP, и код полёта и всё остальное. В нормальном ООП не будет такого бедового наследования, которое было продемонстрированно.
И куски кода для GDC, которые забыли удалить. А при чём тут ООП? Такие куски кода могут появляться независимо от архитектуры перед каждым GDC. И решается это всё использованием специальной ветки для GDC в VCS, которую потом можно удалить.
Понятно, что пример больше про "легче масштабировать и итерировать", но в правильно приготовленном ООП это всё учтено. Простое наличие ECS не предоставляет этого.
Огромное количество проектов реализовано на ООП и продолжает реализовываться. Вряд ли люди в топовых студиях "просто не знают про ECS". Знают. Просто они умеют готовить и то, и другое. И понимают, что ECS - это инструмент для конкретных задач, а не для всей индустрии.

[playrix]

Из забавного я замечаю, что отложенность выполнения прикольно проявляется в многопользовательских шутерах: ты видишь одно, ты проскочил мимо вражеского выстрела, даже успел заскочить за стену и включить хил, но потом с сервера приходит результат вычисления урона, и выясняется, что нет, не проскочил

[DobinSergei]

А разве этот вопрос уже не был решён давно? Например старые игры со сложными механиками - т.н. рогалики.
Весь игровой мир там строится из сущностей. При этом с любой сущностью можно делать любые возможные действия, в любое время изменять св-ва.
А св-ва это список, в котором хранятся все особенности (feature). Это структуры, у которых есть разные поля данных, например задержка до респавна, кол-во ОЗ, указатель на владельца, и т.п. И у всех первое поле это переменная перечисляемого типа (enum) - идентификатор типа особенности, по которому мы понимаем какие ещё есть поля. Для особенностей типа есть-нет (флаг) вообще не требуются поля, достаточно наличия самой особенности.
И всё это можно выполнить даже без ООП, на обычных структурах.
Правда это хорошо работает только в относительно небольшом кол-ве сущностей, т.к. при каждом обращении к св-ву производится его поиск в списке.