C ++游戏引擎中的复合,组件和实体

时间:2013-04-08 21:08:48

标签: c++ game-engine composite entity-system component-based

我正在开发一个开发游戏的学校项目。我们使用由我们拥有的一个团队制造的引擎。发动机的堆积对我来说还不清楚,似乎是一种反模式。然而,似乎没有人可以让我明白设计选择。该引擎应该使用“基于组件”的设计,但我没有看到它。下面是Component,Composite和Entity类的代码。简而言之,我的问题是:这个代码是使用有效的设计模式还是仅仅为了“实现设计模式”而过于复杂,从而导致反模式

Component.cpp:

#include "Engine\Component.h"
#include "Engine\Composite.h"

Component::Component(Composite* parent)

{
    this->parent = parent;
}

Component::~Component()
{
}

Entity.cpp

#include "Engine\Entity.h"
#include "Engine\Game.h"


Entity::Entity(Composite* parent):Composite(parent)
{
    this->mass = 1;
    node = NULL;
}

void Entity::update()
{
    Composite::update();

    this->angularVelocity += this->angularAccelaration;
    this->orientation += this->angularVelocity;

    this->accelaration = (1 / this->mass) * this->force;
    this->velocity += this->accelaration;
    this->position += this->velocity;
    if (node != NULL)
    {
        this->node->setPosition(this->position);
        this->node->setRotation(this->orientation);
    }
}

void Entity::draw()
{
    Composite::draw();

    if (node == NULL) return;
    if (!this->visible)
    {
        this->node->setVisible(false);
        return;
    }
    this->node->setVisible(true);

    this->node->render();
}

void Entity::createNode(std::string modelPath)
{
    // Get the mesh
    irr::scene::IAnimatedMesh* mesh = Game::getSceneManager()->getMesh(modelPath.c_str());

    // Create model entity
    this->node =  Game::getSceneManager()->addMeshSceneNode( mesh );
    this->node->setMaterialFlag(EMF_FOG_ENABLE, true);
}

Entity::~Entity()
{
    Composite::~Composite();
    if (node != NULL)
    {
        node->drop();
    }
}

Composite.cpp

#include "Engine\Composite.h"

Composite::Composite(Composite* parent):Component(parent)
{
}


Composite::~Composite()
{
    for (std::list<Component*>::iterator i = components.begin(); i != components.end(); ++i)
    {
        delete (*i);
    }
    components.clear();
}

void Composite::handleMessage(unsigned int message, void* data)
{
    for (std::list<Component*>::iterator i = components.begin(); i != components.end(); ++i)
    {
        (*i)->handleMessage(message, data);
    }
}

void Composite::update()
{
    for (std::list<Component*>::iterator i = components.begin(); i != components.end(); ++i)
    {
        (*i)->update();
    }
}

void Composite::draw()
{
    for (std::list<Component*>::iterator i = components.begin(); i != components.end(); ++i)
    {
        (*i)->draw();
    }
}

void Composite::addComponent(Component* component)
{
    components.push_back(component);
}

void Composite::removeComponent(Component* component)
{
    components.remove(component);
    delete component;
}

下一段代码是Player.cpp,使用复合和实体作为混合类型的对象(我真的没有得到逻辑)。

Player.cpp

#include "Player.h"
#include "Messages.h"
#include <iostream>

Player::Player(Composite* parent) : Entity(parent)
{
    createNode("../assets/sydney.md2");
    //i = 0;
    //v3f = vector3df(0,0,0);
    /*networker = new NetworkComponent();
    addComponent(networker);
    networker->registerVar(&i);
    networker->registerVar(&v3f);*/
}

void Player::update() {
    Composite::update();
    //std::cout<<i<<std::endl;
    //std::cout<<"vectorx="<<v3f.X<<"\n";
}

void Player::handleMessage(unsigned int message, void* data) {
    switch(message) {
        case DAMAGE: /* Do something */;
    }
    delete data;
}

Player::~Player()
{
    Entity::~Entity();
}

我不相信这是一个基于组件的设计。不应删除实体,只能使用Composite和Component。组件基类不应该是空的并且从不直接使用吗?就像一个名为'Rigidbody'的组件,它包含刚体数据的数据结构和一些覆盖完全虚拟组件基类的函数?

1 个答案:

答案 0 :(得分:2)

发布的代码是composite pattern的变体。此设计模式是结构模式,用于允许客户端以统一的方式处理单个对象和复杂对象,例如由多个对象组成的对象。例如,渲染循环可以迭代对象集合,在每个对象上调用draw()。由于这是一种结构模式,如果这是overengineering的实例,很难主观回答,因为它需要检查更多的类层次结构和体系结构。

但是,ComponentComposite的类命名约定以及复合设计模式的使用都不意味着这是一个“基于组件”的设计。我不熟悉game programming component pattern,但它实际上似乎是strategy pattern状态耦合在算法类中,从而简化了strategycontext之间的接口。在任何一种情况下,这两种模式都是行为模式,可以实现可互换和封装的算法。因此,发布的代码不会实现“基于组件”的设计,因为ComponentCompositeEntityPlayer类都没有提供封装的方法。算法以可互换的方式。例如,Entity::update()将始终以相同的方式计算位置。如果Entity需要使用不同的物理模型,那么这种耦合需要扩展Entity类层次结构(考虑Entity对具有不同物理集的行星进行变形的情况),而不是委托封装算法的类Physics层次结构。