 As we discussed earlier, Unity scenes are stored as .unity files. And these are actually just text files. So if I come here and open this in my text editor, we'll see it's a YAML format file, but it's just showing all the elements that make up our scene, all the game objects and their properties just in the textual format. A similar kind of asset is what's called a prefab, and prefabs are created by taking individual game objects and dragging them into the assets window. And it's created here a .prefab file. If we go back to the assets, it's now this cube.prefab. I can open it in a text editor, and it looks very much like a scene, but it's just describing that one game object and any of its descendants. This game object just had the one child, so that's what we see here. So a prefab is like a scene, but it's just one game object and its descendants. Having created this prefab, what we can then do is create instances of this prefab in our scenes. And in fact, we can have multiple instances within any scene. So here now there's the two instances, now there's three. And the blue text here is indicating that this game object is an instance of a prefab. That's what that means. So if I come to the prefab and I modify it, like say I'm going to give the cube of the prefab, I'll give it a blue material. And now for all these instances, their cube objects are blue as well, because they're linked to the prefab. I can come to these individual instances and I can modify them so that their particular values are different from the prefab. And you'll see here as I edit the transforms, they're now in bold indicating that they diverge from the prefab. I don't know why the rotation is now bold, it's obviously the same as the prefab, it hasn't been changed. So this bold highlighting is a little flaky in my experience, it doesn't always reliably indicate when something has been overridden or not. But anyway, that's what it's meant to indicate. And so here on this particular instance, if I change this blue to purple, the property is now in bold indicating that it's overriding the value inherited from the prefab. So now if I come to the prefab and edit this to let's say green, well it's not affecting this one because this one has its own overridden value. If I now right click and revert value to prefab on the instance, and now it's back in sync with the prefab. Though again, notice for some reason, it's in bold erroneously suggesting that it's overriding the prefab value when it's not. Again, the bold highlighting in my experience is pretty flaky. So don't take it too literally. Anyway, so that's the idea of a prefab. It's an asset which represents a game object and all of its properties, along with all of its descended objects. And you can use it like a blueprint for actual instances in your scenes. And be clear, if I had other scenes, I could use the same prefab in any one of those scenes. Now if I were to delete this asset, notice that the instances have all gone red. That's just unity trying to help us out and warn us that there's instances that have lost their connection to the prefab from which they were made, which perhaps can happen unintentionally. In this case, it was intentional. So to tell unity that these aren't meant to be instances of any prefab anymore, I'm just going to highlight them. And then under game object, break prefab instance. And now you can see the text is black again, because they're just ordinary game objects not linked to any prefab anymore. Now one common reason to create prefabs is that you want to have something put in your scene, but not necessarily at load time, you don't want it to be there at the very start on load. So what you do is you take that game object, you make a prefab out of it here, I'll make this a prefab again there. Now we have our cube prefab. I'll just create a script here, call it prefab demo, and open it in Visual Studio. And I'm going to give this a public game object field. I'll call it prefab. And I'm going to get rid of all these cube objects and attach the prefab demo to our main camera just so I have some place to put it. No real relation to the camera just got to put it somewhere. And in here, for the prefab field, we will drag the prefab onto it. And now what's going to happen, Unity will create an instance of the prefab and assign it to this prefab field. They'll be clear if I play the game right now. No cubes show up, we don't get any cubes, because the game object created for this prefab field isn't actually part of the scene. But if we now come in here and use instantiate, and pass it the prefab, this is effectively cloning the object, but the clone created here will actually exist in the scene. So now if I come back here and play, you'll see that yeah, there's the clone that was created from the prefab. So a common practice then is to put together prefabs in your scene, make the prefab and then delete the actual instance, and then create the instance later using instantiate in the game logic. Yes, of course, in this example, when we called instantiate, it was in the start method of an object that exists at the beginning of the scene. But of course, we can call instantiate at any point, we don't have to do it necessarily at the start of the scene, it can be done later. One reason to make prefabs is to make game objects that can be distributed in packages. For example, Unity has some stock asset packages here under import package. There are various assets in these packages that are useful, particularly for early stage development. Like say, I've already imported this characters package into my project. And so here under standard assets, under characters, we have a first person character and a third person character. Under third person character prefabs, there's this third person controller, which I've created an instance of here. And now if I play this game, and as you can see, we have this animated character, which I can control with basic access input, space to jump, you can walk up slopes, collide with the geometry, and even ducks, this is pretty cool. There's auto ducking, that's a little flaky, but it's pretty neat. So there's a lot of behavior that comes stock with this character. And that's just all under this prefab notices is to scripts attached. There's a collider rigid body for physics and obviously a lot of animations going on here. We won't go into the logic, just understand obviously you probably wouldn't ship a game with this stock character in there, but maybe use this third person controller prefab as a basis and swap in your own model and animations. That's a pretty good way to start. We also have a prefab for a first person character called FPS controller. And here I'm going to disable the main camera game object and the third person controller, and enable the FPS controller. And under this FPS controller, it has its own, did that not stick? Come on. Why you're not enabled? There we go. It has its own camera. And that makes sense because the FPS controller, if we just double click, it's just this bounding capsule. It's just a collision capsule. And there's a camera that is attached to it that moves when the capsule moves. Actually, it's not an ordinary capsule collider. It's this thing called the character controller, which is a special variant of a capsule collider, which has extra logic for moving the capsule collider to positions that aren't occupied by static colliders. There's a special move method where you can tell it to move, but it won't actually move the capsule to intersect anything in the scene. Like it won't move it to intersect the floor or this slope here, it won't intersect it when we move it. So we didn't get into that when we talked about physics, but you might want to look at that's the component being used here. And there's also key logic here in this first person controller script, which I won't go into. I'll let you look at that yourself. Anyway, so now if we play the scene, we should spawn as a first person controller. And I can mouse look around and use WASDA to move around just like doom controls. I can walk up the slope, fall off. And I can jump with space. And notice I can't walk into these pillars because they are static colliders. And I can jump off the edge. Nope, there we go. Okay. And that's a pretty good start for any first person game. Notice this doesn't include anything for rendering hands and interacting with objects or shooting guns or whatever. So you'd have to add that in yourself. But this is a pretty good start for just walking around an environment in first person. So in my opinion, this character's package here is really probably the most essential of these stock unity asset packages. Though you should definitely poke around in these other ones. vehicles, for example, has some prefabs for an aircraft with basic aircraft controls, there's a car with basic car controls. And you again, probably wouldn't use this stuff stock in any project, you wouldn't ship with these prefabs. But you might use them as a starting point and tweak from there, or just take them as models to imitate in your own implementations. So they're definitely worth a look. There's interesting stuff in here.