Я бы не брался говорить что есть прям правильный и неправильный путь
Есть оптимальные и нет.
Главное, на мой взгляд, в ecs- это организовать быструю итерацию по компонентам и быстрый доступ к данным.
Система это просто функция которая обновляет данные в компонентах. Сущность - просто хэндл, вокруг которого компоненты объединены.
Дальше начинаются варианты реализации хранения: массивы, архетипы, соа/аос, свои контейнеры и т.п. А то как организованы системы у каждого может быть своё виденье в зависимости от решаемых задач.
Можно почитать документацию по entt или flecs, например, что бы получить какое то представление. У моей ecss тоже есть документация, ее можно найти в гитхабе. Это даст представление.
Абсолютно верное уточнение что map это не array, сразу после блока с кодом я об этом пишу :)
Этот пример был призван проиллюстрировать реальный способ поиска компонента по его id, но естественно это не оптимальный подход.
Это cpp подобный псевдокод, он не должен собираться, он лишь показывает концепцию.
В случае с ecs нам часто нужно несколько компонентов сразу в одной системе, системой может являться обычная функция, для наглядности псевдокод обновляет данные через системы передавая их в них напрямую.
В следующий раз добавлю пометку "псевдокод", спасибо за фидбек!
Возник вопрос: если провести параллель с C++ - где у нас есть системные threads и примитивы синхронизации вроде mutex/condition_variable - то как виртуальные потоки в Java взаимодействуют с настоящими системными потоками под капотом?
Есть ли там какая-то «скрытая» синхронизация на уровне carrier-threads? Например, пулы, мьютексы, шедулинг очередей задач? Или виртуальный поток полностью избегает тяжёлых блокировок и переключается без участия ОС?
Я бы не брался говорить что есть прям правильный и неправильный путь
Есть оптимальные и нет.
Главное, на мой взгляд, в ecs- это организовать быструю итерацию по компонентам и быстрый доступ к данным.
Система это просто функция которая обновляет данные в компонентах. Сущность - просто хэндл, вокруг которого компоненты объединены.
Дальше начинаются варианты реализации хранения: массивы, архетипы, соа/аос, свои контейнеры и т.п. А то как организованы системы у каждого может быть своё виденье в зависимости от решаемых задач.
Можно почитать документацию по entt или flecs, например, что бы получить какое то представление. У моей ecss тоже есть документация, ее можно найти в гитхабе. Это даст представление.
Привет!
Абсолютно верное уточнение что map это не array, сразу после блока с кодом я об этом пишу :)
Этот пример был призван проиллюстрировать реальный способ поиска компонента по его id, но естественно это не оптимальный подход.
Это cpp подобный псевдокод, он не должен собираться, он лишь показывает концепцию.
В случае с ecs нам часто нужно несколько компонентов сразу в одной системе, системой может являться обычная функция, для наглядности псевдокод обновляет данные через системы передавая их в них напрямую.
В следующий раз добавлю пометку "псевдокод", спасибо за фидбек!
Привет! Добавлю такой кейс и поисследую возможные оптимизации
у меня итерация идёт по первому компоненту из списка в for, и в таком кейсе будет 5000 итераций
Второй компонент может быть nullptr, это можно проверить простым ифом
Крутая статья, спасибо!
Возник вопрос: если провести параллель с C++ - где у нас есть системные threads и примитивы синхронизации вроде mutex/condition_variable - то как виртуальные потоки в Java взаимодействуют с настоящими системными потоками под капотом?
Есть ли там какая-то «скрытая» синхронизация на уровне carrier-threads? Например, пулы, мьютексы, шедулинг очередей задач? Или виртуальный поток полностью избегает тяжёлых блокировок и переключается без участия ОС?
вместо тысячи слов