Компонентный дизайн игрового движка
Я занимался дизайном игрового движка (специально ориентированного на двухмерные игровые движки, но также применимого к трехмерным играм), и мне интересна некоторая информация о том, как это сделать. Я слышал, что многие движки в настоящее время переходят на компонентный дизайн, а не на традиционную иерархию глубоких объектов.
Знаете ли вы какие-нибудь хорошие ссылки с информацией о том, как такие проекты часто реализуются? Я видел, как развивалась ваша иерархия, но я не могу найти гораздо больше с подробной информацией (большинство из них, кажется, просто говорят "используйте компоненты, а не иерархию", но я обнаружил, что для изменения моего мышления требуется немного усилий) между двумя моделями).
Будут благодарны любые хорошие ссылки или информация по этому вопросу, и даже книги, хотя ссылки и подробные ответы здесь будут предпочтительнее.
8 ответов
Обновление 2013-01-07: Если вы хотите увидеть хорошее сочетание компонентного игрового движка с (на мой взгляд) превосходным подходом реактивного программирования, взгляните на движок V-Play. Он очень хорошо интегрирует функциональность связывания свойств QML QML.
Мы провели некоторые исследования CBSE в играх в нашем университете, и за эти годы я собрал некоторые материалы:
CBSE в игровой литературе:
- Архитектура игрового движка
- Программирование игр Gems 4: система управления игровыми объектами игры
- Программирование игр Gems 5: управление объектами на основе компонентов
- Программирование игр Gems 5: библиотека общих компонентов
- Программирование игр Gems 6: Система компонентов игровых объектов
- Разработка объектно-ориентированных игр
- Architektur des Kerns einer Game-Engine and Implementierung mit Java (немецкий)
Очень хорошим и чистым примером основанного на компонентах игрового движка в C# является игровая среда Elephant.
Если вы действительно хотите узнать, какие компоненты читаются: Разработка программного обеспечения на основе компонентов! Они определяют компонент как:
Программный компонент - это программный элемент, который соответствует модели компонента и может быть независимо развернут и составлен без изменения в соответствии со стандартом композиции.
Компонентная модель определяет конкретные стандарты взаимодействия и композиции. Реализация модели компонентов - это выделенный набор исполняемых программных элементов, необходимых для поддержки выполнения компонентов, соответствующих модели.
Инфраструктура программных компонентов представляет собой набор взаимодействующих программных компонентов, предназначенных для обеспечения того, чтобы программная система или подсистема, построенная с использованием этих компонентов и интерфейсов, удовлетворяла четко определенным спецификациям производительности.
Мое мнение после 2 лет опыта работы с CBSE в играх показало, что объектно-ориентированное программирование - просто тупик. Помните моё предупреждение, когда вы наблюдаете, как ваши компоненты становятся все меньше и меньше, и больше похожи на функции, упакованные в компоненты с огромными бесполезными издержками. Вместо этого используйте функционально-реактивное программирование. Также взгляните на мой свежий пост в блоге (который привел меня к этому вопросу при написании:)) о том, почему я перешел с архитектуры игрового движка на основе компонентов на FRP.
CBSE в играх:
- Компонентная разработка игр - решение для повышения затрат и продления сроков?
-
Гибкая и расширяемая архитектура для компьютерных игр(404) - Архитектура программного обеспечения для игр
- Общая структура для разработки игр (WebArchive)
- Интеллектуальная композиция игровых объектов с использованием внедрения зависимостей
CBSE в игровых веб-ссылках (отсортировано по релевантности):
-
Компоненты на основе объектов Wiki(Пустые вики) - Развивайте свою иерархию
- Структура игрового объекта: наследование против агрегации
- Управляемая данными система игровых объектов (PDF)
- Управляемая данными система игровых объектов (PPT)
- Компонентный инструмент для создания прототипов Flash
-
Теория и практика архитектуры компонентов игровых объектов(404) - Entity Systems - будущее ММО
- Форум ogre3d.org: Компонентные объекты
- gamedev.net: Архитектура системы сущностей на основе внешних компонентов
- gamedev.net: Вопрос по сущности системы
- Блог о системе сущностей Brainfold (WebArchive)
Кажется, что по этому вопросу не хватает информации. Я недавно внедрил эту систему, и я нашел действительно хороший GDC Powerpoint, который объяснял детали, которые часто остаются довольно хорошо. Этот документ здесь: теория и практика архитектуры компонентов игровых объектов
В дополнение к этому Powerpoint, есть несколько хороших ресурсов и различных блогов. PurplePwny имеет хорошее обсуждение и ссылки на некоторые другие ресурсы. В Ugly Baby Studios есть небольшая дискуссия о том, как компоненты взаимодействуют друг с другом. Удачи!
Хотя это и не полное руководство по теме дизайна игрового движка, я обнаружил, что на этой странице есть некоторые хорошие детали и примеры использования архитектуры компонентов для игр.
Это с открытым исходным кодом, и доступны на http://codeplex.com/elephant
Кто-то сделал рабочий пример кода gpg6, вы можете найти его здесь: http://www.unseen-academy.de/componentSystem.html
или здесь: http://www.mcshaffry.com/GameCode/thread.php?threadid=732
С уважением
Я исследовал и реализовал этот последний семестр для курса по разработке игр. Надеемся, что этот пример кода может указать вам верное направление того, как вы можете подойти к этому.
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;
};
Компоненты определяют поведение и работают со свойствами. Свойства делятся между всеми компонентами по ссылке и получают обновления бесплатно. Это означает отсутствие больших накладных расходов на передачу сообщений. Если есть какие-то вопросы, я постараюсь ответить как можно лучше.
В настоящее время я исследую эту точную тему во многих (МНОГИХ) темах на GameDev.net и обнаружил, что следующие два решения являются хорошими кандидатами на то, что я разработаю для своей игры:
Интересный арткл...
Я быстро покопался в гугле и ничего не нашел, но вы можете проверить некоторые комментарии - многие люди, похоже, попытались реализовать демонстрацию простого компонента, возможно, вы захотите взглянуть на некоторые из них. их для вдохновения:
http://www.unseen-academy.de/componentSystem.html
http://www.mcshaffry.com/GameCode/thread.php?threadid=732
http://www.codeplex.com/Wikipage?ProjectName=elephant
Кроме того, в самих комментариях, по-видимому, содержится довольно глубокое обсуждение того, как вы можете кодировать такую систему.
В этом контексте компоненты для меня звучат как отдельные части ядра во время выполнения, которые могут выполняться одновременно с другими компонентами. Если это мотивация, то вы можете посмотреть на модель актера и системы, которые ее используют.