Is my engine concept a good one?

Question

I'm currently writing a generic engine for my incoming games. I have developed few games already but never with the same "base" and my code was/is quite a mess. The idea was to create an engine that I could use for any type of games.
I have read papers about entity/components managers. Some are using what they call nodes, systems etc... I thought it was a bit confusing, especially the node concept. I plan to not use nodes, and my question essentially is: "Is this a good engine concept"? And if it is not, what improvements could I make?

First, all elements in my game are entities. The player is an entity, any tile of the map or whatever is an entity. An entity (in my engine) is a basic class with a position, and a list of components. In my mind, all "features", "behaviors", etc, must be implemented through components. The entity class will also have an update and a render method. The entity holds an unique special component that is a component that implements an interface 'Renderable' and will handle the rendering of the entity, an entity that does not need to be rendered will not have a render component.

That was for the entity, now about component. Currently in my engine a component is something that brings something to the entity. For example, if I want my entity to be controllable via keyboard or whatever, I will add a component that handles this to my entity. And during the engine update process, the entity manager will update all its entities and each entity will update all its components (or at least the components that need to be updated).

class KeyboardControllComponent extends AbstractComponent implements Updatable {

    @override
    public void update() {
        //do the input handling here
    }

Basically this component will call another one (a movement component) that will actually apply the movement to the entity.

Also, I have implemented what I call a 'dispatcher' to my engine. It allows all elements to the game (everything in my game extends a GameElement class) to dispatch or listen for events. For example, if the hero walks on a specific thing (a trap for example), the component in charge of the hero entity movement/collision will fire an event to all game elements that are actually listening for that kind of events. I will take the example of an interrupter, the hero 'collide' this interrupter, the interrupter component in charge of collision will then fire a event to the entity that represents a door somewhere and open it.

Is this a good concept?

Finally, all game elements are handled by managers. EntityManager, DispatcherManager, SceneManager, etc...

Let me know what you think of my approach. I have not added actual code using the engine to not overload the post but if you want to see it, no problem.

Answer 1

It looks mighty fine to me. I'm using a similar approach in my engine.

My definition of an Entity is that it is an object that can interact in some way with other objects. Right now I have the generic GameObject class, with three children: Player, Enemy and Bullet. It also has handles to five different modules:

• ModuleSprite - renders the entity
• ModuleWeapon - allows the entity to shoot weapons
• ModuleScripting - makes the entity scriptable
• ModuleCollision - collision detection
• ModuleParticles - particle effects

There's a hidden benefit to this modular approach: you can build objects from a blueprint! For instance, this is the blueprint for a bullet:

name: "Bullet"
type: eBullet
module_sprite {
    sprite: "blast_cool.png"
    render: eCamera
    pivot {
        x: 0.5
        y: 0.5
    }
}
module_collision {
    state: eIncorporeal
    weight: 1.0
    sphere {
        radius: 12.0
    }
}
module_particles {
}

I load these blueprints into my global StateMachine and now I can spawn a bullet like this:

GameObject* result = m_Owner->GetScene()->CreateObject("Bullet", &m_ObjectState);

Even though it's silly, I could have my Bullet spawn more bullets by adding this to the blueprint:

module_weapon {
    weapon {
        name: "Blaster"
        state {
            time_cooldown: 5.0
            time_reload: 50.0
            clip_ammo_left: 10
            clip_ammo_total: 10
            current: 1
        }
    }
}

Important to note, though, is that you should make the module interface as simple as possible. You can have either 0 or 1 of each module, but each module can contain 0..n of whatever functionality it manages.

In my case, the ModuleWeapon class holds all the weapons for an Entity, with a member that describes the currently active weapon.