The second example is unworkable. Once you have several components, keeping track of which ones are adding or modifying which fields on the game object is going to be difficult and error prone.

Normally it's the gameobject that owns the component (hence the name 'component', i.e. "a part or element of a larger whole"), so the idea that the component changes the gameobject would be unusual.

Thanks for reply, that makes sense.

Why would a component know about a game object? It's typically and I think best, as pure data. Least it makes the most sense that way.

For me an entity contains a vector of bits (C++ here so std::bitset<number_of_components>) so it knows which ones it contains at the time. An ID (either 32 or 64 bits and I use a hashed name for that).

Then all components are independent. And each have systems that work on them and know how to get data from other systems they require knowledge of.

I might be weird though, but extending my system requires little work at all.

Why would a component know about a game object? It's typically and I think best, as pure data. Least it makes the most sense that way.

For me an entity contains a vector of bits (C++ here so std::bitset<number_of_components>) so it knows which ones it contains at the time. An ID (either 32 or 64 bits and I use a hashed name for that).

Then all components are independent. And each have systems that work on them and know how to get data from other systems they require knowledge of.

I might be weird though, but extending my system requires little work at all.

Well for example with a move component I send in a reference of the game object so it can move the game object by modifying it's rect location. I figure for some components I need some way for the component to access members of the game object.

If game object is the storage of values then perhaps a simple functions could justify:

def MoveGameObject(gameobject, x, y, z):
gameobject.x = x
gameobject.y = y
gameobject.z = z

Or if you want to have game object contain the definition for moving:

class GameObject:
def Move(self, x, y, z):
self.x = x
self.y = y
self.z = z

Why would a component know about a game object? It's typically and I think best, as pure data. Least it makes the most sense that way.

For me an entity contains a vector of bits (C++ here so std::bitset<number_of_components>) so it knows which ones it contains at the time. An ID (either 32 or 64 bits and I use a hashed name for that).

Then all components are independent. And each have systems that work on them and know how to get data from other systems they require knowledge of.

I might be weird though, but extending my system requires little work at all.

Well for example with a move component I send in a reference of the game object so it can move the game object by modifying it's rect location. I figure for some components I need some way for the component to access members of the game object.

I have no idea about python honestly but in my case the physics system knows how to query the position component system. The systems communicate, not the components. Again, I'm of the school of pure data, but I prefer logical choices :P