Unit 4:Project Design Implementation and Evaluation - Week 18

As planned, a lot has been done this week, and a lot of progress has been made. Apart from game logic, the game is pretty much working, meaning if I was to sketch a prototype of the game logic (which I might just do next), the game would be playable, only ultimately missing polish and final details.

This is a list of things that I implemented into the game as of this week:

  • The weapon is now automatic instead of the default single-fire mode;
  • The weapon now has ammo;
  • You can now reload the weapon;
  • Weapon reloading animation;
  • The weapon now has a random recoil pattern when spraying;
  • Added bullet hole decals;
  • Added a dynamic crosshair;
  • Fixed the firing so that the bullet projectiles will now go wherever you aim;
  • Added sprinting;
  • Added crouching;
  • Added simple AI with health in order to test shooting (still in early stages);
  • Added simple objective that displays on the HUD (still in early stages);
  • Made improvements on the third person camera;
As you can see the list is pretty significant, and the amount of work done this week is far greater than any other week's work. I plan on heavily working on the game during this Easter break, and I reckon that A LOT more progress will be made. 

But now, I'm going into a bit more detail on this week's development summary.
For starters, take a look at this gif:

As I hold down the firing button, you can see that the weapon now has kick-back. You can also see the bullet holes on the wall, the ammo counter, crosshair and reloading animation.

You can also see me trying to control the recoil here. The recoil is completely random within 2 float values for each axis (yaw and pitch). This means that while it is completely random, it can only kick-back so much.

Click to enlarge
Here you can see the whole blueprint for not only how the recoil is setup but how most of the shooting is set up. Basically a LineTrace is there to determine where the player is aiming and send the bullet projectiles from the weapon socket towards the middle of the screen. Essentially everything is revolved around this LineTrace command, the camera, the bullet projectiles, the bullet hole decals spawning points, the weapon socket location which communicates with it.

Click to enlarge
While on the topic of firing, here is the system for automatic firing. Very straight forward, based on whether or not the weapon has ammo, that will decide if the player can shoot, and when they do, the custom event for firing takes place, communicating with the fire rate variable, until the magazine is empty, preventing the player to keep shooting. After reloading, the whole thing repeats.



Speaking of reloading, this is how it is executed. When pressing R, the Reload function takes place (see below) at a delay.
Click to enlarge
This is the function. Simpler than it looks, basically a few integer variables are involved, and determine the amount of ammo available, max ammo and magazine size. I set this up in a way that when reloading, every bullet left in the magazine is gone - as opposed to modern FPS games, where reloading with bullets in the mag will carry them over to your inventory. This is just to test the reloading at first, as I initially meant to mimic the modern reloading system mentioned above, however, I decided to adopt this system instead, as I concluded that it adds more towards the gameplay value, making every bullet count and making the act of reloading more strategic.

Regarding the crosshair, I tried making a dynamic crosshair - spreading whenever the player moves.
Due to an unidentified bug however, there appears to be two crosshairs on the screen, even though the crosshair spreading works just fine. This is not game breaking whatsoever, rather mildly annoying.


This is the ADS (aim down sights) system. It simply modifies the field of view from the third-person camera every time right mouse button is held. The timeline you see there is basically determining how long it takes to zoom in and out.


Here I am showcasing the sprinting and crouching.



These two simply determine the player's movement speed based on whether they are crouching/sprinting or not.
And this is how they seamlessly transition between each other, just like every other animation.


Lastly for the implementations I will talk about the AI, and the moving onto working on game logic in the near future.

Here you can see me shooting some AI, with some debugging information on the top left telling me that the bullet projectiles are hitting, and after a few hits and the AI's health going below zero, they are destroyed and therefore taken out of the game.
Other than changing how the AI looks, moving some of them around and animating them falling over when health is below zero (yes falling over, since the AI will essentially be cardboard targets, like the ones you see at shooting ranges), this is most of the coding needed for the AI. This also means that game logic will not be as complex as I initially imagined, and will most likely be easy and quick to develop.

That will wrap it up for this weeks development progress report. Like I said, I plan on working hard during this Easter break, and really get through a big chunk of implementations.

Comments