Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Updating nested game objects - update child before parent or parent before child?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Starfox   Members   -  Reputation: 504

Like
0Likes
Like

Posted 03 July 2012 - 07:57 PM

I have a system where game objects can contain other game objects as their children, and have an update(float DeltaTime) function in my game objects which does the per-frame updates (ticks, or whatever your favorite engine calls it). I'm wondering whether it makes more sense to update child objects before their parents or the other way around - I want to have some relative update order determinism given that I specify that objects at the same level in the hierarchy are updated in no specific order relative to each other. Your $0.02 are welcome.
Holy crap I started a blog - http://unobvious.typepad.com/

Sponsor:

#2 Koobazaur   Members   -  Reputation: 691

Like
0Likes
Like

Posted 03 July 2012 - 09:57 PM

Pick one, make it a standard, and stick to it.

If you want more details, it depends on the nature of the parent-child relationship, really, and who talks to who more, and assumes the other will be updated first.

Postmortem: one must die -  Political narrative-adventure game playing an Agent of Death who must take ONE life that could change the fate of a conflict-torn Nation

 

Check out my DevBlog for news on the next title!


#3 laztrezort   Members   -  Reputation: 972

Like
0Likes
Like

Posted 03 July 2012 - 10:15 PM

Agree with Koobazaur, it depends on a lot of things. In my projects, I have found that I usually update parent then children, but that is only because the relationship was representing physics attachment (where children have their position and velocities relative to and dependant on the parent). However, I can imagine scenarioes where this is reversed, or where it doesn't matter and thus doesn't need to be deterministic at all.

#4 Ashaman73   Crossbones+   -  Reputation: 7987

Like
0Likes
Like

Posted 03 July 2012 - 11:13 PM

where children have their position and velocities relative to and dependant on the parent

I think that this is quite common, you often have an object attached to its parent (member->party, item->npc,guild->town) which acts depending on the state of the parent.

Best to encapsulate the control of the update in the object itself, a standard update method would look like this(pseudo code):
[source lang="java"]object::update(){ // call internal update this->internalUpdate(); for each child do child.update(); end}[/source]
When you wish to update an object class in an other way, just overwrite the update method like this:
[source lang="java"]SpecialOjbect::update(){ // call super update Object::update(); // do some post processing ...} [/source]

#5 Dmytry   Members   -  Reputation: 1148

Like
1Likes
Like

Posted 04 July 2012 - 02:56 AM

I would have the parent's update call updates of children so that parent can perform processing before and after processing children, or update children in particular order.
My game The Polynomial is now available on Steam. | The Polynomial homepage | Cloud and terrain rendering |Everything i said in that post is obviously ABSOLUTE TRUTH my unhumble opinion.

#6 Koobazaur   Members   -  Reputation: 691

Like
0Likes
Like

Posted 04 July 2012 - 02:36 PM

Dmytry, that's usually what I do in a clear owner->child type of a scenario, but it may not work in the aforementioned physics attachment system, since whatever function goes on updating all your objects would probably update the child already. Hence why i said, it depends on the nature of the relationship.

Postmortem: one must die -  Political narrative-adventure game playing an Agent of Death who must take ONE life that could change the fate of a conflict-torn Nation

 

Check out my DevBlog for news on the next title!


#7 Krohm   Crossbones+   -  Reputation: 3245

Like
0Likes
Like

Posted 05 July 2012 - 01:12 AM

I have a system where game objects can contain other game objects as their children, and have an update(float DeltaTime) function in my game objects which does the per-frame updates (ticks, or whatever your favorite engine calls it). I'm wondering whether it makes more sense to update child objects before their parents or the other way around

I suggest to consider the idea of dropping extensive update process. I once read an article suggesting to not update at all.
I don't think that's feasible but I can sympathize with the concept and I worked out a system which is somewhat compliant with this concept. What I have done in my system is to have a single place when update(deltaTime) will be issued. There will only be one update call per tick. The user (script) is in charge of ensuring the information is propagated to the objects it needs, in any order it needs.
Exception are what I call live objects, similar in concept to the volatile C keyword. So far those objects have the following properties:
  • They are architecturally simple. They don't have subcomponents and most cannot even be used as subcomponents albeit all can be instanced as objects in the script.
  • They are guaranteed to change atomically before each script is run and guaranteed to be consistent across different script invocations in the same tick.
  • They require (mostly) quite some work to be implemented in script.
  • They are typically backed by native data structures (some even take 0 bytes in script heap memory).
I have found myself pretty comfortable with this approach.

Now, in the case of "natively nested" components, such as the limbs of a ragdoll, you don't update them. They physics API updates them for you and pours out the transforms to your system. Albeit it appears reasonable the parent will be synced first, I specified no order is guaranteed.

So in short I suggest to consider not enforcing an order. But I'm interested in this discussion so please make specific examples. As I learned the hard way, nobody will get anywhere as long as generic objects are considered against arbitrary relationships.

#8 Dmytry   Members   -  Reputation: 1148

Like
0Likes
Like

Posted 05 July 2012 - 07:12 AM

Dmytry, that's usually what I do in a clear owner->child type of a scenario, but it may not work in the aforementioned physics attachment system, since whatever function goes on updating all your objects would probably update the child already. Hence why i said, it depends on the nature of the relationship.

Ideally, the physics should work with 2 states: current that is read only and future that is write only; this helps to make use of multiple CPUs (by making the physics independent of the order of updating). It may be useful to separate e.g. AI updating from physics updating. Ahh, and also, if physics gets different values depending to the order (e.g. two masses connected by a spring, and result depends to which is updated first), that is rather bad and makes it difficult/impossible to ensure conservation of momentum (and energy).

Edited by Dmytry, 05 July 2012 - 07:15 AM.

My game The Polynomial is now available on Steam. | The Polynomial homepage | Cloud and terrain rendering |Everything i said in that post is obviously ABSOLUTE TRUTH my unhumble opinion.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS