The Build Engineer

Also known as the Platform Engineer / Automation Engineer / DevOps Engineer

The following is insight into these roles from Tom O’Neill, former Build Engineer at Romero Games, and currently Senior Automation & Tools Engineer at HundredStar Games.

General Sentiment/Overview

#

These roles would be considered the most adaptable and transferrable skill-sets to have when it comes to software development in general, and is the backbone of the games development process.

These roles are critical in managing the lifecycle of game projects, all the way from prototyping, shipping, and ongoing maintenance of a game.

The significant difference when it comes to games is the scale of the software stack you are supporting. This all surrounds a game engine, which is in most cases, at its core, is a monolithic multithreaded C++ application supported by a bespoke set of tools for turning people’s Art and Code into a game you can distribute, test, and play.

With this, the most important high level areas to consider are:

• Source Control Management
• Continuous Development / Continuous Delivery
• Release Management
• Infrastructure Management
• And of course, Programming.

Day to Day Responsibilities

#

Source Control Management

#

This is the job of being the central gatekeeper of all code and assets that make up the game. While hundreds of people are contributing to a single code base every day, they use SCM tools to allow them to contribute incrementally, ensure their work is safe, and that they are not impacting the work of others.

This involves creating and co-ordinating branches for releases, merging work between development branches, and supporting the team with technical issues and queries.

This is the backbone and the single-source-of-truth for the work performed by the team.

Continuous Development / Continuous Delivery

#

This is the backbone of the Build and Deployment process for the development of the game. As people contribute to the game project, this system continually builds the game to ensure that changes don’t break the existing game, and that builds can be generated for QA validation and automated testing.

This is the process of using tools like GitHub Actions, Jenkins, and TeamCity, to allow for scripts and logic to be run for building and deploying the game to a centralised location.

These are complex systems that will be iteratively improved as requirements grow, but will require frequent maintenance.

Release Management

#

This is the role of ensuring that builds arrive where they are needed most as soon as possible. The CI/CD backbone allows these builds to be created, but they need to be deployed to different platforms for different use cases.

This could be Steam for example, allowing for daily/weekly game updates to hit users for live games. During the development process, this would be for QA, PlayTesters, and the publisher.

Infrastructure Management

#

This is the area of Cloud and On-Prem virtual environment management. Designing and creating VMs, maintaining their environment, disaster recovery, data warehousing.

Environment requirements change, cloud platforms shift significantly In the background as time goes on, and needs to be accounted for.

General Support

#

Having such a broad reach of technical areas, this role is very typically called upon for their domain knowledge to support the team.

Daily requests may be:

• Supporting Artists and non-technical users with tools issues
• Writing tools and automating menial tasks for artists
• Supporting with SCM requests
• Triaging broken builds
• Analysing build and performance data
• Highlighting issues to corresponding teams

Communication and soft-skills are incredibly important in this role, requiring you to work with technical and non-technical people, ensuring all parties are aligned.

Engine Upgrades

#

Engine Upgrades are frequently required and are critical to the ongoing development of a game. It may come as a surprise, but the vast majority of games developed at a AA+ level are developed using a Game Engine and Editor that the devs will build themselves. This means that you have complete access to the source code of the engine and editor, but also the responsibility of maintaining it.

When a company like Epic releases a new version of Unreal Engine, and you are working with the source code of the engine, it is not as simple as downloading a new version through the Epic Game’s Store.

The process for doing so requires every tool and skill in the tool belt of a dev in this domain.

