Component Systems (formerly: Component Oriented Programming)

[Falco Girgis]

Actually, I don't care how my programming is called as long as I know what I am doing and what the pros and cons of it are.

ya i should start thinking this way, for some reason i worry about how everything will be called in the future and how it will look when im going to be the one programming it so as long as it works good and i know whats happening it is what i should do

I have just always been a bitch for proper terminology/vocabulary when describing things. It's just the literary nerd in me...

[WSPSNIPER]

Actually, I don't care how my programming is called as long as I know what I am doing and what the pros and cons of it are.

ya i should start thinking this way, for some reason i worry about how everything will be called in the future and how it will look when im going to be the one programming it so as long as it works good and i know whats happening it is what i should do

I have just always been a bitch for proper terminology/vocabulary when describing things. It's just the literary nerd in me...

ya, but i think i do it too much. when i program i try to make sure that at a high level everything looks perfect and can be implemented in a way that is neat and organized. i guess its not a bad thing but sometimes it can make low level stuff harder to implement

[K-Bal]

Actually, I don't care how my programming is called as long as I know what I am doing and what the pros and cons of it are.

ya i should start thinking this way, for some reason i worry about how everything will be called in the future and how it will look when im going to be the one programming it so as long as it works good and i know whats happening it is what i should do

I have just always been a bitch for proper terminology/vocabulary when describing things. It's just the literary nerd in me...

ya, but i think i do it too much. when i program i try to make sure that at a high level everything looks perfect and can be implemented in a way that is neat and organized. i guess its not a bad thing but sometimes it can make low level stuff harder to implement

I think you got me wrong. Good high level organisation is the most important thing in programming if you're going to write anything bigger than console tic tac toe. However, I find it to be unimportant by which name you call this organisation as long as you are aware of how the topology / structure is.

[EccentricDuck]

Actually, I don't care how my programming is called as long as I know what I am doing and what the pros and cons of it are.

ya i should start thinking this way, for some reason i worry about how everything will be called in the future and how it will look when im going to be the one programming it so as long as it works good and i know whats happening it is what i should do

I have just always been a bitch for proper terminology/vocabulary when describing things. It's just the literary nerd in me...

ya, but i think i do it too much. when i program i try to make sure that at a high level everything looks perfect and can be implemented in a way that is neat and organized. i guess its not a bad thing but sometimes it can make low level stuff harder to implement

I'm the same way. Falco has a funny diagram regarding Procedural/Object-Oriented approaches to programming in the album on the ES website and, while I have yet to do a Comp Sci class (though that will change in 2 weeks), I've definitely found myself being over-focused on OO design. In some ways it's been good because it's pushed me to learn different practical implementations of OO design (hence why I've been so interested in Components), but several times I've found myself over-complicating things that would be much simpler to do with a more procedural approach.

Yesterday I got a bit fed up with what I have been doing and decided to totally change modes and it was one of the most productive coding sessions I've had in awhile. I've been trying to figure out a good component framework for something that I will be working on soon, but I've been trying to integrate it with what I'm currently working on. To give some perspective, what I'm doing now is 3D and what I will be doing is 2D. What I'm working on has 1 level and networking while the next thing I want to work on will have several levels and will not have networking. What I'm working on now is partially based on a framework for a demo game (for XNA developers) that has components, but those components are the underlying managers rather than components that are attached to entities. I realized I'm spending too much time trying to make something to port over when they're two completely different games and I'm simply creating more work for myself. What I'm working on now is relatively simple once you get past the networking and graphics (which I've been putting a lot of focus into). There just isn't much to be gained from a component oriented approach. My game will have such a limited number of entities that it's not worth it - and the components will be different in many ways from components in the other game so it's not portable. Better just to approach it procedurally* rather than over-complicate things in this case.

*I should say that what I'm doing is still probably less procedural than what someone who's used to programming in C would call procedural, but I'm not stepping back every 10 minutes to figure out how to further abstract functionality rather than just implementing it.

In the ES engine, we utilize both approaches. Each area has a vector/array for every component within the area (warp, character, enemy, collidable, etc). The "systems" or "managers" operating on these components simply utilize the arrays. HOWEVER, there is also an array of every ENTITY in the area as well, and the entities also contain pointers to each component attached to them.

The data-driven approach is much better for the behind-the-scenes managers/factories manipulating these components, but for the higher-level programmer/scripter, it is way more useful to be able to reference an entity's attached components from within the entity (IMHO).

Thank you for that clarification! I've really been struggling with how to best work with the area-manager and component-manager communication. As I said above, I've kind of shifted gears on what I'm currently doing, but that doesn't mean I'm not thinking about it on the side.

[WSPSNIPER]

ok one more question would you use the component method for your core ... like windowing and stuff like that. well i guess it could be a component like the rendering component but just wondering

[eatcomics]

offtopic: Sniper... I love your avatar xD More on topic: I think there's a high demand on an edjuakation for this Gyro

[Falco Girgis]

ok one more question would you use the component method for your core ... like windowing and stuff like that. well i guess it could be a component like the rendering component but just wondering

Personally, no. The core of ES utilizes other OO design patterns. Currently "Entities" are the only component-based subsystems.

...though off of the top of my head, it does seem very useful for something like attaching widgets to a GUI class...

[WSPSNIPER]

ok one more question would you use the component method for your core ... like windowing and stuff like that. well i guess it could be a component like the rendering component but just wondering

Personally, no. The core of ES utilizes other OO design patterns. Currently "Entities" are the only component-based subsystems.

...though off of the top of my head, it does seem very useful for something like attaching widgets to a GUI class...

thanks

[WSPSNIPER]

ok ive been working at this for a while and i have got a working entity system with a rendering component and system...

here is the main.cpp ( for now )

Code: Select all

