It’s time to finally put some characters into our fps game! Let’s get right to it! We’re first guided to download a model off of filebase:
The course has you import the GDHQ fps controller, but I’m going to try to use the one we made. if it doesn’t work out, then I’ll come back and download it.
Next, we would go to the FBX of the mans model and change the animation type to Humanoid, which makes sense. We did that often when making animations for our player in the 2.5D games course.
While we’re now able to shoot our zombies and through our health system damage and kill them, there’s no visible feedback. Todays lecture focused on that.
First we downloaded some blood splatter from filebaseHQ into our assets.
Next, we were given the challenge to instantiate the blood splatter prefab onto the enemy when we hit. We’re to research hitinfo.normal as well as hitnormal.position in order to rotate the splatter appropriately on the model.
To begin with, I think we’re going to need to create a holder for our bloodsplat prefab so I’ll create a variable in our shoot script since…
State machines aren’t optimal when used with if statements. To get the best performance, you’ll want to be using them with switch statements.
So in Update, we’ll lay down the foundations of our Switch statement:
and for each case, we’ll use the different states:
Shooting zombies is fun and all, but it’s like shooting a dead fish in a barrel if they’re not going to fight back, so let’s give them an attack system that will access the players Health script.
To make things simple, when the enemy gets within a certain distance of us, they’ll inflict damage. We can do that by giving our zombie a spherical collider; Voila! we’ve created that radius! Don’t forget to enable ‘is Trigger’!
Let’s make the radius a little bigger by making it 1 unit.
So we just created a damage system, let’s put it to use by now by shooting our zombies. We have a shoot script, and we know what we are shooting thanks to our raycast hit, however if we were to use the name from the raycast, we’de be getting names like “Enemy”, “Enemy 01”, “Enemy 02”. Nobody’s got time to check for different names though, so let’s take advantage of Unitys tag system and give our Enemy prefab an Enemy tag:
Now we can have an unlimited amount of enemies and all we need to do is check its tag…
The next part of making our zombie fps game is creating a health system. We want it to be generic so we can use it on any entity that needs it.
let’s begin by making a Health script and placing it on both the Player and Enemy objects.
So what do we need to know when dealing with health? Generally we’ll need a maximum amount of health or hp, a minimum amount which if it goes under, the object will ‘die’, and the current status. So let’s create some variables in our Health script:
The next phase in our Zombie FPS course had us create a preliminary enemy. As in our Spaceship shooter, we’re still in our preliminary phase so we’re going to focus more on workable gameplay than graphics, so the zombie we’re making is going to be a cube.
Actually, let’s make it a little taller and more zombie/enemy like. let’s make it 3 units tall and give it a red texture.
Today we started by implementing a reticule in our game. First by installing the GameDevHQ hub, and then downloading a reticule set. For the stuff we’ve covered before, I’m going to go over quickly.
I chose Reticule #6. To implement it, I created a UI image, set it to the center by zeroing out its x and y positions, slid the sprite into the source image. It was recommended to resize the image to 64x64, but I felt 48x48 was more appropriate.
We’re currently being taught to write our own camera look system from scratch. To begin, a very simple way for the camera to follow the player is simply make it a child of the player.
As you’ve probably noticed, I’ve already set the cameras position and rotation to be in a place that’s close to ‘over the shoulder’ in most popular games. Here’s the stats:
If you’ve used any kind of 3D program, this will be familiar to you already, but the tl;dr is Global space: Locked coordinate system, Local Space: movable coordinate system attached to any game object.
Here’s a local coordinate system for our player capsule. As you can see when I rotate around the y axis, the x and z axis turn along with the player gameObject. the coordinates are local to the gameobject.