• Every differing line of code needs to be merged, every new asset needs to be replaced. (SCM, Programming)
• The Editor needs to be stable, and every artist/coder plugin needs to be accounted for. (Programming)
• The Game needs to be built and tested for every platform. (CI/CD, Build Automation, Infrastructure Management)
• The game needs to be monitored for significant performance changes as part of the engine upgrade. (Programming, Automated Testing,
• The game needs to be distributed to QA for verification during the upgrade process (Release Management)
• Supporting tools need to be compatible with the upgraded Editor and Game. (Programming, CI/CD).

ALL OF THIS NEEDS TO HAPPEN WHILE PEOPLE ARE ACTIVELY WORKING ON THE ENGINE, EDITOR, AND GAME, WITH MINIMAL DOWNTIME.

Student Projects

#

What kind of student projects would you recommend doing to prepare for this role?

There is no explicit project that one should do, but you should change the behaviour of EVERY project you work on by using the following tools:

1. Start using git for every project you work on.
   • Best place to start is the “No Deep Shit” Git Guide.
   • The more time you spend with the tool, the more use cases you work through, the more you will absorb and understand about meaningful source control management. This will give you a solid foundation for working with other industry standard SCM tools I.e. Perforce.
   • What may initially feel like extra work for the sake of it, will save you hours of rolling back experimental work just to get back to stability. You quick-save all the time while playing a game don’t you? Your projects should be no different.
2. Commit often.
3. Start using GitHub Actions on your GitHub projects.
   • This is the basis of Continuous Delivery and Continuous Integration.
   • GitHub actions is an amazing and importantly FREE tool that offers you access to VMs/Containers to run verification processes on your Projects. With a means of building, testing, and deploying your projects, using this will not only set you up for how software is managed at any company, but will save you time in the long run by offsetting verification to a fresh environment every time.
   • The official GitHub Actions documentation is the best resource, with an infinite amount of YouTube tutorials to peruse.
4. Build Often!
   • While working on your game, use the editor tools to build/package your game often for verification. Working within the Editor is fantastic and convenient, but is never a true reflection of the user experience. Building frequently will get you familiar with the underlying tools and frameworks used for actually turning code and assets into a playable game.
   • If you’re really interested in a challenge, write your own script to use the underling command line tools to build exactly what you need with one command..

Pros

#

Why might a student want to pursue this role?

If you enjoy automating your problems away, if you appreciate thinking on your feet and fast feedback loops in your day-to-day work, and if you like the big-picture scope of building and maintaining large and complex systems, this may be a role for you to consider.

If you like backwards engineering existing systems and pride yourself in how fast you can learn and adapt within unfamiliar codebases, this role is up your alley.

This is an excellent role for firefighters, the scrappy problem solver, and the architecturally minded developer who likes designing technical systems.

Cons

#

Why might a student want to avoid this role?

If you don’t like the idea of being a Firefighter or being under pressure by being the first point of contact when systems fail, this may not be a suitable role!

Resources

#

• AWS/Azure Certification
• GitHub Actions documentation
• “No Deep Shit” Git Guide

Series Conclusion and Final Thoughts

#

We’ve now looked at 9 engineering roles in Games, there are several others including the Engine Programmer, Data Scientist, and Online Services Programmer that I had to cut for time. If you’re a student reading this I hope it has been insightful and has sparked an idea of a path you might want to go down in your game dev career. Do feel free to reach out if there’s any information shared in the series that is unclear.

For my final thoughts on engineering in games as a whole:

1. Learn C++!
   • You may have noticed there’s a lot of talk throughout the series around unreal engine, and that would be one strong case to learn C++. That reason aside, working in games often comes with the kind of runtime optimization that you can only get with languages like C++ that allow you to have the fine-grain control that is obfuscated in other languages. Learning C++ is really an essential skill for any engineer in Game Dev, so start early and get familiar. Effective C++ 3rd Edition are a great resource once you’re past the basics to excel in using the language.
2. Get to know a bit about your associated disciplines.
   • Are you interested in becoming a UI programmer. Learn a bit about UI art and design. Animation Programmer? Get to know the basics of animation. Whatever role you’re in, you’re going to be communicating with others, and if you can identify the ones you’ll be communicating with the most, get to know their role and communication will be much easier.
   • The second advantage to this is it can help unblock you if you’re familiar enough to make your own placeholders instead of relying on artists. But also don’t let it get in the way of your primary focus.
3. For projects, start small. Think of the smallest possible version of the project, and then half the size. It’s always easier to build more on later. If you have cool ideas you don’t want to let go, put them in the stretch goals bucket, but always make sure you have a small MVP and that finishing your project isn’t reliant on all the stretch goals being complete.
4. If not already using it. Start using Version Control (Github, SVN, etc).

And that’s it! I hope you’ve enjoyed the series and best of luck with all your game dev endeavors!