#include "Window.h"
#include "Image.h"

#include "EntityManager.h"
#include "Component.h"
#include "RenderComp.h"
#include "Entity.h"
#include "RenderingSystem.h"
using namespace es;
using namespace fe;

EntityManager* mgr = EntityManager::getInst();

RenderingSystem * renderer = RenderingSystem::getInst();;

// i need to find a way to allow components/systems to communicate O_O

int main(int argc, char* args[])
{

    fe::Window window = renderer->getWindow();
    Entity player;

    player.addComponent("Rendering");
    Image* image = &player.getComponent<RenderingComp>("Rendering").getImage();

    image->load("cool.png");

    image->move(20, 20);
    while(window.isOpen())
    {
        SDL_Event event;
        SDL_PollEvent(&event);
        if(event.type == SDL_QUIT)
            window.close();
        renderer->execute();

    }
    return 0;
}

and the rest of the src can be found here http://code.google.com/p/metalheavensur ... len-engine


ok one thing im thinking about is how im going to get the components to communicate with eachother, for example if i have an animation component and i want the frame offset to set the image which is located in the rendering component... what do you guys think

thanks for all your help. I would love any comments you have on my program

[EccentricDuck]

ok one thing im thinking about is how im going to get the components to communicate with eachother, for example if i have an animation component and i want the frame offset to set the image which is located in the rendering component... what do you guys think

Since no one else has answered I'll have a go at this with some thoughts I've had. One way would just be to make the components accessible to each other. You would have a dependency of some components on others. That would make sense though since you can't do something like animate without a renderable sprite. You could use either an error handler or just an if - else statement to either raise an error if animation is present and sprite isn't, or just have animation not animate when renderable is missing. The way I was going to do it involved passing a reference of the entity to each component and the component could reference any individual component through the entity.

[WSPSNIPER]

ok one thing im thinking about is how im going to get the components to communicate with eachother, for example if i have an animation component and i want the frame offset to set the image which is located in the rendering component... what do you guys think

Since no one else has answered I'll have a go at this with some thoughts I've had. One way would just be to make the components accessible to each other. You would have a dependency of some components on others. That would make sense though since you can't do something like animate without a renderable sprite. You could use either an error handler or just an if - else statement to either raise an error if animation is present and sprite isn't, or just have animation not animate when renderable is missing. The way I was going to do it involved passing a reference of the entity to each component and the component could reference any individual component through the entity.

thanks, thats what i was thinking about. i was also thinking about passing a ref to the image into the animation and updating it directly and a ref to the image rect for collision exc... but idk how that would work out. i think passing the entity may be a better idea

Thanks again :D

[Falco Girgis]

ok one thing im thinking about is how im going to get the components to communicate with eachother, for example if i have an animation component and i want the frame offset to set the image which is located in the rendering component... what do you guys think

Since no one else has answered I'll have a go at this with some thoughts I've had. One way would just be to make the components accessible to each other. You would have a dependency of some components on others. That would make sense though since you can't do something like animate without a renderable sprite. You could use either an error handler or just an if - else statement to either raise an error if animation is present and sprite isn't, or just have animation not animate when renderable is missing. The way I was going to do it involved passing a reference of the entity to each component and the component could reference any individual component through the entity.

thanks, thats what i was thinking about. i was also thinking about passing a ref to the image into the animation and updating it directly and a ref to the image rect for collision exc... but idk how that would work out. i think passing the entity may be a better idea

Thanks again :D

Yeah, this is a pretty touchy subject. Granting one class access to another class usually is a pretty gray area in the software design field.

The Unity3D engine gives each component a reference to each other component, so that they may access one another. My lower-level C background cringes at things like this, because I feel like wasting 8 pointers per component is a little excessive. I require each component to have a "parent" entity (that it is attached to) then allow them to backtrack through the entity and access other components:

Code: Select all

collidable->getEntity()->getComponent(Component::ANIMATION);

Depending on how much of an OO cunt you are, this may offend you. I'll take my kilobytes of RAM though, thankyouverymuch. :D

As for handling this dependency, the approach that we use in the ES Joint AssetIO framework is to declare a purely virtual function that checks for prerequisites before the component is attached. If the Entity/GameObject does not already have a Sprite component, there is no way in hell that it needs an Animation component.

Code: Select all

class Animation: public Component {
    bool canAddTo(const Entity& entity) {
        return (entity->getAnimation())? true : false;
    }
}

So now I'm able to check for prerequisites when the user attempts to attach a Component to an Entity:

Code: Select all

bool Entity::AttachComponent(Component &component) {
    if(!component->canAddTo(*this)) return false;
    else componentList.push_back(component);
    return true;
}

[K-Bal]

Sounds smart, Gyro.

I think the main reason for Unity to use references to all components is performance. You don't have to iterate over the components to find the right one.

[WSPSNIPER]

Gyro, thanks for the reply. That made me think of it in a different way, so the components hold a pointer to the entity and the entity will hold the component in a list? well that sounds like a good way to do that.

Thank you :D

[Falco Girgis]

Sounds smart, Gyro.

I think the main reason for Unity to use references to all components is performance. You don't have to iterate over the components to find the right one.

My method is not iterative either. At least components that are "built in" to the engine are stored as a static array that may be accessed by:

Code: Select all

class Component {
public:
    enum TYPE { SPRITE, ANIMATION, COLLIDABLE, RIGID_BODY, MAX_TYPE };
};

Code: Select all

class Entity {
private:
    Component *component[Component::MAX_TYPE];
public:
    Component *getComponent(Component::TYPE type) {
        return component[type];
    }
};

C++ and Lua "Behaviors" (components that are extending the engine) are stored in a std::map and must be iterated through (which is the same as Unity). I'm pretty sure that they did it just for convenience and code readability.