Week 5 Development (Devlog)

Task Undertaken:

- The primary tasks for the week was to branch out of the standardized Weapon prefabs wit the creation of Splash Damage/impact force and constant movement of a projectile to simulate rocket movement, restructuring of the Ammunition handling code for all weapons derivative of the WeaponBase script, alongside integration of a weapon switching script for the Player. 

- The RocketLauncherBase functioned identically to most other WeaponBase derivative scripts focusing more on the altered functionality of the projectiles so they do not lose velocity over distance travelled. This was achieved through the deactivation of Gravity On within the RigidBody component parameters alongside slowed movement. This allowed the projectile to still function with the WeaponBase script with spreadAngle and shotRate variables whilst simulating a constant moving Rocket based on the BulletBase script, which allowed for code concision and ideal functionality.

- The WeaponSwitching script was achieved through having two GameObjects (Both assigned Weapons) being input alongside their transform locations being constantly read and saved into primaryWeaponLocation and secondaryWeaponLocation variables. By constantly checking the position of each weapon within the update function, the weapons could easily switch locations at anytime during gameplay, irrespective of the players forward facing direction. This format requires the programmer to select two weapons from the beginning and position them in apt locations for switching and firing, however is expected to be expanded upon when weapon drops are integrated into the game so that the Gameobject will read the information automatically. A boolean was also created as a means of checking which weapon was currently out and cover all possible states for equipped weapons due to some initial testing conflicts.

- The Ammunition method (AddAmmo) was repaired due to some flawed functionality in which the MaxAmmo would remain the same whilst adding that value into the currentAmmo. To remedy this , 2 new variables were created: capacityDiff & ammoCapacity which defined and checked the Weapon's difference between it's maxAmmo and currentAmmo  and the maximum ammo in a clip of a weapon. This was placed directly within the reload script for temporary testing and will be changed to a method later for tidy code conventions. This process now correctly checks if the currentAmmo is lower then the ammoCapacity, saves the value as the capacityDiff (Capacity Difference) and adds the difference to the currentAmmo whilst subtracting it from the maxAmmo.

Obstacles:

- One minor complication throughout this process was the discovery that using any weapon and firing it whilst Switching simultaneously cause it to no longer fire when receiving input. This is currently a bug, that will be remedied and checked to see if it's a boolean problem with the initial WeaponBase script with the canFire.

Solution Reasoning:

- The process of creating a derivative script from the BulletBase and restructuring it to function for the Rockets was a simplistic process and was in the interest of keeping code concise for both the RocketLauncherBase alongside the RocketProjectile. This was achieved by having the RocketLauncherBase a inheriting child of the WeaponBase script like all other weapon types however slightly altering the projectile scripts AddForce code so it was constantly moving forward, lowering the mass of the prefab and deactivating the gravity for the RigidBody component of the prefab so that there would be no drop off. This allowed the movement and functionality to align closely with that of a real rocket. The prefabs variables where kept the same as all other WeaponBase inheritance scripts allowing for randomized and unique weapon integration at a later stage if the team decides to integrate it (For example a multi-projectile rocket launcher). Discussing is still going to be had with the team as to whether a homing projectile will be integrated for the RocketLauncherBase at a later stage.

- The WeaponSwitching process was a surprisingly straightforward and rapid process involving 5 variables, two of which were for the currently equipped weapons of the player, two utilised for acquiring and updating the weapon's locations constantly as the player was moving around the scene, and a singular boolean to check which weapon is currently held. The use of 2 separate variables that checked the locations of the primary weapon and the secondary weapon respectively allowed for tidier code rather than typing the primaryWeaponRef.transform.position repetitively which was tested and also works exactly the same. The use of Gameobject variables was beneficial for assigning two objects that were made children of the PlayerController and functions well irrespective of the Weapons assigned to the player after having been positioned correctly. This allows any prefabs that are made later on to utilise the same script simply by the WeaponSwitch script reading the Players currently held weapons which will be read by a possible WeaponPickup script at a later stage.

- The repair of the ammunition script to function properly allowed for all weapons to maintain their independent munition pools whilst ensuring proper functionality with the Reload function defined within the WeaponBase script. This was achieved through integration of new variables being capacityDiff and ammoCapacity which allow for more readable and understandable code alongside more concise scripting. This script was iterative  over numerous development stages and has finally reached a fully functional point that allows each weapon to have it's own ammo pool that is saved to the prefab itself when switching weapons. After reviewing the previous code used for munitions it was clear that the difference was never being read properly and instead was feeding the maxAmmo into the currentAmmo  directly without having an intermediary that checks the amount requireed for a magazine of the weapon.