Game - Elementalis Infectio

Elementalis Infectio is a First-Person Shooter (FPS) game about eliminating viruses inside a living body. It was created by a team of 3 developers where I was Project Manager, Programmer, and QA Lead. I also created the 2D icons for the user-interface (UI) and power-ups. The audio, 3D art, narrative/story, and level-design were done by my team members. My teammates used programs such as Substance Designer/Painter, 3DS Max, and Cubase for materials, models, and audio while I used systems within Unreal Engine 4 and Visual Studio to complete my programming work (as well as Photoshop/Illustrator for the 2D icons used on power-ups and the UI).

The player is tasked with eliminating elemental viruses that deal damage based on their type. For example, earth viruses deal earth damage, while fire viruses deal fire damage. There are 5 different types of viruses; regular (no element), fire, water, air, and earth. Along the way the player receives bonuses such as increased ammo for killing viruses and there are temporary and permanent power-ups that increases specific elemental resistances (resulting in the player taking reduced damage of that type). The final challenge is the boss virus that periodically switches between each virus type (while updating its color and damage type to match).

Interdisciplinary Collaboration and Teamwork, Unreal Engine 4 Mastery, Gameplay Programming, Artificial Intelligence decision-trees and path-finding

This document is a detailed reflection of the development process that outlines what went right, what went wrong, and plans for the future

Working on this project was my first experience developing a game with team members. Our team consisted of three members; a 3D artist, an audio tech, and myself (programmer). Along with programming, I was also chosen by my team to lead the team/project as project manager. As project manager, I created a development schedule for the game as a whole in addition to individual team members’ tasks, I organized formal and informal team meetings in our agreed upon communication program (Discord) where we would share what we did the previous week and plan the following week(s), I created files and documents to support the development of the game such as spreadsheets for quality assurance testing, and I ensured that development didn’t stray too far from the plan/schedule by periodically checking in and keeping team members (including myself) on task. As the only programmer, I did all of the coding of the framework and mechanics of the game (C++ and UE4’s Blueprint), I kept up the project’s online repository and ensured that my team members understood and knew how to work with Git for source control (using Sourcetree), and I integrated some of the assets (created by other team members) into the game.

During the development of this project, I learned how to design and develop a video game with a cross-discipline team. As the team leader, I also learned techniques and methods for leading a team of game developers to the completion of a project. I made sure that every member of the team knew that their input was valued. To promote ownership of each team members’ tasks, I allowed the team to decide which tasks they would like to tackle, then I logically organized the selected tasks to ensure the project was completed on time. I learned to manage software development through an agile framework called Scrum. My team and I worked in iterations or sprints that lasted one week each. Before each sprint, we first reflected on the success of the previous sprint, then updated the list of tasks we were to complete during the following sprint. In addition to scheduling and project-management techniques, I also learned quite a bit about source control and Git. Specifically, I learned to manage a repository using GitFlow methodology. With the GitFlow source control method, our repository consisted of multiple branches (Master, Development, Features, and Hotfixes). The master branch served as the release branch that included our most up-to-date stable build of the game, while the development branch included what we were currently working on. When the development branch was made stable with recent updates, it was merged into the master branch to be released. As we added new features or fixed minor bugs, feature and hotfix branches were utilized. As the team’s programmer, I learned how to code in such a way that made it easy for the game designer to use the systems I create. This meant organizing my functions and variables into categories and adding comments that show in the Unreal Engine 4 editor as tooltips when the designer hovers over them (tooltips in the Details panel in UE4 and on Blueprint nodes/pins).

Some of the challenges I faced during the development of this project were communication among team members, keeping team morale up, and organizing work across varying team members’ schedules. Everybody has their own way of thinking and doing things, so communication is important for any team project. My team members and I were of different disciplines (programming, audio, art, etc.), so communicating cross-discipline was a challenge we had to overcome. In addition to communicating effectively, we also had to overcome the challenge of working with everyone’s schedule. We all worked on the project at different times of the day/week, so we had to leave notes/messages to each other regarding what was worked on and what still needed to be done. This also made daily communication that much more important.

The best feedback that I received during the development of this project was simply watching somebody play the game without any help from me. This enabled me to recognize when they were confused about something or didn’t know where to go or what to do to continue progressing through the game. As a game developer, this information tells me that the game can be improved to make such situations more intuitive. For example, when the player didn’t know they should be moving forward down a hallway, a visible power-up was added to incentivize continuing down the hall.

Upon revisiting this project to continue improving it, I noticed that the death of viruses was a bit dull. As it was, when a virus died, then would become a ragdoll and fall to the ground. I made killing viruses more appealing and fun for the player by adding an extra impulse to the final hit. This way, when the player kills a virus, it’s blasted backwards before becoming a ragdoll. To accomplish this, I opened the projectile class and navigated to the function that is called when the projectile hits something. After verifying that it was a virus that the projectile hit and after dealing damage, I added additional nodes that check if the virus is still alive. If the virus is not alive after the projectile deals damage to it, the projectile adds an extra impulse to the virus at the location of impact. A final run-through of the game led me to find that this impulse does not get added when the killed virus was too close because the player deals damage directly to viruses instead of firing a projectile when the virus is close when the player fires their weapon. To fix this, I added to the function that is called for the player to deal direct damage to a virus so that the virus is blasted backwards when killed this way (seen in the image below).