Войти
ПроектыФорумУтилиты

ECS для своей игровой инфраструктуры (C++)

Страницы: 1 2 Следующая »
#0
8:31, 9 фев 2021

Потихоньку осваиваю кресты и формирую инфраструктуру для разработки игр.

Готов первый крупный компонент инфраструктуры, на котором все будет базироваться - ECS фреймворк.
https://gitlab.com/kkolyan/npecs/

  • без зависимостей
  • headers-only
  • gcc, msvc, clang
  • без привязки к платформам (тестировал только на Windows)
  • C++17
  • неплохое покрытие тестами
  • Перечень фич и инструкция

    Вдохновлялся дизайном и идеями LeoECS.

    Старался сделать хорошо и эстетично, но в крестах я зелен и свеж - буду признателен любой критике и замечаниям.


    PS: на самом деле, был еще нулевой шаг - небольшой json-парсер, но это для совсем щедрых на ревью людей.

    #1
    11:09, 9 фев 2021

    Выглядит неплохо. Не хватает перечисления списка фич и лицензии.
    По мне только очень много мелких файлов. Я бы всё в один хедер запихнул. Это сделает его подключение к проекту проще и отвяжет от CMake. Например так даже делает EnTT, у которого кода в 10 раз больше.

    Я недавно захотел воскресить свой заброшенный 5 лет назад движок, и одна из первых вещей в моём списке дел - заменить его кривую и недоделанную компонентную систему на ECS. Как раз было интересно посмотреть, сколько времени/строк кода займёт минимальный фреймворк.

    #2
    12:48, 9 фев 2021

    gammaker
    спасибо) лицензию добавлю.

    > Не хватает перечисления списка фич
    дак а нечего перечислять... из списка фич, который декларирует ENTT, у меня нет ни одной) только самое базовое без чего ECS просто немыслим... showcase недостаточно нагляден?

    > По мне только очень много мелких файлов. Я бы всё в один хедер запихнул. Это сделает его подключение к проекту проще и отвяжет от CMake.
    действительно, 4 cpp-шки ни к селу ни к городу получаются и без cmake их не очень сподручно подключать. по всей видимости, их стоит превратить в темплейты, добавив фейковый параметр, спасибо за замечание!

    но не совсем понял, почему объединение в _один_ хедер упростит подключение? есть аггрегирующий хедер npecs.hpp, который в себя включает все-все-все (не считая cpp-шек, которые я уберу). объединение прямо в один хедер упростит разве что копипасту файлика...

    > Например так даже делает EnTT, у которого кода в 10 раз больше.
    видимо раньше делал, т.к. сейчас  у них сорцы разбиты на 53 файла, в среднем по ~300 строк.

    > Как раз было интересно посмотреть, сколько времени/строк кода займёт минимальный фреймворк.
    пилил две недели по 3-4 часа в день. примерно 90% времени заняла шлифовка параллельно с написанием тестов.

    #3
    13:38, 9 фев 2021

    Интересненько, только не всём подойдет ... кстати зачем так жаттоо форматировать код? Нечитабельно ведь ... + дописывай для функций которые могут выкинуть noexcept (false), тогда коментарий становится лишним.

    #4
    14:08, 9 фев 2021

    Ждём: кучи, фильтрация сразу по двум компонентам (возможно это тоже самое: свободная группировка). Например выделить тех юнитов которые держат копьё и при этом без работы.
    Подмена компонента или сущности (думаю это понятно, копирование свойств и в другой компонент или сущность). Сортировка ещё нужна. Указать сразу 25000 объектов для пула (allocate?) и их полное наполнение. Потестю даже под UE)
    Ну а если ещё будет c# прокладка, то проброшу во все проекты.

    #5
    15:17, 9 фев 2021

    Salamandr
    > ждем кучи
    в каком смысле?

    > фильтрация сразу по двум компонентам (возможно это тоже самое: свободная группировка). Например выделить тех юнитов которые держат копьё и при этом без работы.
    видимо имеешь в виду Exclude по компоненту. такое придется запилить, да)

    > Подмена компонента или сущности (думаю это понятно, копирование свойств и в другой компонент или сущность)
    зачем это во фреймворке? что из этого неудобно делать просто средствами языка?

    > Сортировка ещё нужна
    а какая именно и для чего?

    > Ну а если ещё будет c# прокладка, то проброшу во все проекты.
    зачем?) для C# есть LeoECS.

    #6
    15:19, 9 фев 2021

    Aviator777
    что именно не так с форматированием?) есть какой-то годный гайдлайн или просто пример хорошо отформатированного на ваш взгляд кода?

    Aviator777
    > дописывай для функций которые могут выкинуть noexcept (false), тогда коментарий
    > становится лишним.
    ну как же лишним) я же коментом описываю в каких именно случаях будут исключения. noexcept(false), я так понимаю, лишь даст сигнал что исключения в принципе могут быть.

    #7
    15:38, 9 фев 2021

    Aviator777
    > кстати зачем так жаттоо форматировать код? Нечитабельно ведь
    А где ты там сжатость нашел? Все отлично и читабельно. Это ж вкусовщина чистая.

    #8
    16:16, 9 фев 2021

    Aviator777
    > кстати зачем так жаттоо форматировать код?
    Хорошо отформатирован код, приятно читать.

    #9
    17:11, 9 фев 2021

    Работаю по 7 - 10 часов в сутки с С++ кодом, не знаю как вам остальным, но как-то проще  орентироватся в коде когда блоки {} отделены от строк кода, когда в начале класса идут всё публичные елементы потом, защищенные и только потом приватные.

    class Entity
    {
      public:
        Entity( Storage* pStorage, const EntityKey& key );
        
      private:
        EntityKey m_key { EntityKey::SOME_DEFAULT };
        Storage* m_pStorage {};
    };
    
    
    Entity::Entity( Storage* pStorage, const EntityKey& key ) 
      : m_pStorage{ pStorage }
      , m_key{ key } 
    {
      doSomethhingSmall();
    }

    На работе используем модифицированный К&R пока что самое лучшее что встречал, возможно я слишком привык :D

    #10
    17:57, 9 фев 2021

    kkolyan
    > в каком смысле?
    объединение по нескольким фильтрам. Облако, куча.

    > видимо имеешь в виду Exclude по компоненту
    я имею ввиду что на сущности висит: Health, Position, UnitWeaponSpear, FreeForWork, UnitStateStay. Мне нужна не выборка цикла в цикле, а лишь проверка на то что оба этих компонента присутствуют на сущности. Допустим: (Health + Position) или (FreeForWork + UnitWeaponSpear + UnitStateStay), и лишь тогда добавляем его в список для меня.

    > Сортировка ещё нужна
    например по расстоянию до цели (да это я могу реализовать конечно и сам)

    kkolyan
    > зачем?) для C# есть LeoECS.
    чтобы мне не приходилось писать разный код, а использовать существующие (наработанные) файлы в своих будущих проектах (на любом языке, но для начала C++ и C#). Ведь модель построения будет в принципе похожа даже для разных жанров, режимов. В этом и принцип ECS, долго писать, а потом просто юзаешь готовые решения.

    #11
    17:58, 9 фев 2021

    kkolyan
    > но не совсем понял, почему объединение в _один_ хедер упростит подключение?
    gammaker
    > отвяжет от CMake

    Отвяжет от смаке, волочёшь?
    Потребитель просто скопирует твой каталог в свой проект, напишет у себя #include "xxx" и сможет сразу приступить к работе, избежав тягомотины с редактированием сценариев сборки или какого-либо другого подключения файлов к своему проекту.
    Хотя пути прописать всё равно придётся, это да.

    #12
    18:14, 9 фев 2021

    Salamandr
    > объединение по нескольким фильтрам. Облако, куча.
    не понимаю. облако - это  облачные вычисления? куча - это тип памяти? ну она есть и активно используется.

    Salamandr
    > я имею ввиду что на сущности висит: Health, Position, UnitWeaponSpear,
    > FreeForWork, UnitStateStay. Мне нужна не выборка цикла в цикле, а лишь проверка
    > на то что оба этих компонента присутствуют на сущности. Допустим: (Health +
    > Position) или (FreeForWork + UnitWeaponSpear + UnitStateStay), и лишь тогда
    > добавляем его в список для меня.

    это только так и работает)

    for (ViewCursor<A,B> cursor : world.getView<A,B>()) {
      // этот код вызовется ровно столько раз, сколько есть энтити на которых есть и компонент A и компонент B. 
      // при этом через cursor можно быстро получать эти самые компоненты (и медленно любые другие)
    }

    > > Сортировка ещё нужна
    > например по расстоянию до цели (да это я могу реализовать конечно и сам)
    пока хочу без этого попробовать. вообще ускоряющие структуры удобнее выносить из ECS (например в отдельные монолитные компоненты, либо вообще внешние ссылки)

    > чтобы мне не приходилось писать разный код, а использовать существующие (наработанные) файлы в своих будущих проектах (на любом языке, но для начала C++ и C#).
    я правильно понимаю, что ты предлагаешь встроить в фреймворк среду исполнения для C# (CLR/Mono) для того чтобы можно было к проекту подключать код на C# без изменений?

    > В этом и принцип ECS, долго писать, а потом просто юзаешь готовые решения.
    по-моему принцип ECS в другом :)

    #13
    18:17, 9 фев 2021

    kkolyan
    > для того чтобы можно было к проекту подключать код на C# без изменений?
    для того чтобы можно было подключить dll к Unity и кодить на c# с тем же функционалом твоей ECS.

    #14
    18:18, 9 фев 2021

    Phuntik
    > Потребитель просто скопирует твой каталог в свой проект, напишет у себя
    > #include "xxx" и сможет сразу приступить к работе, избежав тягомотины с
    > редактированием сценариев сборки или какого-либо другого подключения файлов к
    > своему проекту.

    вы объясняете почему мне нужно избавиться от cpp-файлов. а вопрос в том, зачем склеивать мои 30 hpp-файлов в один.

    boost, doctest и entt отлично подключаются как вы говорите, без cmake, при этом они состоят из большого кол-ва hpp-файлов.

    Страницы: 1 2 Следующая »
    ПроектыФорумУтилиты

    Тема в архиве.