Jump to content
  • Advertisement
Sign in to follow this  
AxeGuywithanAxe

Unity Game Object Update Order

This topic is 895 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys, I wanted to get an opinion on how some of you guys handle game object update order. Do you guys just go through the list and say "screw dependencies" like Cryengine/Unity, or do you use dependency graphs like UE4/Killzone Engine. Thanks

Share this post


Link to post
Share on other sites
Advertisement

Well off of my the top of my head I can think of two dependencies that might be in an engine. Lets say you have a MovementComponent and a SkinnedMeshComponent. (My component model is similar to UE4 in that I have primitive components that have transforms (i.e SkinnedMeshComponent) and logic components , like MovementComponent). The movement components job is to update the SkinnedMeshComponents transform prior to animation evaluation. Because of this, the MovementComponent should run prior to the SkinnedMeshComponent. Another dependency is based on children. If one component, lets say a player, is on a vehicle.. the vehicle should update first.

Share this post


Link to post
Share on other sites

True dependencies are actually pretty rare in most game logic, in my experience. If your update code is highly order-dependent you might consider using different methods that aren't so fragile.

 

In this rare case I have to strongly disagree with Apoch unless I'm miss-reading the intentions here or I'm reading more into the question than he was..  Everything is about order and in fact the OP is incorrect about Unity, there is order control built in, you can tell the engine the order of execution you want.  Additionally, when it comes to the future with multi-core, without execution order control you simply can't effectively utilize current CPU's.  (Well, not that I know of 'effectively'.)  I don't disagree in that it *can* be fragile, but it is much like bad patterns in C++, you learn to avoid the parts that cause issues.

 

Having said that, let me rephrase it so the negatives have some context.  Unity has ordering in terms that you can control which 'components' execute before other components.  I think they call this the priority system or something like that.  The purpose in Unity seems to be making sure that an AI update component can complete making decisions before any movement is calculated in that frame.  This is fairly trivial common sense behavior I would think.  But, perhaps, what Apoch was suggesting is that this is 'system' level dependency and not individual object to object relationship dependency.  What I mean is that i always update AI before physics, I can apply impulses via the AI and have those acted on when physics updates, I never try to interleave AI and physics, this is *system* level dependency.  The other, bad, option is that I write a follow behavior that executes at the same time as the AI for the object I'm following, well, which one updates first changes the behavior of follow since I could be following last frame or next frame's position.  It's just bad news.

 

So, depending on the OP's intentions, dependency always matters.  It depends on where you apply it as to if it is a problem or not.

Share this post


Link to post
Share on other sites

Well the reason I don't want to do a hard coded version like

for( auto* MovementComponent ..)

{

 

}

for( auto* SkinnedMeshComponent)

{

 

}

is that in some cases, a skinned mesh component isn't being modified by a movementcomponent. Or there are hundreds of different scenarios, like maybe update this CrowdComponent, then update this movement component.. then do a post update of componentY and X. So I don't want a hardcoded scenario of spaghetti code and am leading more towards a generic approach like killzone/UE4. I understand how to build a well balanced dependency graph, I was just asking if anyone else actually does a dependency graph system, or if you guys just haven't found enough reasons to use one in a multithreaded environment

Share this post


Link to post
Share on other sites

I believe you may have misinterpretated what I stated AllEight . I understand that there is some type of dependency , like AI->Physics->GameObjects... etc. But I was speaking about the fact that Unity doesn't state that a parent game object will be updated prior to a child game object.

Share this post


Link to post
Share on other sites

Well the deal is that Killzone uses the dependency graph to thread it's entities. And this is a really terrible way to go about things, as most of the dependencies are honestly weak. Unreal uses the Dependency Graph to schedule tasks, but it's unrelated to the game logic. The Documentation even tells you that UE4 is single threaded, and is order independent. It will probably have use in any choreographed scene... but other wise... no.

 

Well off of my the top of my head I can think of two dependencies that might be in an engine. Lets say you have a MovementComponent and a SkinnedMeshComponent. (My component model is similar to UE4 in that I have primitive components that have transforms (i.e SkinnedMeshComponent) and logic components , like MovementComponent). The movement components job is to update the SkinnedMeshComponents transform prior to animation evaluation. Because of this, the MovementComponent should run prior to the SkinnedMeshComponent. Another dependency is based on children. If one component, lets say a player, is on a vehicle.. the vehicle should update first.

There is no dependency between the Movement and Skinned component. If you somehow got a dependency between the two, you're doing something terribly wrong. The skinned component, which I assumed is a skinned mesh, can be triggered by literally anything, and has no direct ties to anyone's system. Therefore, it's simply a message listener.

The only thing that a skinned component would honestly be dependent on, is the world transform of an object. A movement component should not be responsible for that, because that's part of any object that occupies a volume in space, whether it moves or not. This is why Unreal hard codes it into a number of their objects.

Edited by Tangletail

Share this post


Link to post
Share on other sites

I've actually looked into the task scheduler system for UE4 and at the beginning of the frame it goes through all registered FTickFunctions in a function like this


TArray<FTickFunction*> TicksThisFrame;


for(TickFunction* Function = Level->AllTickFunctions)
{
   for(FTickPrerequesite& TickPrequitie : Function->Prerequesites)
  { 
    //has already been registered for updating
     if(TickPrereq.UpdateFrame == Level->CurrentTickFrame)
      continue;

   //register this prerequesite first
      TickPrereq.Function->RegisterPrerequesites(TicksthisFrame);
  } 

   //now register this tick
   if(Function.UpdateFrame != Level->CurrentTick)
       TicksThisFrame.Push(Function);

  //update the cached frame
  Function.UpdateFrame = Level->CurrentTick;

}

So idk how it can't be related to game logic. The dependency between the skinned mesh component and the movement component exists because the movement component must modify the world transform of the skinned mesh component before the animation composite pass, where the skinned mesh component finally generates it's world space bone matrices. There are other dependencies that may exist in the engine, but this was just one I came up with, because UE4 has a similar system where the movement component is updated prior to the RootComponent so movement updates aren't a frame behind.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!