HoverDrive is a networked multiplayer 3rd person vehicle shooter, where players race around the map to defeat other players and AI drones to collect powerups and get the most kills before time expires.
About This Project...
This game was created for our GAM300/GAM350 class using Unreal Engine 4 for 7 months from September 2019 to April 2020.
This project was made with 17 people, the team breakdown being:
4 Designers (BAGD)
2 Designers/Programmers (BSGD)
2 Programmers (RTIS/BSCS)
8 Artists (BFA)
1 Sound Designer (BAMSD)
Create player characters using weapons + abilities
Implement base weapon logic into the game
Balance weapons over time
Concept AI robots for the player to battle
Design Team Lead
Organize tasks and objectives
Communicate design needs to other team leads
Assist in production tasks (submission, plan team meetings, etc.)
Playtesting + UR
Create materials and testing focuses
Conduct tests using materials
Analyze and report on found information
Analyze UE4 blueprints to understand their function
Edit Blueprints to improve and/or fix bugs
Working on HoverDrive
Getting to work on HoverDrive was one of the more chaotic projects I have worked on. In addition to having to deal with the global Covid-19 pandemic partway through development, I ended up needing to wear a ton of different hats perform a variety of tasks to best benefit the game. One of the biggest advantages of this project was getting to work on a networked game, which are some of the games I am most passionate about and get to start thinking about how work.
Combat Design in HoverDrive
Where my work in Beyond was much more about designing, then passing off my plans to a programmer to actualize the idea, HoverDrive was the first project where I got to both design the weapons and implement them into the game myself. My home in HoverDrive was the 8 different guns used by the players, along with the weapon varieties used by the different AI drones.
Since HoverDrive is character based, it was critical to make weapons that not only felt unique to each character's kit, but to also create synergies so characters could have playstyles. For example, this Apophis is a spikey haired character that wants to get close and find from a short distance. I decided to give him a shotgun for CQC and mine launcher to allow him to limit other player's escape routes when used together. Combine that with the ability to make small jumps, and you have a fast bike that is good at controlling space, a well-defined playstyle.
A way I approach thinking about weapons like this is to consider one weapon a primary and the other a secondary. Normally shooters that give you a secondary intend for it to be a backup in case you are in a pinch. For me though, I want to think about ways I can get the player to choose the secondary, even when the primary is a viable option. Focus this thinking to a playstyle and then start building dependencies with the weapons, such as the mines only being good if you are chasing a player into them with a shotgun. Or distance being hard to close without the ability to zone with a mine.
Design Lead on HoverDrive
While working on HoverDrive, I was also in charge of all the designers that were on our team. Most of the active responsibilities I had on this project was directing designers in what to focus on for each milestone, along with conveying wants/blocks to the other leads on the team. My approach to production was a little pulled back, where I wanted to give my peers the ability to work how they wanted and just try to facilitate their work where possible. Production for me is currently not one of my career pursuits, but I still feel listing the capacity to take on the responsibility and having experience with production is worth noting.
Playtesting & User Research for HoverDrive
One of the other tasks I mostly took the reins of was creating playtests and running those playtests with players. Since we had no dedicated person to run all our tests, these duties mostly fell onto me conduct and carry out. Most of my tests that I conducted went through a format of 1) finding the focus of the test 2) determine how to best conduct said test 3) create post survey to give after the test 4) conduct the test and give posttest 5) analyze results and write a short report on findings.
Most of my testing focused on general gameplay to ensure the game was fun and balanced, but also had me sometimes taking art pieces or audio samples and testing their popularity and cohesion from a player standpoint. Sometimes I would combine these elements in the effort to save time as well. Most of my tests were done as playtests, but some early tests were simply done with paper copies of art. Giving the test is mostly about watching the player and noting down key moments that can be referenced later. A lot of the knowledge I got out of testing came from posttest surveys, so I would typically have them take from 2-5 min to complete with time after to give any additional feedback and add them to my notes I had taken. After all the tests were done, I would take all my data and look through it see where the most notable improvements can be made. Then it just comes down to writing a report to tell the story of the data collected and suggest what and where improvements can be made, highlighting bits that I felt were the most significant. If you do not make it brief, no one will read it!
Blueprint Debugging for HoverDrive
While a smaller role in the work I have done on this project, Blueprint Debugging was probably where I ended up spending most of my time. With most of the team (as well as myself) using Unreal 4 for the first time, combined with the challenge of working on a networked multiplayer game, our blueprints were always a mess and had to constantly be combed over. The networking was mostly the cause of the problems we had; making sure events fired in the right place, on the right object, and in the right mode was a constant worry. So, I would dig through the charts, commenting and cleaning up when possible and getting everything up and running.