Oh, Bugger!

⚒️Language: C++/Blueprints (Unreal Engine 5) 🗓️Duration: 8 months

👨‍💼Team Size: 23 (8 designers, 11 artists, 4 programmers) 🎮Link to the game

Owlet >

Overview

This year, I worked in a multidisciplinary team to develop the game "Oh, Bugger!", a first-person horde shooter. The project was developed over the course of the entire academic year, which simulated the process of releasing a game in the industry, going through all the different phases of development - concepting, pre-production and production. At the end of the year, during the Industry Day that our university hosts, our project was voted as the best Year 3 project by industry professionals!

Key Responsibilities

Integrating and fine-tuning wall walking plugin
Onboarding designers about how they need to use the plugin
Developing enemy AI behaviors and level ingredients
Worked on CPU and GPU optimizations:
- Applying Lumen and Nanite in the game & diffrent anti-aliasing method
- Separate enemy deaths in multiple frames
Worked with designers, developing the USP of the game and keeping ideas in scope for the project

Challenges & Lessons Learned

Throughout the development of "Oh, Bugger!", I tackled many new challenges which taught me a lot about game development.

The first one was working in a team of 23 people. This is the biggest team I've been part of and it showed me how complex the dependencies become whenever you work in a larger team. We needed to establish and maintain good communication between all departments in order to keep everyone aligned. This would in turn ensure that the project remains coherent and that everyone has a unified vision of what we want to produce in the end.

Following well-defined processes turned out to be something else that is vital for the success of our project. Using version control effectively, and reviewing work properly to have a stable build were vital for a smooth development process . On many occasions, we would have people that do not review their work properly, which would lead to us having a broken build. In those situations, my programming lead and I would step in and identify which submit broke the build, and revert it, as agreed in our team contract. While we were unable to enforce some of our processes, the fact they were clearly defined helped reduce the severity of the issues.

A major technical hurdle I faced was the integration of the wall-walking plugin that we use for the movement of our enemies. I have experience with external libraries, but I had never used plugins in Unreal Engine before. Integrating it and making sure it works with our AI logic was quite difficult. I dove deep into both the codebase and the documentation in order to understand it well enough not just to use it myself, but to also be able to teach our designers how to work with it. After a while, I became the go-to person for anything related to our enemies wall-walking behavior.

In conclusion, this project taught me quite a bit from both a technical and collaborative standpoint. I learned how to work with a large number of people, handle dependencies during development and gained even more experience working closely with designers.

My Contributions

Wall Walking Plugin Integration

A big part of this project was the wall-walking plugin that we used. It is a third-party plugin from the Unreal Marketplace and integrating it into the project was my responsibility. Beforehand, we used another plugin made by one of our classmates, but it was in a very prototype state and did not fit our use. We opted for a third-party plugin since we did not have enough time to develop our own, even if it was something we really wanted to do. We had to choose the option that would save time and allow us to keep polishing our project.

My Contributions:

Integrating wall-walking plugin inside the project
Refactoring AI logic so that it works with the wall-walking
Onboarding our AI designer on how she needs to use the plugin, what components she needs to use, what objects need to be in the level
Fine-tuning wall-walking behavior to achieve better player experience

Enemy Behavior & Level Ingredient Implementation

While working with the design department, I participated in tons of discussions about how the enemeies should behave. We went back and forth both about implementation details and the actual design of the enemies. It was a very productive process which once again showed me why working with designers is so enjoyable and why I find it the most fun part of making a game. In the video on the left, you can see our enemies in action!

I also worked on one of our level ingredients, which are the eggs. They can be found in multiple places in the game and whenever they are destroyed, they spawn more enemies which the player needs to eliminate.

My Contributions:

Implementing core architecture & logic for the enemy AI
Developing separate enemy subtypes (Horde & Explosive Enemy)
Creating an egg level ingredient which spawns enemies

Optimizations

During the last 2 months of this project, I turned my focus towards optimizations. In order to provide an enjoyable player experience, we wanted to have our game run at a stable 60 FPS. In order to do that I performed both CPU and GPU related optimizations that increased the performance.

My Contributions:

Work with VAs and consult when applying GPU optimizations that may affect visual fidelity
Apply Lumen and Nanite to the project and ensure that all assets are unaffected
Experiment with different anti-aliasing methods and compare performance difference
Separate enemy death into multiple frames to increase CPU perfromance

Before Optimization

All enemies would die in the same frame, taking up to ~63ms. This would cause enormous performance issues.

After Optimization

After I applied my optimization, the death of the enemies was split in separate frames, allowing for a maximum of 10 enemies to die at once in a single frame. This way the death would take only up to ~3ms in worst cases.