Weapons and Combat
One of my other significant contributions to the project was designing and developing grenades, as well as refining the wand system. In earlier projects, I worked on systems like weapon mechanics, so I felt confident approaching these tasks. However, both grenades and wands presented their own unique challenges during development.
Grenades required precise timing and physics to ensure they behaved realistically, while also being engaging for players to use. On the other hand, the wand system needed to balance intuitive controls with satisfying functionality, making it feel magical yet grounded in the game's mechanics. Both systems required iteration and testing to get right, but tackling these challenges was a rewarding experience that pushed my problem-solving and development skills to the next level.
Grenades were the first problem I talked about after sorting the player movement and when I got started, I was not feeling particularly inspired or full of purpose so getting started I fell back to my earlier implantation of spells in another project. This involved using inherited classes and virtual voids to build a base class. Each grenade then is a child of this class and has its own unique logic for exploding, breaking and spawning effects. This system isn't by any means ground breaking but lets the grenades be very simple to understand and use.
The more interesting problems and design choices came when working on the unique effects of the grenades. Early on, we decided to include a black hole grenade and a Molotov grenade, which became the first two grenades I developed. The system was simple. When a grenade activated its shared method, it would either spawn a new ground effect or create a projectile on the floor. This zone would have a defined lifetime and execute its own unique effect during that time.
To streamline the process, I created an added element called the Ground Damage Effect, which served as the backbone for these systems. It featured a few key methods
Setting Active Time: Decided how long the effect would last on the ground.
Trigger Animation Event: Controlled the growth and shrinkage of zones, depending on the effect.
Execute Tick: Managed ongoing actions within the zone, such as damage over time.
Although conceptually simple, implementing these ground effects proved challenging. One major hurdle was ensuring the zones had the correct visual behavior. All zones started with no visible effect, so the animation needed to make the zone appear as if it was growing. This was heavily reliant on animations, which made it easy to accidentally scale incorrect values, changing the animated model and making the zones difficult to position accurately. This made changes to get the balance right much harder. Each edit required double checks and assistance from developers for the designers and artists.
These systems provided a solid foundation to explore various effects, and thanks to earlier planning, we were able to create my personal favorite grenade: the Glue Grenade. Upon activation, the glue would spray out, and if a player walked over it, their MovementType would change, limiting their speed and preventing jumping. This functionality piggybacked the Ground Damage Zone system, showing the versatility of the groundwork, I had laid. While the system itself didn’t need significant changes, I want to look into more user-friendly interfaces in the future. With improved tools, it would be easier to manage and refine these effects, particularly for collaborative workflows with artists and designers.
Wands
The original shooting system was designed by our talented Programmer Tomos J. He had made a solid start to the design but had ran into some difficulties moving it forward so I used the previously added grenade system to inform the new wand system. I use the same structure of having a base class with virtual methods that are shared across all wands. The wands then had their own logic again inspired by past projects. The player’s interaction with wands was managed through a PlayerWand class, which held the current wand and dynamically called its methods. This added layer of abstraction allows us to add extra logic like swapping to the standard wand when the player runs out of shots, Dynamically move between wands and have a scalable system that's easy to add to. This system should also support wand snapping when we look at implementation for that mechanic.
Although it is our cleanest-designed system, the main focus of the weapons was on weapon balance and design. I wanted to ensure we had a streamlined and effective way to organize and balance the various weapons.
When developing the weapons, my first step was to outline the Time To Kill (TTK) for the game. TTK represents the ideal time it takes for each weapon to eliminate another player. For this project, we decided on a slightly longer TTK to align with the game’s more arcade-like style. This decision was intentional, as it gives players more opportunities to react to their environment and make faster strategic decisions.
One of my favourite examples of great weapon balance is Apex Legends, which has an excellent approach to TTK. I used their average TTK as a baseline to guide our starting point. After testing, we found that players enjoyed the pacing and feel of the weapons, so we decided to stick with this approach. It struck a satisfying balance that matched the overall vision of the game.
We, unlike a competitive game, want to let the weapons become more overpowered to play with natural balance of the game. Arch (2023) does a fantastic video collection on the balancing of weapons and a look into a few games. this has been a key reference point for us to develop our arsenal
So, what do we have and what are they in the context of a normal shooter
Flamethrower – SMG
Shotgun Wand – Shotgun
Standard wand – Rifle
Burst wand – Rifle / DMR
We use a spreadsheet to Manage the weapons and keep them all with a certain range of each other to stop weapons creeping too far from each other. The color section of thew table Allows us to see the primary features of the weapons like TTK (Time to Kill), DPS and total damage output.
Certain weapons require some more planning than just editing them with the spreadsheet as there are some weapon stats that have an equivalent effect on the quality of the weapon that are not covered by the spreadsheet. These are things like projectile speed and Range. Throughout testing, the Shotgun and flamethrower have gone through many iterations together due to these stats. The Shotgun despite its power is limited by its range and speed making chasing down other players far harder than other weapons like the standard wand as you can get good space between you and the shotgun projectiles as they are just over the player speed. And the same was true with the flamethrower.
I’ve had a lot of fun designing the combat systems. It’s always incredibly rewarding to work on such critical aspects of the game and have the chance to fine-tune unique interactions and gameplay mechanics. The positive reactions we’ve received during testing sessions have had a profound impact on me. Seeing players enjoy and engage with the systems we’ve built has been both motivating and inspiring.
Taking a more deliberate approach, especially with the wand system, has truly paid off. This success can be attributed to better time management compared to previous projects, as well as improved planning and knowledge. These factors played a significant role in making the system feel polished and enjoyable.
However, there were some hiccups with the grenade system. I hesitated to dive back into the Unity editor tool to refine certain aspects, and in hindsight, committing the energy to design a robust tool would have been worth the time saved. It’s a valuable lesson for future projects
Arch (2023). [Online Video]. Available at: https://youtu.be/gJ5xDfIjjKQ?feature=shared [Accessed 6 December 2024].