Unused methods after component inheritance in component based architecture?

Question

I have a GameObject class, which contains Components, like:

• Renderer
• Camera
• Behaviour
• Rigidbody

First I inherited all of them from Component which has an Update() method, and it is called every frame on every game objects' every component.

But then I noticed, that** Renderer and Camera's Update method is unused**. (There are classes like RenderData & CameraData which are isolated and made from primitives, and upon creation of these Components, these Data's pointer is sent to the GraphicsEngine which will process them every frame.)

So having an unused method is bad. So I created a DynamicComponent class, which inherits from Component, and Behaviour & Rigidbody classes are inherited from it.

I moved the Update() from Component to DynamicComponent, and I have now 2 containers at gameobjects:

• Components (for components which are inherited directly from Component)

• Dynamic Components (for components which are inherited from D.Comp.)

And every frame I only call DynamicComponents' Update().

Now I'm having another issue. There is the Behaviour class, where should be a Start() method, which is called on every Behaviour when the scene is fully initalized.

That means that I should have a Components, D.Components and also a Behaviours container at game objects.

This looks very bad to me.

Having a Component class, with Start(), Update(), etc is very simple and makes a very clean code, but this means that only a few derived classes implement its virtual methods.

What should I do?

Answer 1

Basically I'm with truthastup. I'm kind of a fan of the so called ECS pattern, which separate data and logic for Component and System. I think it's the pattern is good at making the engine architecture modular and flexible. I've also implemented a version of my own but it hasn't been used in commercial game, though.

On the other hand, the architecture you're using is more like Unreal and Unity engine, which is, lets say more conventional, but it's also easy to use. So follow this architecture is totally fine, there are many users of Unreal and Unity, which proves it can work, myself is also developing game by Unreal engine right now.

Anyway, the point is, I think to have so many layers of inheritance of Component is kind of shooting itself in the foot. The origin of Component based design is to let composition over inheritance and make things easier. So I'd say to have only one base class of Component and design a set of common virtual functions (Start(), Update() etc.) is very good to go.

You mentioned the problem that only a few derived classes implement some virtual functions, I think it's totally fine, since virtual functions are not always needed to be implemented. They are virtual because they "maybe" overridden, but not necessarily.

If your game engine is to be released for the public some day, then I'd strongly recommend to stick with a single Component base class and have all possible virtual functions in it, which is following the Unity way. Comparing Unity and Unreal's component based design, I'd say Unity is totally a winner, their architecture is clearer and easier to learn and use, and is more "component like". But Unreal's code base is far more older than Unity's, so maybe it's unfair/pointless to compare them, though.

Answer 2

Having a Component class, with Start(), Update(), etc is very simple and makes a very clean code

I'm not sure this is true. In my code, Components are simple data structures without any functionality. They just keep some info about this GameObj.

For instance:

class GraphicsComponent: public Component{
    public:
    unsigned int gameobj_id;
    float posx, posy, posz;
    float scaling;
    std::string material_name;
}

My Systems have Init(), Update(), etc, and will update the Components during those functions. in Engine::StartRunning() I call every System's Init() function. Then, when I start my gameloop, I call every System's Update() function over and over again until someone tells me to stop.

class GraphicsSystem: public System{
public:
    void Init(){
        // *set up initial GameObj components* //
    }
    void Update(float delta_time){
        HandleSystemMessagesAndInput();
        // *do stuff with components* //
    }

    std::vector<GraphicsComponent> gfx_comps;
};

Different Systems will keep 'their data' about the GameObjs (it's all inside that Component), but they will have functions implementing their functionality. For example, PhysicsSystem will have a PhysicsSystem::HandleCollisions( PhysicsComponent *phys_comp_a, PhysicsComponent *phys_comp_b) function.

I still keep a global container of GameObjs for convenience, but that's kind of taboo. However, I find it useful to hang a GameObj's Components on a GameObj struct for intra-System bailouts. In reality I only really use this during Component add/remove (each System does its own Component adds/removes) and I would warn you against thrashing the cache by doing it too often.

P.S. This link has some good discussion about the tradeoffs in using different approaches: http://gameprogrammingpatterns.com/component.html