Elysian Shadows

I don't want what I say to merely become law here. Somebody show me concrete proof that a strict component system is a paradigm and not a design pattern.

Somebody show me a components system that is NOT implemented with an object-oriented paradigm? I don't think you can. The mere fact that we are attaching "components" to "entities"--both of which are "objects" that have encapsulated attributes (the definition of an object-oriented paradigm) makes my point look even stronger.

What about the method through which you guys are registering your components?

K-Bal wrote:

Code: Select all

int main()
{
   sf::RenderWindow window( sf::VideoMode( 300, 200 ), "Test", sf::Style::Close );
   window.UseVerticalSync(true);

   ComponentFactory factory;
   factory.RegisterComponent( "Movement", &MovementComp::Create );
   factory.RegisterComponent( "Rendering", &RenderComp::Create );
   factory.RegisterComponent( "Collision", &CollisionComp::Create );

   GameObject player( factory );
   player.AddComponent( "Movement" );
   player.AddComponent( "Rendering" );
   player.AddComponent( "Collision" );

   GameObject stick( factory );
   stick.AddComponent( "Movement" );
   stick.AddComponent( "Rendering" );
   stick.AddComponent( "Collision" );

   while( window.IsOpened() )
   {
      float delta = window.GetFrameTime();
      player.UpdateComponents( delta );
      player.UpdateProperties( delta );
                stick.UpdateComponents( delta );
      stick.UpdateProperties( delta );

      sf::Event event;
      while( window.GetEvent( event ) )
      {
         switch( event.Type )
         {
         case sf::Event::Closed:
            window.Close();
            break;

         default:
            break;
         }
      }

      const sf::Input& input = window.GetInput();

      player.GetProperty< sf::Vector2f >("Movement:Velocity").Set(sf::Vector2f(0.f, 0.f));
      if(input.IsKeyDown(sf::Key::Down))
      {
         player.GetProperty< sf::Vector2f >("Movement:Velocity").Set(sf::Vector2f(0.f, 50.f));
      }
      if(input.IsKeyDown(sf::Key::Up))
      {
         player.GetProperty< sf::Vector2f >("Movement:Velocity").Set(sf::Vector2f(0.f, -50.f));
      }
      if(input.IsKeyDown(sf::Key::Left))
      {
         player.GetProperty< sf::Vector2f >("Movement:Velocity").Set(sf::Vector2f(-50.f, 0.f));
      }
      if(input.IsKeyDown(sf::Key::Right))
      {
         player.GetProperty< sf::Vector2f >("Movement:Velocity").Set(sf::Vector2f(50.f, 0.f));
      }

      window.Clear();
      window.Draw(player.GetProperty< sf::Sprite >("Rendering:Shape").Get());
      window.Display();
   }

   return 0;
}

That is clearly a factory design pattern. The mere fact that you can't (prettily) implement a component without utilizing one or more other object-oriented design patterns also proves my point. By the way, that looks pretty good, K-Bal. It's essentially what we're doing. We have a little bit of cheap-assedness going on so that our client components auto register themselves (without having to do it at program initialization. I was planning on covering that in my article that I was going to submit to our newsletter...

But yeah, I challenge anybody to prove that a "component system" can be a programming paradigm, rather than an object-oriented design pattern.

GyroVorbis wrote: But yeah, I challenge anybody to prove that a "component system" can be a programming paradigm, rather than an object-oriented design pattern.

This first section of this page was what I was basing my argument on.
http://t-machine.org/index.php/2007/11/ ... nt-part-2/

I don't believe this proves it as a different paradigm, because he isn't implementing the concept of an entity system solely in code. He is using a database to store all of the attributes, and queries to retrieve them. So perhaps "paradigm" was a poorly chosen term on his part, as I'm not even sure that database interaction is of any paradigm?

GyroVorbis wrote:That is clearly a factory design pattern. The mere fact that you can't (prettily) implement a component without utilizing one or more other object-oriented design patterns also proves my point. By the way, that looks pretty good, K-Bal. It's essentially what we're doing. We have a little bit of cheap-assedness going on so that our client components auto register themselves (without having to do it at program initialization. I was planning on covering that in my article that I was going to submit to our newsletter...

I'd be interested in seeing that. The whole idea of external interfaces like level editors and in-game scripting fascinates me but I'm a total noob when it comes to that stuff (haven't really done it yet). I know that adding entities and components as well as registering them would have to be done dynamically though (hopefully I'm using that term correctly).

dandymcgee wrote:

GyroVorbis wrote: But yeah, I challenge anybody to prove that a "component system" can be a programming paradigm, rather than an object-oriented design pattern.

This first section of this page was what I was basing my argument on.
http://t-machine.org/index.php/2007/11/ ... nt-part-2/

I don't believe this proves it as a different paradigm, because he isn't implementing the concept of an entity system solely in code. He is using a database to store all of the attributes, and queries to retrieve them. So perhaps "paradigm" was a poorly chosen term on his part, as I'm not even sure that database interaction is of any paradigm?

Just wanted to let you know that I had been writing a post for half an hour trying to disprove the author of that article's claim that a "component system" is its own programming paradigm.

...I decided to stop, because there was no end in sight, and some of the other people commenting on the article did a fine job already. I adamantly disagree with that fact.

would you create a class for the instances of objects as you did before?
or would you just instantiate the entity and hard code it?


