One of the mechanics in our game is the main character struggling not to get detected by the robots who are populating the hospital which they are trying to explore in order to find the phoenix chip, the very processing chip which will save their friend. Our team wanted the player to face the enemy who detected them in order to give life to the game, instead of a game over screen popping up plainly or the level restarting immediately. I thought this mechanic would be easy to implement, but most of the time with programming, something that seems simple, usually is not. I thought that I could just obtain the players camera transform, and make it LookAt(enemy), but that would work if all of our enemies were identical, and they were not. They perform the same way depending on the enemy type, but when detection comes into play they are not the same object. I searched for a solution that did not require instantiation of prefabs, because I knew that it would also require a couple other work arounds in the code, but after a couple hours of searching, and problem solving I gave up, and starting instantiating the enemies. The first piece of a "basic" functioning system to spawn the enemies into the level uses an array of empty gameObjects as the transform locations for spawning of the enemy, and then spawning the enemies using the prefab, and then adds it to an array. I thought this would be the end of the issue, it was not, I had to make every enemy instance separate because as of the moment of instantiation they were still copies of the original and did not have their own components. After the enemies were instantiated, I gave them the necessary script components, and also made sure that every piece that they required for those scripts were able to be obtained through code at the start so that each instance was self sufficient. The GroundBot utilizes 3 scripts, GroundBotHeadMovement, which makes it so the ground bot enemy will rotate in a window of 45 degrees to the left and the right, when the player is spotted the enemy will stop , and their eye will change color to yellow, once the detection bar is filled up the camera will pan to the enemy in question and then you can restart the level, or go to the Main Menu. The state machine script on the specific enemy who was detecting, was what determines which enemy the player would look at when being fully detected. each enemy has a separate state machine script which handles the game over screen mechanic, but when a certain enemies field of view is collided with, a bool is set on the player detection script component which says whether it is a ground bot, flying bot, or a spider bot. This solution to the problem of individual instances took me a very long time, roughly 14 hours to be exact, because I would find a solution, and then that solution would need another piece to work properly. I believe that the hardest part was not instantiating and then giving specific values to the instances, but actually grabbing the components needed to determine WHO was detecting the player. The first 6 pictures are of the spawning scripts for each enemy, the 7th picture is of the GroundBotStateMachine game over mechanic which handles the player looking the enemy, each of the enemies have this piece in their distinct state machine. The 8th picture is of the players detection system which dictates which state machine is used, when the enemy collides with the player, the state machine for that enemy AND the field of view for that enemy who is detecting are set through a function called in PlayerDetection on impact with the FOV collider, this can be seen on the spider field of view script being set in the player detection script in the OnTriggerEnter() in picture 9. Overall this was a big accomplishment for me, and although it was a lot of moving pieces it gave our enemy units more diversity and also gave me a good amount of experience.