Western Shooter Devblog #8 | Script Communication using GetComponent in Unity

In order to further randomize our spawn points, we are gonna need to communicate with the enemy script. We are able to do this by using GetComponent to grab reference to the Script inside of the enemy prefab that we have control of from the Spawn Manager!

Randomized Spawn Points

In order for our Spawn Coroutine switch function to work properly, we need to communicate with the Enemy Script and tell it which direction to go once it’s instantiated, since there are two possible spawn points on either side of the lane.

If the enemy spawns on spawn point 1, then it’s direction variable will need to be changed to Vector.left, and Vector.right for spawn point 2.

So here we’ve modified our switch function to grab our _enemy prefab, use GetComponent to access the Enemy script, and then change the public direction variable to Vector3.left if the Right Spawn Point is chosen.

The _direction variable is set to Vector.right by default so we won’t need to change it if they spawn on Spawn Point Left.

And that’s it for our Spawn Manager!

Now we just need add a little more randomization to our Enemy script, and develop its behavior for getting closer to the player.

To add a little more randomization and to avoid multiple enemies passing through eachother that are in the same row, I added a simple Random.Range to the z position of the enemy once it first spawns, it’s only a slight change, but noticeable!

Look at that! Our enemies are spawning and they aren’t phasing through eachother like ghosts!

But we don’t want our enemies to walk back and forth indefinitely until they die. Let’s create a system where after a few laps, they’ll appear in the next row closer to Cubert.

So here I’ve upgraded the enemy’s movement behavior to give us more control and functionality. So from top to bottom we have our enemy movement tied to a simple if statement that will allow us to stop the enemy from moving when we need to by the _canMove bool.

Next, to fix a small issue where the enemies are able to shoot through the walls they move behind, we have an if statement that declares once the enemy goes behind either wall, _canFire will be set to false by the else statement at the bottom. Which will of course turn off enemy shooting by our updated shooting script.

Lastly, we have our else if statements that will add a lap to our _currentlaps variable each time the enemy reaches one side of the lane, as well as immediately changing direction and go the other way for another lap.

Now we can have an if statement for once the player reaches a certain amount of laps, we can reset the _currentlaps to 0 and move them to the next row forward using a Coroutine!

We’ll do a basic transform to move them to the next row, and then use our _canMove bool to stop the player, and control how long until we want the enemy to appear in the next row.

As you may have seen already, we have a second if statement declaring if _canWin = true, then we destroy the enemy and print a debug log. This is a second win condition for the enemies.

If an enemy reaches this WinBox object, on their 3 lap before the player stops them. They will have reached Cubert and the player will lose the game.

And with that, we have finally finished our Enemy Spawning System! We created a couple other features a long the way which made it take little longer but we can finally see it all in action!

Wow, we’ve come a long way eh? Well, I think we’re atleast at a point now where our prototype has served as a proof of concept! Why don’t we start making our game a little less square? (get it?)

In the next devblog maybe Cubert will finally get some arms! …and just generally be less cube-like.