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

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

[@playrix6774]

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

[@AsusIks]

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

[@playrix6774]

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

[@zax2100]

Спасибо

[@myownchannellol]

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

[@nognomar]

Заранее прошу прощения за некропостинг, но хотелось бы узнать про "правильное ооп" в играх. Не являюсь "адептом ецс" (равно как и ооп, ибо считаю что нужно выбирать инструмент под задачу, а не подгонять задачу под инструмент), но к сожалению был свидетелем такого вот "неправильного ооп" во многих крупных проектах, как мобильных так и ААА. И вот очень часто под каким-нибудь докладом или статьей про ECS вижу комментарии вида "вы не умеете в ООП, там нет этих проблем" - но к сожалению почему то авторы подобных коментариев никак не желают поделиться примерами "правильного ооп" в больших проектах с кучей так или иначе пересекающихся систем. Было бы неплохо услышать где же нужно хранить HP и код полета character-a если не в самом character-е? Потому что ООП обычно как раз учит этому, разве нет? Потому что если сторонние системы изменяют внутреннее состояние объекта извне - то это фактически нарушение инкапсуляции. Разумеется под "хранить HP и код полета внутри" я не подразумеваю буквальный хардкод всей сопутствующей логики внутри класса Character - пусть все эти компоненты будут инкапсулированы в собственных типах аля Health и Movement, сути дела не меняет, по канонам ООП класс Character так или иначе должен хранить эти компоненты в себе, и доступ к ним снаружи должен быть максимально ограничен. С остальными доводами согласен, про GDC совсем странно и уж естественно не стоит брать и бежать все переделывать просто потому что ecs

[@karimkimsanbaev7932]

Согласен с обоими сторонами, очень интересный ход мыслей. Правильного ООП не видел. Но и примеров ООП как в видео тоже не видел. Пример с грузовиком и самолётом - означает, что если используете наследование - вы знаете на что идёте. Поэтому наследование плохая практика и лучше композиция. Но коммон пример с грузовиком и самолётом от силы раз в год. Если больше - мб не так выводите абстракции или гейм дизайнера часто штормит)

[@vlader776]

@@nognomarво-первых существует MVx, который позволяет выстраивать над unity объектно-ориентированную модель, а view это монобэхи, которые можно поделить под анимации, звуки и тд. А зависимости раскидывает DI. А предоставленный на видео вариант ООП я называю детским. Красивого проектирования нуль

[@nognomar]

@@vlader776 оо, Забавно слышать когда тебя называют нулем, но сами весь набор MVx паттернов подвели под одну гребёнку... А зависимости "раскидывает DI" - с этого вообще в голос. Сразу видно эксперта-архитектора, сути проблемы не увидел, но гонору и самомнения через край.

[@vlader776]

@@nognomar Прошу заметить на личности я не переходил. Просто назвал пример с character, у которого в зависимостях Health и Movement, слишком простым примером, которыми обычно начинают учить использовать ооп. В реальной разработке строятся более сложные абстракции и классы на 10тыс строк кода с высокой связанностью уж точно не будет. В итоге, все сводится к тому, что поддерживать адекватно сделанный продукт становится легко и плюсов использовать ECS становится куда меньше, отсюда следует большое количество вакансий, где требуются знание именно ооп, а не ECS. Если бы была в действительности такая скудная реализация ооп в геймдеве, то при разработке учили только ECS. А MVx шаблоны за собой имеет единый смысл, а выбор конкретного исходит из конкретного проекта. А DI мощный инструмент для поддержки сложного продукта, который используется не только в ООП, но и в ECS. Следовательно, я не совсем понимаю ваших претензий к комментарию выше. А раз вам было смешно, то это свидетельствует о вашей некомпетентности

[@DobinSergei]

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