Nano Hash - криптовалюты, майнинг, программирование

Компонентная разработка игрового движка

Я изучаю дизайн игрового движка (в частности, ориентированный на 2-мерные игровые движки, но также применимый к 3d-играм), и меня интересует некоторая информация о том, как это сделать. Я слышал, что в настоящее время многие движки переходят на компонентный дизайн, а не на традиционную иерархию глубоких объектов.

Знаете ли вы какие-либо хорошие ссылки с информацией о том, как часто реализуются подобные конструкции? Я видел, как менял вашу иерархию, но не могу найти гораздо больше с подробной информацией (большинство из них, кажется, просто говорят «используйте компоненты, а не иерархию», но я обнаружил, что требуется немного усилий, чтобы переключить мое мышление между двумя моделями).

Приветствуются любые хорошие ссылки или информация по этому поводу, и даже книги, хотя ссылки и подробные ответы здесь были бы предпочтительнее.

architecture game-engine entity-component-system entity-system
14.12.2009

Ответы:


1

Обновление 2013-01-07: Если вы хотите увидеть хорошее сочетание компонентного игрового движка с (на мой взгляд) превосходным подходом реактивного программирования, взгляните на движок V-Play. Он очень хорошо интегрирует привязку свойств QML QT.

Мы провели небольшое исследование CBSE в играх в нашем университете, и за эти годы я собрал некоторые материалы:

CBSE в игровой литературе:

  • Архитектура игрового движка
  • Жемчужины программирования игр 4: система для управления игровыми объектами.
  • Жемчужины программирования игр 5: Управление объектами на основе компонентов
  • Жемчужины программирования игр 5: Универсальная библиотека компонентов
  • Жемчужины программирования игр 6: Система компонентов игровых объектов
  • Объектно-ориентированная разработка игр
  • Architektur des Kerns einer Game-Engine и реализация на Java (немецкий)

Очень хорошим и понятным примером компонентного игрового движка на C # является игровая среда Elephant.

Если вы действительно хотите знать, какие компоненты читаются: Разработка программного обеспечения на основе компонентов! Они определяют компонент как:

Программный компонент - это программный элемент, который соответствует модели компонента и может быть независимо развернут и составлен без модификации в соответствии со стандартом композиции.

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

Инфраструктура программных компонентов - это набор взаимодействующих программных компонентов, предназначенных для обеспечения того, чтобы программная система или подсистема, построенная с использованием этих компонентов и интерфейсов, удовлетворяла четко определенным характеристикам производительности.

Я считаю, что после 2 лет опыта использования CBSE в играх, объектно-ориентированное программирование - это просто тупик. Вспомните мое предупреждение, наблюдая, как ваши компоненты становятся все меньше и меньше и больше похожи на функции, упакованные в компоненты, с большим количеством бесполезных накладных расходов. Вместо этого используйте функционально-реактивное программирование. Также ознакомьтесь с моим новым сообщением в блоге (которое привело меня к этому вопросу, когда я его писал :)) о Почему я перешел с компонентной архитектуры игрового движка на FRP.

CBSE в игровых статьях:

