Final Project Week 2 - Weapon Characteristics
This week I worked on the different shooting characteristics that will change how the weapon is used by the player, this includes fire rate, fire mode and ammo. I also made some changes to the system that will allow the developer to change the stats for each weapon in their game.
Fire Rate
I wanted to make sure that my rate of fire was easy for the developer to understand so that they know exactly what number they need to use for the fire rate of their weapon. To do this, I made it so that the value the user inputs is the rounds per minute (RPM), this is a measurement used in real life weapons. so if the user is making their weapon to replicate a real life variant then they can find the RPM of that and input it directly.After I had the rate of fire complete, I came an issue where if you have low frames per second (FPS), or a high RPM weapon, it will not shoot as fast as it should. This is because the rate of fire was being limited by the frame rate. I wanted to make sure this is actually what was happening, so tested with 10000 RPM, with this RPM, 1000 shots should take 6 seconds, but in reality, it took around 16 seconds to make 1000 shots. This makes sense because at 60 FPS, it will take 16 seconds for 1000 frames to be shown.
10000 RPM is an extreme example, very few real weapons can actually shoot at this speed, however, this issue can also happen at lower RPMs, so I had to fix it. The way I decided to fix the issue means that in some frames, multiple shots can be fired, this will allow the weapon to shoot at it's full speed. below I have included some of the code I used to make this work.
 |
 |
| Code that would limit the fire rate to the frame rate | Code used to ensure the weapon fires at its full RPM |
The problem previously was that no matter how long it has been, the cooldown for the next shot will be reset, but what I had to do was add the cooldown for the next shot on top of how long it has been since the last shot. This had to be done until the cooldown went above 0 again. This meant that multiple shots may be fired each frame to allow the fire rate of the weapon to remain the same no matter what frame rate you are playing at.
Fire Mode
I started my system with the automatic fire mode, this means that the player will hold the shoot button, and it will automatically fire until the player lets go of the button or they run out of ammo. this one was the simplest to set up and didn't have me running into any unexpected issues.Next, I moved onto the single fire, on the surface, this seemed to be as easy as automatic fire, and getting it set up was, instead of checking if the user is holding the shoot button, it checks if the user pressed the shoot button that frame. Then the user will have to let go of the button before they can shoot again.
While that system worked, it sometimes felt unresponsive, as if the weapon didn't react to every click, for a while it was hard to figure out what the actual problem was, but I realised that it was because of the fire rate of the weapon, if you click before the weapon is ready to fire again, it will not allow you to fire until you have released the button. This seems like it makes sense, but it felt quite frustrating while you were playing.
To fix this, I have to check if the player is currently pressing the button, this will allow the system to shoot immediately after the weapon is ready, even if the player did not push the button on that exact frame. But to stop it from shooting continuously, it checks if the player has released the button since the last shot.
 |
 |
| Old method used for single fire | New method for single fire to improve responsiveness |
I did some playtesting after making this change, I didn't tell players what the difference was, but asked them if they could notice the change. Most players thought that the difference was the rate of fire of the weapon, which is because more of their clicks were being registered meaning there was less time between shots making the weapon feel faster. One player mentioned that they felt the old method was ignoring a lot of their shots, while the new method felt like they had more control. This playtesting was good because it allowed me to make sure that the new method used for single fire is beneficial to the overall feel of the system.
After finishing the single fire, I moved onto burst fire, burst fire is like a mix of burst and automatic fire. When you take a shot, the gun will fire multiple shots. I have seen different types of burst fire in different games. Battlefield 4's burst system will fire all of the shots, even if the player releases the shoot button, where as ghost recon wildlands will only shoot while the button is pressed, but still requires you to release the button before making another burst. Battlefield also has different amounts of burst on their weapons, for example, most guns have a 3 round burst, but a few have 2 round burst meaning that when you pull the trigger only shouts are fired, instead of 3.
I decided to take more inspiration from the battlefield system, the way the gun will shoot the whole burst felt better to me, because it felt like their was a clear reason for having the burst fire mode, the ghost recon system felt more like a strange hybrid between burst and single, and the same effect could have been done by simply tapping the shoot button. I will also implement the variable burst mechanic. I want my system to be as modular as possible, so if the developer using my system has a specific real gun in mind, they should be able to set the burst amount to a realistic number.
Modularity
Originally, all variables for the weapon, were in the system script, this was originally done while I was testing because it would allow me to quickly test different variables, however, this isn't favourable because if I want to make a weapon switching mechanic, or the developer would like to create prefabs of their weapons, they would have to store the stats for the weapon separately, or use the same for each weapon. This is obviously not what I want from my modular weapon system. to fix this issue, I now have 2 scripts that will control the weapon, "WeaponSystem.cs", which will hold all functions and handle all user input, and "Weapon.cs", which holds all of the variables for the weapon. Having these separate allows the system to look at the weapon that is currently active, and use the variables in that weapon to change the feel of the weapon. |
| Weapon switching, each weapon has a different appearance and stats |
Now that this new modularity was implemented I decided to make weapon switching, this would be useful to developers using the system, and will also allow me to more efficiently show the system that I have created, and how the variables on the weapons can change the feel of the system. Above is a clip of the switching in action, each gun has different sway amounts, fire mode, fire rate and ammo count. These weapons could also be given different models to match their different stats.
I planned for the tasks this week to take a lot longer, so I planned to spend next week on them aswell, however, I managed to get everything completed, because of this I will move all of my planned tasks forward a week.
Next week I will be working on the dynamic bolt system, that will allow the weapon to look like it is animated, without actually having to create any animations for the weapon, this will allow the developer to change the fire rate and have the weapon react accordingly.
The GitHub for this project is available here: https://github.com/ElliotChester/Modular-Weapon-System-Final-Project
Comments
Post a Comment