I’d like to drop some info regarding a bit where Rick and Sam were talking about the panels each being their own canvas, and Sam said :
“That’s a choice that we’ve made. It’s not particularly backed up with any necessity to use different canvases.”
This is a blog post by Unity Technologies (updated in 2021):
It mentions that each Canvas is an island that manages and groups all the geometry generated under it. So changes to any of the renderable UI stuff under it makes it have to recalculate the geometry for ALL the possibly-thousands of renderable stuff— which they mention, can cause noticeable multiple-millisecond CPU spikes.
Realistically speaking, this may not be a problem if your UI is really simple but you can imagine that it can get unnecessarily wasteful as you make it more and more intricate.
So having one giant Canvas for your whole UI is not recommended by Unity. Just separate out different parts of your UI into different Canvases where they make sense and however they’re easier to work with. And especially where performance is super important, separate the UI parts that get updated a lot from the parts that stay mostly static.
However, they also mention that you can nest canvases (ie, put Canvas GameObjects as Transform children of other Canvas GameObjects) and you’ll still get the benefit of using multiple canvases.
You can also nest canvases, which allows designers to create large hierarchical UIs without having to think about where different things are onscreen across many canvases. Child canvases also isolate content from both their parent and sibling canvases. They maintain their own geometry and perform their own batching.
Child/Nested Canvases will inherit the effects of the CanvasScaler of its parent Canvas. (Adding a CanvasScaler component to it will warn you that it’s unnecessary.)
So, no worries. The sample project in the course is doing the recommended thing in this regard.(?)