Embedded Files
The Project
Gunsect is university project made over 6 months by 12 people, it's a top down shooter featuring a gun with swappable parts.
In this project I was the solo programmer.
I designed, programmed and implemented systems that were simple to use for other team members.
Noteable Systems
A complex gun swapping system
A combat system utilising object inheritance.
Highly replayable, randomised gameplay loop
Gun Module Swapping System
This game relies on it's selling point of having a gun that can have its parts swapped out.
Our gun can swap out 3 parts, the "Trigger", "Clip" and "Barrel". These parts which we call "Modules" have variables attached to them and all together make up the way that the gun fires. There are a number of variables that are shown to the player and many more that aren't.
All up there are roughly 40 variables that can impact the bullets and the way the gun is fired. That could have gotten messy quite quickly so I made use of structs and helper functions to ensure that the process of firing a bullet in code was simple.
Our modules were easy for designers to work around with the custom editor script that I wrote to ensure that there was no extra variables on screen that they didn't need to edit.
Combat System
The combat system in Gunsect was a valuable experience in designing systems to assist me with an already large work load while ensuring I didn't compromise the quality of the product or others quality of work.
In Gunsect our combat is based on gunplay. Our "combatants" are our enemies and player, which share a base class, this means that they reuse a lot of the same systems such as: movement, collision, health, elemental effects, animations and material changes.
This made programming a lot easier on my end and meant that I didn't have to handle different cases for custom behaviour and a lot of art implementation was generalised so I didn't need to rewrite any code.
Our enemies and our player both use the same gun module system. Meaning that for designers, creating a weapon for an enemy was a familiar process and not something they had to think about separately to the player, this also allowed us to have a wider range of enemies while having a limited amount of resources allocated to making complex behaviors.
This inheritance structure was something that required heavy communication and coordination with artists and designers alike to ensure that I made systems that accommodated everything they wanted to do in the project; but also making sure that they accommodated for the way that our code worked.
Inside of inspectors you can see that these classes are inherited using the same.
Gameplay Loop
Our gameplay loop required moving between levels randomly, and having multiple doors to the next level with random reward types that dictate the reward in the next level you enter, similar in style to games like Hades.
Because the Unity engine moves through scenes in a build based on their order number or their file name, to automate scene transition in a way that I didn't need to update magic numbers depending on the build order of our scenes as new levels were added, we needed to use a scenes name.
To do this I placed all of our level scenes in a folder hierarchy and read the folder structure to get their file names, from there I wrote a text file recording all levels that would be inside of the build and could then use string manipulation to assign them to lists and load levels based on whether they were in particular folders, this was used to create different difficulty levels inside of our game.
Our reward system works in near exactly the same way but instead of loading levels it spawns our rewards based on files loaded in the unity resources folder.
Overall the system worked better in my favor but we found that it didn't work quite so well at run time in builds due to restrictions with the way the resources folder is compressed in build time. So text documents needed to be saved and then fed into the project before build time.
Google Sites
Report abuse