 Okay, your components have an enabled flag, which governs whether that component itself is enabled, but then game objects, they'll have an active flag, which we access through the active self property. Upon creation, every game object starts out active, but we can make it inactive by calling set active with a value false. For whatever reason, they made it a separate method. You can't just set cube active self directly. But anyway, after setting active to false here, active self will be false. And what that does is when a game object is an active, then all of its components, whether they're enabled flag is set on or off, components will be effectively disabled as well. And all the children of that game object, in turn, are also effectively disabled, whether or not their own active flag is true or false. So here we're going to print out the state of our cube, make it inactive and then print out the state again. Let's see that in action. And so cube active starts out true. And well, oops, we have four cubes stacked on top of each other. So you didn't see the cube disappear. But you do see in the hierarchy how it's grayed out. That's indicating it's inactive here. Let me move these out of the way. And hey, you don't see it because that cube is inactive. Now if we leave the cube active and instead set the sphere to inactive, well, that's the parent of all the cubes. So not just the sphere will be inactive, but effectively all the cubes will be inactive, even though all of their active flags are still set to true. So here let's see that in action. The sphere and all the cubes have disappeared. And as you see in the hierarchy, they're all grayed out. Because no matter what the flag is on these objects, their parents somewhere up the chain, their ancestor is inactive. So they're effectively inactive in turn. In the editor, we can set the state of the objects with this checkbox. That's what this checkbox is about. This sets the active flag on an object. And on the renderers, this is setting the enabled flag. So here, as I play the game, all these changes are just temporary if I stop the game. Now I can edit the scene as it's initially loaded. So here if I were to disable this mesh render, that would mean on scene load, that component of the sphere would have its enabled flag initially set to false. Likewise, it could do the same on my object. So like, I'm checking that now the sphere initially when the scene loads is active on the sphere is initially set to false. So something we'll want to do is sometimes destroy our game objects and game components. And we can do so with the destroy method, which is a static method of the object type, but because we're inside a mono behavior class that extends from object. So we don't have to qualify the method name here with the class name. Anyway, so here we're getting the mesh render component from our sphere and passing it to destroy. That'll mark the mesh render for destruction. And by the time the game is rendered this frame, it'll have been destroyed. And we have this overload of destroy where we can also pass in a float value, which is a number of seconds we want to wait before destroying the object. So here we get in the transform of the sphere passing a destroy but saying we want to wait 3.2 seconds. So let's see this in action. Come here hit play. And the sphere basically disappears at the very start of the game and we're waiting 3.2 seconds. And well, actually we get this error because it turns out transforms are kind of component you can't destroy. Instead, you're supposed to destroy the game object, not its transform. So that is not valid. And instead, let's simply destroy the sphere itself after 3.2 seconds and see that in action. So I'm going to restart the game. Game is going waiting 3.2 seconds and then destroyed the sphere. I noticed that the sphere and all of its four children have disappeared from the hierarchy. So when you destroy a game object, you're destroying that game object, all of its components and all of the descendants of that game object, not just its immediate children. Now what does it really mean to destroy an object? Well, it makes the object permanently inactive as far as unity is concerned. And if you try and access any of its methods or anything access its components, et cetera, you're going to get runtime exception. But the object isn't really gone. Like the garbage collector hasn't gotten rid of it. It's really still there. Meaning that any reference we have to in our code, this is still really a reference to that same sphere object. So let's see what happens if in the update, we print out first the test of whether sphere is equal to null. And we'll also print out the transform of the sphere and we'll see what happens. So for 3.2 seconds, the sphere will still exist. But after 3.2 seconds, something's going to change. So let's just keep going 3.2 seconds. Yeah. Okay. So here, let me pause the game. So while the object existed, the test of sphere equals null was of course false because our sphere field was referencing a game object. And then we printed out the transform of the sphere and that's what you see here. But then once the object was destroyed in our update, well, when we try and print out the transform, we get this missing reference exception because once an object is destroyed and not supposed to access any of its elements. And so you get this exception. But very strangely, it's telling us that sphere is equal to null. Well, that's strange, because definitely nothing has actually reached into our class and actually modified the value of the sphere field. So it's really not null. But what's going on is that the object type overloads the equality operator such that when you test for a quality between a game object and null, it'll report true when the game object has been destroyed. So the sphere field of our instance isn't really null, but this test will return true anyway. The idea is that in your code, you may have some checks for whether a game object reference is null or not. But because you're not supposed to use objects once they're destroyed, the idea is that those tests of whether the object equals null should return true, even though those references aren't really null, because we're using these null tests to make sure that we actually have an object. But once an object is destroyed, you're not supposed to use the thing anyway. So just be clear here, this is never null. In fact, that's why we're getting the exception. If sphere were actually made null, then instead of getting that exception saying that we have a missing reference exception, we would get an actual null reference exception. And let's look here. So what if we want to create objects and components? Well, we can create game objects simply by instantiating them, like any other class. And so now we've created this game object, signed it to reference new cube, giving it the name new cube. And when you create a game object like this through the constructor, it just automatically shows up in our scene. But of course, an empty game object by itself doesn't do anything. So we want to give it components. And we can do so with the add component method where you specify the type of component you want to add. And this call will actually return the newly created component, which is useful because in practice you actually want to start messing with the properties of your new components. But here we're just creating a mesh render and mesh filter, and they're just going to have their default properties. So let's see that in action. I will start the game. And there's the new cube, but we don't see anything. We gave a mesh render and mesh filter, but we don't see anything here. I'll just move it a little bit. What's going on? Well, the first problem is that our mesh filter, its default value for its mesh property is nothing. So we'd have to give it a mesh, like so now we have a cube. And the second problem is that we haven't picked a material. So he'll just go in and give this a material. And I'm doing this in the editor here. But of course, in practice, you would want to set these properties of the components in your code. So that's one way to create a game object. But more commonly, what we'll want to do is use the instantiate method of object, which probably should have just been called clone, because that's what it does. It actually takes an object or component and returns a clone of that thing. So here I'll come up with these lines. And what we're doing here is we're cloning the sphere, and we get back a new sphere. And this clone includes a copy of all the components with all the same properties. And in fact, it will also have a clone of all of the descended objects. So you're getting a full copy of what the sphere is. And of course, initially, it's just going to be rendered on top of the existing one. So we want to see it. So let's just move its position here. And now let's see this in action. Come here, hit play. But here is a full clone of the sphere. And where's its cubes? There's the cubes right there. So it also has its own four cube children. And if we look through all the properties, everything is the same. Only thing that's different is the transform of the sphere, which we modified in code. Let's just demonstrate something important about destroy. And that is the destruction only takes effect at the end of the current frame cycle. So here, if we destroy the sphere in this awake method, we can still instantiate. We can still use the sphere because it's not yet destroyed really. So this is not going to give us an error. You know, just show that in action real quick. Yeah, play the game. Yeah, so yeah, we destroyed the original sphere in that frame, but we also got its clone in that same frame. But if instead of creating the clone here, what if in the update, if the user hits F, then we create the clone, we're going to get an error here because this is going to be done in a later frame. And so when we try and instantiate from F, we got this exception because having called destroy on our sphere, it gets actually destroyed at the end of its frame. So when I tapped F after the game had started, that first frame has already gone by and the sphere has been destroyed. And when I hit F and try and instantiate from sphere, well, now we get a missing reference exception. One more important thing to understand about instantiate is that when you instantiate an object, any awake methods of newly created script components, those are initially called during the call to instantiate. So by the time instantiate returns here, any awake methods on the sphere or its newly created descendants, those awake methods will have been called. But the start methods are not called until the start of the next frame. So to demonstrate this, I've created a new cube script and I attached it to the first cube. And that script looks like this. We are simply printing out on a wake, we're printing cube awake, and we're printing the frame count. That's the number of frames that have elapsed. So when this is zero, you're in the first frame, when it's one, you're in the second frame, etc. And then in start, we're printing cube start and also the frame count. And also when we do the instantiation, you'll see printed first before instantiate and then after instantiate. So let's see this in action and see what we get. Play. So first, cube awake zero, that's the cube that exists in our scene upon load. And then the awake method of our sphere is running. So we see before instantiate, the second cube is created and during instantiate. That's when this is called the awake method of the cube is called. And then the instantiate call returns, but it's not until the next frame that we call start on both our original cube and the next cube. Also remember, there's the guarantee that update is not called on an object until after start has been called on an object. So in fact, we won't get our first update on either of these cubes until the second frame. We can prove that if we come here and in our update, add a line printing out a cube update with the frame count. Go back, replay the game. And updates. Yes, so let me stop the game. Letting our log go back to the top. As you can see, the first update didn't occur until after both calls to start in that second frame. So this is something to keep in mind that your objects aren't necessarily active in that frame where you create them. They're really up and going until the next frame. So you have to be careful about that in your logic.