In this lecture, we'll revisit our Ted the Collector game to make it a little more interesting using a list and iteration. Let's go check it out. I've changed the functionality in this game by what appears to be just a little bit, but it actually leads to a whole bunch of code changes. I'll start by showing you how the game works now. I still right-click to place Dr. T heads, and I still click the teddy bear with the left mouse button to make it start collecting. But now it actually goes to the closest pickup, not the oldest pickup. If I add pickups along the way it will change direction and pick up those closest pickups, and then I can place more and it will go to the closest one first and so on. The Ted the Collector code has minor changes. We save a reference to a TeddyBear object, because we're going to need to call a method in the TeddyBear object, so we need a reference to the teddy bear. While I could have marked this with serialized field and populated it in the inspector, I decided I wanted to find it using its tag. So I added a TeddyBear tag to the teddy bear prefab, just to show another way that we've already seen when we looked at tagged destruction, but another way to actually find game objects. I still have a list of the pickups in the game. I changed my properties, so now I don't just return a target pickup, I actually return a list of all the pickups that are currently in the scene. I've added a start method to retrieve the teddyBearGameObject. I find it with its tag, and then I get the teddy bear script attached to that teddyBearGameObject and put it into this teddyBear field. Just as a reminder, we've used GetComponent a lot to get things like the rigid body 2D and so on. But we can use GetComponent to get scripts that we've attached to game objects as well because remember scripts are just components like all the other components we have. In update when the player presses the right mouse button, we do all the things we did before, but we also call this new method in the teddyBear that has the teddy bear update its target. This is the method that we'll take a look at, that makes it so the teddy bear can decide, I no longer should go toward my current target pickup because the new pickup that was added is closer, and that's why the teddy bear will change direction and go after a new one that we've placed that's actually closer. RemovePickup works exactly the same as it did before. We have massive changes in the TeddyBear script. These are still the same fields. In our StartMethod we do the same things we did before. We do the same thing on MouseDown as we did before. It looks like there aren't any changes yet because OnTriggerStay2D use the same as well. But here's where things start getting different. Remember the update target is the method that Ted the Collector calls when a new pickup has been added to the game. If our current target pickup is null, which it will be when the first pickup has been added to the game or when we finished collecting all the pickups and then the player added another pickup to the game, we set our target to be that pickup that just get past it. That's an easy one. If we don't currently have a target then this is our new target, so we set target. If we do currently have a target pickup, we have to decide if this new pickup is closer. The first thing we do is we call a GetDistance method that I wrote to get the distance to our current target. That method just uses a built-in vector3 distance method to calculate the distance between two objects, the teddy bear and the pickup that I pass in as an argument to the method. I pass in my current target to that method, and I save the result in my target distance. Then I calculate the distance to the new pickup that was passed in here and check to see if it's less than target distance. Because if it is the new pickup is closer to the teddy bear than my current target pickup, so I need to change my target. I call SetTarget with the pickup that was passed in. To set the target, first I set my target pickup field to the pickup perimeter and then if I'm currently collecting, I go to the target pickup. I need this if statement because remember, this set target method gets called with the very first pickup also and I don't want to just start moving toward that pickup when I set it as a target because I'm not collecting it. I haven't been clicked on on my collider, so I'm not collecting it. I only want to go to the target pickup when the set target is called if I'm currently collecting and this will make it so I change direction and go to a different pickup. The GoToTargetPickup method is exactly as it was before. The GoToNextPickup method is an interesting one because it sets the target pickup field to the result of calling another new method called GetClosestPickup and if the target pickup isn't null, I'll go to it just as we've seen going to any other target pickup. But if it is null, there are no more pickups to pick up right now, so I set the collecting flag to false. The GetClosestPickup method does some interesting processing with a list and with iteration. The first thing I do is I get the list of all the pickups in the scene right now, by accessing this new property in the ted the collector class, I declare a couple of variables here. I want to keep track of the closest pickup and I went to keep track of how far away I am to the closest pickup. If in fact the list of pickups was empty, then I return a null, and back here and go to next pickup. Remember that's why check if it's null, because it could return null. If the list of the pickups in the game is at least one big, then I know I should walk through all the pickups and find the closest one, and that's the one that I should return from this method. I start by assuming that the first pickup in the list, the element at index 0, is the closest pickup and I calculate the distance to that pickup. I could find out this assumption is wrong. I may walk through the rest of the list and find one that's closer and that's great. If I do, then I'll replace this. But I can start by assuming that the 0th element in the list is actually the closest pickup. Here's where I use iteration and I'm using a foreach loop to go through the list of pickups. I will confess I could have optimized this and avoided the very first loop iteration by using a for loop that starts io one rather than zero but I just decided that that was an unimportant optimization for this particular example so I'm using a foreach loop instead. I'm going to look at each pickup in my list of pickups. What I'm going to do is I'm going to calculate the distance to that pickup and I'm going to see if the distance to the current pickup is less than the shortest or closest distance that I have found so far. If it's not, this pickup isn't a closer than the closest pickup I've found is so far, so I don't do anything. But if I did find a new closest pickup, one that's closer than the closest pick up I've found so far. I set closest pickup to pick up and I set closest distance to distance so that next time through the loop, closest distance has been updated to be for my current closest pickup. I just keep going through this loop, replacing both closest pickup and closest distance as necessary as I find a closer pickup. That means that when I'm done with the loop, I've actually found the closest pickup that's in the scene right now and that's the one that I return. This pattern of assuming the 0th element in the array or list I'm processing is that extreme value, either a minimum or a maximum, is a pretty standard pattern for looking for an extreme value, a minimum or a maximum in an array or list. You should make sure you understand how this works so that you can use this pattern whenever you need to do it and if you really want to do the optimization of avoiding that first loop iteration and using a for loop here instead of a foreach loop, that's perfectly acceptable as well. It's still the same pattern. To recap, in this lecture we saw another interesting use of a list and iteration in a small game.