idk i guess both would work but what would be better. i just thought that with the first one you would have to do less work for say having 100 players in the game... well i guess you could create a function to create a player as well. im still trying to figure this out so idk if any of that makes sence but whatever.

WSPSNIPER wrote:would you create a class for the instances of objects as you did before?

Code: Select all

class Enitity
{
    // stuff about componets
};

class Player : public Entity
{
public:
    Player() {
        addComponet("Collision");

    }
}

or would you just instantiate the entity and hard code it?

Code: Select all

Entity player(componetSys);
player.addComponet("Collision");
// exc...

idk i guess both would work but what would be better. i just thought that with the first one you would have to do less work for say having 100 players in the game... well i guess you could create a function to create a player as well. im still trying to figure this out so idk if any of that makes sence but whatever.

The first, inheritance-based approach completely defeats the purpose of a component-based system.

When you create a class called a "Player" inheriting from an Entity, that is becoming a hard-coded, compiled entity type. The point of the entity system is that you are dynamically creating new types of entities at RUN-TIME (not compile-time) by attaching components. Just the fact that the Entity has a "player" or "collision" component attached should make it considered a player.

GyroVorbis wrote:

WSPSNIPER wrote:would you create a class for the instances of objects as you did before?

Code: Select all

class Enitity
{
    // stuff about componets
};

class Player : public Entity
{
public:
    Player() {
        addComponet("Collision");

    }
}

or would you just instantiate the entity and hard code it?

Code: Select all

Entity player(componetSys);
player.addComponet("Collision");
// exc...

idk i guess both would work but what would be better. i just thought that with the first one you would have to do less work for say having 100 players in the game... well i guess you could create a function to create a player as well. im still trying to figure this out so idk if any of that makes sence but whatever.

The first, inheritance-based approach completely defeats the purpose of a component-based system.

When you create a class called a "Player" inheriting from an Entity, that is becoming a hard-coded, compiled entity type. The point of the entity system is that you are dynamically creating new types of entities at RUN-TIME (not compile-time) by attaching components. Just the fact that the Entity has a "player" or "collision" component attached should make it considered a player.

thanks, im still thinking about how this works. So you have a component class and do you create different components that inherit from the base component class then you use them to define the entity. if have a tank class and want 1000 tanks would you have a function createTank or would you have to hard code it all or would you have a tank component class or what.. sorry for asking so many questions.

@post above me, I'm just waiting to see his article on the subject :D I think that's one that he was doing... now we just have to hope the newsletter goes live soon

eatcomics wrote:@post above me, I'm just waiting to see his article on the subject :D I think that's one that he was doing... now we just have to hope the newsletter goes live soon

sweet, i will be watching. i an super interested in this because i have been programming the same way for too long now i would like to try some different styles

Thank You Falco

Here is how I think about it:

Assume you have an engine and a game based on that engine - Entity is part of the engine. Than it is okay to derive a specialized entity class for your game from Entity, that contains stuff that is very special to the entities in your game. However, in most cases this could also be achieved by adding specific components.

About OOP or Non-OOP: In one article the described entity system did not contain a class Entity, but only some managers that can reference entities by an unique identifier, in principle like an array. So this is a data-based approach, whereas having a container of entities where each has some components is an object-based approach. The good point with the data-based approach is that you can iterate through all components of one type in O(n), n number of components of type x (When you have a container of entitites you would need O(m), m number of entities, m > n.

K-Bal wrote:Here is how I think about it:

Assume you have an engine and a game based on that engine - Entity is part of the engine. Than it is okay to derive a specialized entity class for your game from Entity, that contains stuff that is very special to the entities in your game. However, in most cases this could also be achieved by adding specific components.

About OOP or Non-OOP: In one article the described entity system did not contain a class Entity, but only some managers that can reference entities by an unique identifier, in principle like an array. So this is a data-based approach, whereas having a container of entities where each has some components is an object-based approach. The good point with the data-based approach is that you can iterate through all components of one type in O(n), n number of components of type x (When you have a container of entitites you would need O(m), m number of entities, m > n.

thanks for the explanation, it helped a lot.

K-Bal wrote:About OOP or Non-OOP: In one article the described entity system did not contain a class Entity, but only some managers that can reference entities by an unique identifier, in principle like an array. So this is a data-based approach, whereas having a container of entities where each has some components is an object-based approach. The good point with the data-based approach is that you can iterate through all components of one type in O(n), n number of components of type x (When you have a container of entitites you would need O(m), m number of entities, m > n.

Correct, but I still don't see this as being non object-oriented just because your "components" are not within an entity class.

Your components themselves are still classes (usually inheriting from an abstract Component class to implement pure virtuals, which is OO as fuck) regardless of where they're being stored. You're still using factories (an OO design pattern) to retrieve/update/manipulate them. I have never even seen a component NOT be implemented as an OO object encapsulating its own functionality. (A character component has a function Character::Walk() that causes the entity to walk).

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).

ya, thanks for clearing that up. i couldent imagine doing this without a pure abstract component class but idk. im going to start to try to implement this myself thanks for all the help you guys have given me

I just wanted to show that those are different logical approaches. The combined approach is probably the most useful one, but it turns up new "problems" that the programmer has to solve (e.g. who ones the components?).

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.

K-Bal wrote: 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