CBSE в веб-ссылках игр (по релевантности):
16.08.2010
  • Мне сложно найти ресурсы по FRP, связанные с игровыми движками. Можете ли вы предоставить код или ссылки? 17.10.2010
  • FRP - это небольшая область в целом, особенно в играх. Существовал уже много лет, но все еще довольно передовой. Если вы будете искать в функциональном реактивном программировании связь с языком Haskell, вы найдете большую часть исследований по нему. Ключевые проекты - Fruit, Fran и Yampa. Yampa Arcade - это статья, в которой описывается использование реактивной библиотеки Yampa в играх. Я не слышал о каких-либо реальных реализациях, кроме, возможно, некоторых вещей Silverlight с использованием новых реактивов .NET. 22.10.2010
  • Это отличный ответ, спасибо, что познакомили меня с FRP. Однако я бы сказал новичкам: переходите на функциональное программирование или программирование на основе прототипов ... Тогда я бы сказал: И в качестве дополнительного бонуса используйте FRP, если вы выбираете FP. 25.04.2011
  • Очень хорошим и понятным примером компонентного игрового движка на C # является игровая среда Elephant. Он так и не был закончен, и он не решает никаких реальных проблем, таких как взаимодействие между компонентами / объектами. 22.07.2011
  • Я являюсь автором Elephant-thingie, и, прежде чем кто-то решит использовать эту старую штуку, я хотел бы отметить, что я выпустил альтернативу под названием ComponentKit. Хотя в нем нет ничего, связанного с игрой, это, по крайней мере, полезный справочник о том, как можно реализовать такую ​​систему. 25.01.2012
  • @ JacobH.Hansen Забавно, на днях я просмотрел этот пост, а сегодня вернулся, чтобы просмотреть еще несколько ссылок, и увидел новый пост! Я собираюсь взглянуть на ваш ComponentKit. Как вы справляетесь с общением? Только с делегатами? 27.01.2012
  • Я прочитал это как Программный компонент - это программный слон .. слишком устал 21.11.2012
  • Хороший обзор информации и ссылок, спасибо! Раньше я много читал t-machine.org/index.php/2007/09/03/ (на который вы ссылаетесь выше) и нашел его очень полезным. 10.10.2014
  • отличный пост, желаю, чтобы он был более свежим 01.04.2015

    • 2

    Похоже, что информации по этому поводу действительно не хватает. Я недавно внедрил эту систему и нашел действительно хороший GDC Powerpoint, который довольно хорошо объяснил детали, которые часто остаются позади. Этот документ находится здесь: Теория и практика архитектуры компонентов игровых объектов < / а>

    В дополнение к этой Powerpoint есть несколько хороших ресурсов и различные блоги. PurplePwny имеет хорошее обсуждение и ссылки на некоторые другие ресурсы. В Ugly Baby Studios есть небольшая дискуссия о том, как компоненты взаимодействуют друг с другом. . Удачи!

    14.12.2009
  • +1 за тот первый powerpoint, очень заставляет задуматься! 06.04.2010
  • @Noah: Ссылка на GDC ppt не работает, у вас есть ppt в наличии где-нибудь еще? :-) 18.04.2012
  • На данный момент нет, но когда выйду с работы, я покопаюсь и посмотрю, не поместил ли где-нибудь резервную копию. 25.04.2012
  • Хех, скачал ppt (ссылка работала), потом понял, что присутствовал на выступлении 5 лет назад, спасибо за напоминание. В общем, будьте осторожны, не добавляйте слишком много поведения в свои компоненты, это приведет к спагетти-коду и возможному безумию. Отдавайте предпочтение тупым компонентам, которые хранят данные, и передавайте свое поведение процессорам сущностей. 10.10.2014

    • 3

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

    12.07.2010

    4

    Это открытый исходный код, доступный по адресу http://codeplex.com/elephant.

    Кто-то сделал рабочий пример кода gpg6, вы можете найти его здесь: http://www.unseen-academy.de/componentSystem.html

    или здесь: http://www.mcshaffry.com/GameCode/thread.php?threadid=732

    С уважением

    02.04.2010
  • первая ссылка была перемещена сюда: unseen-academy.de/snippet_component_system.html , видимо. 18.01.2012

    • 5

    В настоящее время я исследую именно эту тему во многих (МНОГИХ) темах на GameDev.net и нашел следующие два решения, которые станут хорошими кандидатами на то, что я буду разрабатывать для своей игры:

    17.07.2010

    6

    Я исследовал и реализовал этот последний семестр для курса разработки игр. Надеюсь, этот пример кода укажет вам правильный путь к этому. 

    class Entity {
public:
    Entity(const unsigned int id, const std::string& enttype);
    ~Entity();

    //Component Interface
    const Component* GetComponent(const std::string& family) const;
    void SetComponent(Component* newComp);
    void RemoveComponent(const std::string& family);
    void ClearComponents();

    //Property Interface
    bool HasProperty(const std::string& propName) const;
    template<class T> T& GetPropertyDataPtr(const std::string& propName);
    template<class T> const T& GetPropertyDataPtr(const std::string& propName) const;

    //Entity Interface
    const unsigned int GetID() const;
    void Update(float dt);

private:
    void RemoveProperty(const std::string& propName);
    void ClearProperties();
    template<class T> void AddProperty(const std::string& propName);
    template<class T> Property<T>* GetProperty(const std::string& propName);
    template<class T> const Property<T>* GetProperty(const std::string& propName) const;

    unsigned int m_Id;
    std::map<const string, IProperty*> m_Properties;
    std::map<const string, Component*> m_Components;
};

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

    05.09.2010
  • Итак, вы используете свойства компонентов, чтобы общаться друг с другом? Не нарушает ли этот подход инкапсуляцию? В основном вы используете свойства как набор глобальных переменных. 22.09.2010
  • В дополнение к комментариям happy_emi вы только что обменяли большие накладные расходы на передачу сообщений, под которыми, я полагаю, вы имеете в виду поиск строк и плохую согласованность кеша, на большие накладные расходы, связанные со свойствами. Компонентная половина вашей реализации выглядит нормально, но свойство-половина не имеет смысла - либо создайте те реальные поля в вашей Entity, которые компоненты могут устанавливать, либо сохраните межкомпонентные ссылки. 23.09.2010
  • Свойства просматриваются только при создании компонентов и сохраняются в виде указателя. Получение общих данных об объекте требует единовременной платы. Данные являются глобальными только в том смысле, что все компоненты имеют доступ к любым нужным им данным в своей сущности. Я говорю не только о поиске строк, но и о вызываемом дополнительном коде. Помните, что в вашей игре может быть огромное количество сущностей. Передача сообщения каждой сущности для обновления их позиции в каждом игровом цикле - это много бесполезных накладных расходов, когда вы можете просто указать компоненту, устанавливающему данные. 27.09.2010
  • Может быть, поможет пример. Скажем, у вашей сущности есть компонент Pathing и компонент Rendering, оба нуждаются в местоположении Vec3. Порядок произвольный, но предположим, что сначала создается компонент Render. Render запрашивает у объекта свойство местоположения Vec3, которое создается на объекте, и указатель передается на Render. Теперь создается Pathing, он запрашивает то же местоположение Vec3, а объект возвращает указатель свойства (фактически необработанные данные внутри свойства), которое он только что создал. На этом этапе, когда Pathing обновляет местоположение, Render может рисовать, не запрашивая новые данные о местоположении. 27.09.2010

    • 7

    В этом контексте компоненты для меня кажутся изолированными частями времени выполнения движка, которые могут выполняться одновременно с другими компонентами. Если это мотивация, то вам стоит взглянуть на модель акторов и системы, которые используют этого.

    14.12.2009

    8

    Интересное искусство ...

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

    http://www.unseen-academy.de/componentSystem.html
    http://www.mcshaffry.com/GameCode/thread.php?threadid=732
    http://www.codeplex.com/Wikipage?ProjectName=elephant

    Кроме того, в самих комментариях содержится довольно подробное обсуждение того, как можно кодировать такую ​​систему.

    14.12.2009
    Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..