Hi there, people, I'm working on a game using a component-based object system, loading data from disc, using that to create objects and components via factories, and so on and so forth. I'm quite satisfied with how all that works, and am only telling you for a bit of context. What I'm still having trouble with is the issue of component inter-relation, specifically with regard to things like 'position'. The 'position' of an object can mean many things - where it is on screen, where it is in the physical game-world space, where it is in terms of AI methods - and these different (though preferably identical) positions will be stored in the relevant components. The mesh will be in the graphics component, and so on. Now, save for special cases, these positions will need to be the same. What I don't quite understand is how these components will keep positions in-sync. Should they broadcast a message to the other components of the object every time they change position? Should certain components even be allowed to change the position (graphics component)? Should there be an additional 'position' component that gets the final say? If there's no physics component or position component, does that mean the object is immovable? I'm aware this is a fairly new way of doing things with regard to object systems, but I'm quite sure some of the software engineers on the forum could provide some input. What would be a sensible way of handling these inter-relations? Thanks :)

It's not really a new way of doing things. You could use messages or you could use the Observer design pattern which attaches observers to an object that get notified when the object changes.

I suppose I meant it's only recently being focused on, rather than it's a new way of doing things :)

Anyway, I figured message-passing would be one of the best ways. And in fact, now that that's been confirmed, I'm beginning to see that there aren't really any other problems. If there are no components that change position in the object, the object is static... if there are multiple, I've probably designed the object wrong. It's just a case of choosing the right components, then :) Thanks for the help, people!

I am planning to maintain a set of global state for the entity that all components share. This would probably be a list of tokens from a fixed list of possible global state variables.

It would be nice to be completely free form, but you would have the problem of one component updating "pos" and another trying to display a 3d mesh at "position", a mistake that sounds too easy to make for my liking.

Hence I am likely to bite the bullet and go for the old 'not so clever header file' with an ENUM of state variable names and a simple binding between that and a type using some kind of token class. Each entity then has a map that contains just the state variables it requires.

Downsides being header recompilation, the upside is that using enums is probably quicker since i should be able to get at the state far more directly. Either way in a project with shared state you need to keep track of accidental redundancy somehow, if I keep track of it all in a single enum then there is one place to add and look up what state there is to use.

I suppose you could read in the list from a txt file, converting strings to ID's at start up. If a class tries to get at a global state var that isnt one of the ones defined on that list then it gets told off. as long as the devs have a single list to look at and work from then most of the redundancy can be removed and what isnt can be spat at the debug console.