Final Project Week 5 & 6 - Winter Break


Over the winter break I had only planned to go over my code, fix any bugs and optimise any code i could find that needed it. I had planned to do this in the first week of the break but my time was taken up by another university module as it was the last week we could work on it. Because of this i decided to take on the work in the last week of the break, this was actually good because it allowed me to look at the project with fresh eyes and see issues that I previously didn't missed.

The majority of what I did in the end was just cleaning up the code so that it could be read easier. however there were a few changes that could have a significant affect on gameplay and performance.

Moving reload to a coroutine

The first big change I made was moving reload to a coroutine, I did this because previously the system would check every frame if the reloading bool was true. This was a bad because for the majority of the time, the player would not want to reload and it would just be wasteful. This also helped with readability of the code because to somebody who was not familiar with the system it would look odd having reload called every frame.

By moving reload to a co routine reload can now be called when it needs to be used and there is no need every frame to check if reloading is true. This will improve performance and allow anybody looking at the code in the future to more easily understand how it works.

Fixing unregistered mouse clicks when shooting

Another big thing that I changed is how the player shoots burst and semi automatic weapons. I mentioned in a previous blog that I had created a system for firing semi automatic weapons that would fire if the mouse button was pressed, as long as it had been lifted since the last shot. This was in an attempt to improve the player experience. After doing some play testing it was clear that the system I implemented had an improvement, users could tell that the system was more responsive, however it had an issue very similar to the original one. If the user clicked their mouse too fast, they could lift the button before the system is ready to fire.

To fix this I change the system to shoot as soon as it is ready if the user clicks before the weapon is ready to shoot. This means that you can click as fast as you want, as long as you are clicking as fast as or faster than the weapon can shoot, it will shoot at its maximum fire rate. This has a very notifiable improvement over the last iteration. While the 2nd iteration was able to reduce the amount of unregistered key presses. This one will never miss, if you click, your action happens. Not being able to click too fast allows the user to focus on other aspects of the game such as aiming at the enemies or focusing on their ammo count.

Breathing

The last major change I have made to the project is the breathing mechanic. This is used to add a small amount of passive sway to the weapon, when not aimed this is a purely visual change. However when aiming this can be used partially for visual effect, but also to add a small amount challenge and thought into an otherwise simple system.

I tried a couple of methods to make this work. the first one worked much like my weapon bob using sine to get the new positions. While this worked well for the movement weapon bob, I felt that it didn't look right for the breathing as it moved too predictably. I wanted the system to move randomly so that the player has to actively adjust to the movement.

Using Sine (exaggerated for demo)  Using Random Numbers (exaggerated for demo)

The method that I decided to go with works by picking a point within a radius specified by the developer. It will them move between the points, it was very important to me that the movement had the illusion of momentum and weight, this means that it will smoothly move between the points it randomly selects, and when it gets to them it doesn't instantly change its movement direction, it will slow down and accelerate in the new direction.

Without momentum or weight (exaggerated for demo) With weight and momentum (exaggerated for demo)

While the examples above do not have the values you might expect to have in an actual game, it does well do demonstrate the movement with momentum, the developer using the system will be able to change the max speed, acceleration and sway amount. These values allow the user to customise the system to be as fast or slow as they would like while also having the ability to add momentum which will greatly improve the user experience.


For the rest of this week and next week, I will be working on the bullet spread system that will be used mainly for hip fire, but will also be available while aimed if the developer would want to enable that.

You can find the project here: https://github.com/ElliotChester/Modular-Weapon-System-Final-Project

Comments

  1. How to Play Casino: Easy Guide to playing slots on
    Casino games are played by 4 players, the average time they take turns herzamanindir.com/ is https://septcasino.com/review/merit-casino/ around 14:20. The house is gri-go.com divided into 토토 three distinct categories: the house

    ReplyDelete

Post a Comment