The proper use of Awake and Start

I have been using Unity for quite some time now and I realised that I was moving more and more initialisation code towards the Awake method.
A lot of Unity's manuals and tutorials make extensive use of Start, though.

From how I understand this, since a MonoBehaviours constructor is not to be used, the only worthy alternative is Awake. As an additional fact, the execution-order explicitly calls all Awake methods before any Start. To be consistent, every GameObject should wire itself before accessing one another, hence using Awake for the first and Start for the second part. It also means the script can be disabled and still be accessed from another gameobjects Start without worries. It's less error prone to do it like this because you know everything is setup when you do something cross object in Start.

It feels like I'm missing something about Start why it's used so much. Most of my code doesn't even have Start. So the question is more about "what is Start for, despite from initialisation through external resources like singletons"?

 

You hit the good rule of thumb for Unity method usage: Awake is for initializing my stuff, Start is for initializing your stuff. Use Awake to create arrays and other completely internal dependencies. I would caution against even accessing static service locators inside of Awake, because you can't know if the service has fully initialized itself yet. Start is the best place to flesh out external dependencies, like singletons and services.

An interesting thing to bear in mind about the Start method is that it won't run until just before the MonoBehavior's first Update call (or what would have been an update call, if the class doesn't implement update). If something prevents Update from running, such as the MonoBehavior's GameObject being disabled, then Start wont have run.

 

A lot of Unity's manuals and tutorials have a bunch of bad code in them!

The default MonoBehaviour should probably have Awake as the initialization method instead of Start. Always use Awake unless you're reliant on other objects having run their Awake.

 

Since you're answering this @Baste , what makes you so certain that there's a lot of bad code? Are you in close contact with the Unity Team? Are didn't they just not put too much into when they wrote it the first time?
I mean wouldn't be the first time that the docs are somewhat outdated, but Awake and Start have at least existed since Unity 2.x (I don't know any older version).

 

its more that "good code" is more complicated and they were trying to not scare off complete newbies with lots of syntax and a huge learning curve to just get the simple stuff working.

So you'll find public variables everywhere (not serilalized private/protected), simplified designs and approaches, unscoped getcomponent calls in update etc.

 

Good point.

 

Before we had the script execution order panel, Awake vs. Start was the only way to make sure B's initialization code ran before A's (*). The docs (even the current Start,) implied (IMHO) that it was safest to use Start, saving Awake for when you needed to force someone to run first.

The only reason I can think to care, now, is for prefabs: Awake runs during the Instantiate line, whereas Start runs after you've quit.

(*)Unless you were a programmer already, in which case you instinctively wrote an init() function and called them all yourself from the main object.

 

Just to be safe, I always try to put all of the initialization code in Awake, and try not to use the Start function. It's also important to note, as someone else pointed out earlier, that the Awake is always called on a script, but the Start function is not called unless the MonoBehaviour is activated. So Start is more or less a way of Unity letting the script know that it is ready to start running the script's Updates for the first time. (i.e. ready to "Start" running the Updates).

One good use of Start is when you need to use the Physics.IgnoreCollision.

Also, baking GI emission ( DynamicGI.SetEmissive) appears to not work when called from a script's Awake (at least this is what I found when using Unity 5.3.6).