Sign in to follow this  
hymerman

Question about component inter-relations

Recommended Posts

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

Share this post


Link to post
Share on other sites
Lets say you use a message based system. Lets assume both the physics system and the graphics system has a position of the same object. Now if the physics system changes the position, it could just post a "position changed" message with a reference/pointer to the related entity. The graphics system would see that the position is changed and update it's position accordingly. This is how I would do it, some problems might occur if many systems can change one value and the systems run in different threads. There's lots of ways to work around this problem though.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Quote:
Original post by hymerman
It's just a case of choosing the right components, then :)


You have a lot of faith in your team if that doesn't worry you :)

Share this post


Link to post
Share on other sites
I suggest you have one master position for each object, which positions the object in the world.

All other positions are calculated on the fly from the master position, often using the camera object.

If you _need_ to store another _copy_ of the position (in physics for example), this is a caching problem. Make sure you always update the master position.


/Marcus

Share this post


Link to post
Share on other sites
Quote:
Original post by hymerman
... now that that's been confirmed, I'm beginning to see that there aren't really any other problems... It's just a case of choosing the right components, then :)


Given that the only conclusion you've come to so far is that you will use a message-based system, I don't think that your design problems have whittled down to just chosing a few components. Whittling it down to just choosing the right components is only as descriptive as the statement, "Just do it correctly and you won't have done it correctly".

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this