Summary

• Contributed my game development experience to build up an infrastrucutre base to make a new game IP
• Participated in team decision making about designing our best practices and how to help developers stick to them
  • Asset checking tool to enforce naming conventions and performance-sensitive metrics
  • Perforce branching strategy
  • Unreal Engine version upgrades
  • Build machine specs

Personal Highlights

• First professional experience with Unreal Engine 5
• Led the setup of a good CI/CD system integrated with source control to empower the development team based on my previous experiences
• Built a build system using Unreal Engine’s BuildGraph tools despite them being sparsely documented at the time

Video

Due to NDAs, there is no publicly available footage of the project.

Project Description

Stellar Entertainment Software hired me due to my experience and expertise regarding general games programming. It’s a very young company, with several co-development and remaster projects under its belt, but it had struggled in the past to get attempts at getting an internally produced game and IP up and running. The technical director at the time, Andreas Neukoetter, had been positively impressed by how well I did on their programming test, and I was working alongside him to direct the project’s technical decisions in the right direction. I wanted to get a fast and reliable CI/CD system with automated testing up and running, as well as get the team used to good practices for version control and asset labeling. I proposed for the team to make a tool for artists and designers to determine naming conventions in the Unreal editor, and for it to block Perforce submit if it was meant as a production-ready asset but didn’t meet the naming convention rules. I learned about Unreal’s BuildGraph, which was mostly undocumented at that point, and set up our build system to use it with the intent of eventually also using it to run automated test sessions. We discussed ways to prevent pitfalls I had experienced previously from slowing the team down, such as hard code review vote requirements, assigned people to be on dedicated code support roles to avoid support requests going unanswered or falling on the same people all the time, discussed Perforce branching strategies, started to automate parts of merging in the latest versions of the Unreal Engine source code from Epic Games, and many other things that we wanted to have figured out before the project fully started.

Unfortunately, my concerns about us not having basic infrastructure figured out started to encounter a lot of friction with where the project was at that point; there was a push for us to have content to show almost constantly, which made it very hard for us to reach a point of stability with the content and less time was being spent on actually having things like crash/bug reporting figured out, or a larger amount of fast build machines to be able to churn out builds quickly but not slopily. I firmly believe that it’s important to quickly iterate on what you are working on, and to make changes easy to do, but you have to have ways of having confidence as a team that the changes won’t introduce unforseen problems. Game teams often have trouble iterating on ideas because builds take a very long time to get made. The assets we work with and the nature of the problems we solve makes it difficult to keep iteration times low. In addition to that, games have been slow to adopt automated testing, in part because unit testing is time consuming and can be difficult to get right in a language like C++ that doesn’t have proper native testing support like other more modern languages, and in part because more sophisticated integration testing needs to figure out problems like faking player input (either through replays or some other means) which is another time sink, along with learning curves for both. That said, these aren’t unresolved problems. I’ve taken great inspiration from the work Rare did on Sea of Thieves to get their team to be more proactive in guaranteeing stability and predictability in game projects. Cutting down on unecessary things, like code and data branches in a heavy centralized version control system like Perforce, and replacing them with less heavy alternatives, like feature flags, empowers teams. Investing in those things early on sets the project on the path to success, as it allows the team to pivot and reconsider choices mid-production. Errors and performance concerns get caught earlier, preventing broken code from blocking the team and making it easier to meet more ambitious performance goals.

At that time, I was frustrated with feeling like I wasn’t being listened to and my expertise wasn’t really valued. Once Andreas left the team, I felt like I had lost what I felt was my main advocate on the technical side for early investment in things that would save the team a lot of grief and extra work in the future. I decided it would be better for me to leave and find a different opportunity. Looking back, I would handle things differently, and I would have advocated to find a way to keep demo development separate from full production development. This would allow the team to be as messy as it needs to be for the sake of demo development, and only move things across when the team had resources to clean up or improve or properly implement what is being brought across. Recognizing and learning from the mistakes I have made during my career has been as much a part of it as celebrating my successes, and I think my most recent work shows that.