What is Project Ascension?
Project Ascension is a online multiplayer FPS game made in Unreal Engine 5, which was heavily inspired by Halo Reach, and strives to be both fast paced and competitive. A lobby can hold up to eight unique players, who will fight each other to reach the top of the scoreboard. One round will last between three and five minutes to maintain a fast paced experience for the players. A variety of different guns can be found around the map for each player to pickup. Each weapon has unique statistics such as damage, fire rate, and magazine size. We wanted to create an experience that allowed players to find their playstyle within the game and use that to their advantage. Project Ascension is playable across both LAN and WAN networks, using Steam integration to connect players together. While the game is not currently available on Steam, more development of the game is scheduled to take place in the near future.
The game was created during a collaborative games module that was apart of the Master's Degree syllabus. The module aimed to simulate an active games company that were producing several different games. This strived to give the cohort an opportunity to explore and push their communication skills and gain experience working in a group. The lecturers acted as our line-managers, and each group had a project lead who had pitched a game idea. Our group consisted of six to seven people across a few different disciplines.
My Role in Ascension
This project marks my fourth group project that I've partaken in over the course of my university life. As such, I was one of the most experienced people in the group and took on the role of Development Lead. Each year I've partaken in a group project, I've pushed myself further and further to climb up the ladder of responsibility, so naturally, uptaking the development lead position was my next port of call. As the project progressed, I was later made the Co-Project Lead as well. This came about by the Project Lead needing some assistance in creating our Jira Sprints, as they often had multiple Project Lead tasks to carry out on the same day that our sprints started. I also took over as Project Lead one week when the Project Lead was ill, leading the standup meeting in front of the class, attending the project leads meeting, and setting up the Jira sprint by myself. As the Development Lead and Co-Project Lead, these were some of my responsibilities :
- Frequent communication with the Project Lead on the direction of the project
- Managing the GitHub as a trusted Code Owner
- Approving and rejecting pull requests as necessary, in a timely manner
- Communicating with team members when pull request changes were required
- Giving both positive and constructive feedback to team members and encouraging an efficient but healthy work ethic
- Taking lead of the project when the Project Lead was not available
- Working as a member of the development team, developing multiple core systems across the game
As mentioned at the end of the list, I put a lot of work into not just managing the team and the GitHub, but also being a core member of the development team. I was responsible for multiple core systems, mechanics and features throughout the game.
My Work in Ascension
Weapon System
The biggest task that I worked on was creating the entirety of the weapon system. I initially started on the weapon system by researching the best way to manage the data of each weapon and eventually decided on using a Data Table. This allowed me to keep all the data in one place, where it could be edited for use across the project. It also ensured that the data was easily reachable regardless to which blueprint was trying to access the data. The data table ended up being incredibly future-proofed and extremely successful towards the end of the project when a lot of weapon specific data was required.
The weapons were made pickup-able by using a linetrace to tell when the weapon was being looked it. The weapon would then correctly inform the player via UI which key to press to pick up the weapon and which weapon it
was. The player would then be able to press the button to pick the weapon up, and the weapon the player is holding would visually change from the old one to the new. The old weapon would be dropped on the floor and
available for any player to come and pick it up. I used an Interface to manage the weapon UI and pickup logic as it allowed me to assign the interface to each weapon blueprint and run the event from the player blueprint
without multiple checks for each type of weapon.
The weapon inventory was created using an array and the data table in tandem. While its not the most efficient way to do things, it was certainly effective and functional. The player is only able to hold two weapons
at once, so I used a simple array with two elements to hold the name of the weapons the player were holding. I then used the data table to take the data of each weapon when it was active and change the mesh and the statistics
as necessary. I did a similar thing for the ammo count of each weapon, using an array of two elements to hold an integer of how much ammo each weapon had. This allowed for the ammo used to be consistent when switching
between weapons, meaning if weapon 1 had 25/30 ammo, when switched to weapon 2 and back, weapon 1 would still have 25/30 ammo.
Replication
I worked extremly closely with the Project Lead to ensure that the entire project was replicated where needed. Replication is vital in a multiplayer game as without it, no one would be able to see or interact with each other. A lot of the work that the team made was not replicated, so we spent a lot of time testing the project and going through other peoples work to ensure that everything that needed to be replicated was. This included the player movement, the weapon system, the character meshes, the scoreboard, the kill feed, the match timer, plus much more.
More Work with Project Lead
Towards the end of the project, we got into a good rhythm of working together on tasks, primarily bug fixing and polish. We would screenshare on Discord so that we could both look at the others work in real time. This was especially effective with bug fixes as it allowed for us to bounce ideas off of each other a lot and resulted in a lot of issues being fixed quicker than we thought due to one of us being able to spot the issue that the other couldn't. For example, the damage system stopped working at one point, and the Project Lead spent 2+ hours attempting to fix it. I loaded the project up the next day to have a look and solved the issue in two minutes as the only issue was that the damage causer pin had been disconnected by accident.
I also worked closely with the Project Lead on the damage system, the death system, the execution system, and the animation montages, along with a lot of QA and bug fixes as previously mentioned.
Server Browser
While not overly advance, this is the first time that I've used the Steam Integration plugin in UE5. The server browser was intended to allow the player control over which lobby they were joining, along with providing a place
for them to create their own lobby which can be found by other players. A list of lobbies will be shown on opening the browser and each time the 'Refresh' button is pressed, the player will be able to scroll through all of
the active lobbies and choose which one they would like to join, or make their own lobby!
Match Start Functionality
There was initially an issue with the start of the match, where each player would be able to start playing as soon as they loaded in. This led to an unfair advantage for the host and the match timers would become out of sync with each other. I fixed this by making implementing some logic which would check if each player had loaded in, and once every player was loaded, the pre-match timer would then begin, staying in sync across all players. This ended up being rather simple to implement. I added a boolean check to the end of the BeginPlay logic of each player, and checked if all players had hit this ready boolean or not in the GameMode. The GameMode would keep checking every five seconds if every player was ready, and once everyone was, the game starts.
Other Bits and Bobs
Along with all the features and mechanics previously mentioned, I also spent a lot of time QA-ing peoples work and approving/requesting changes where necessary, I did a lot of general GitHub management, I did a lot of bug fixes throughout the entirety of the project, I made a functioning pause menu that prevented the player from moving while it was open, I created a class choosing mechanic to incorporate the classes that another team member made, I assigned animation montages for the weapon system, and I added controller functionality into the game.