Should properties of a components be added to the game object the component is modifying?

Started by
5 comments, last by CrazyCdn 6 years, 11 months ago
If I have a component that receives a game object (in which it's modifying) and which has it's own properties, should
the properties be added to the game object or be part of the component? Does it matter? It's something I've been thinking
about lately and was wondering if there would be a benefit to doing one vs the other. Code below is Python 3.
class Component:
def __init__(self, gameobject, x, y, z):
self.gameobject = gameobject
self.x = x
self.y = y
self.z = z
OR
class Component:
def __init__(self, gameobject, x, y, z):
self.gameobject = gameobject
self.gameobject.x = x
self.gameobject.y = y
self.gameobject.z = z

Advertisement

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.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

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

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

This topic is closed to new replies.

Advertisement