Successfully executing a multiplatform launch can be challenging, and production inefficiency is a common bottleneck. We sat down with Cygnus Entertainment’s lead artist Amber Johnson and lead engineer Jon West, as well as Unity’s technical product management lead Marie-Christine Babin and Marc Nelson, manager of technical product management. These experts discussed common obstacles that could affect your multiplatform launch, and gave tips on DevOps best practices to ship successfully.
Let’s start with the basics. Does a user need to know general DevOps or CI/CD practices to use Unity DevOps?
Jon West: One of the reasons we chose DevOps with Unity, including Unity Version Control, was because we had a rapidly growing team that expanded to roughly 30 people. We needed a solution that was fast and easy to onboard developers, while being stable enough to scale. It helps to be familiar with general concepts of version control and DevOps, but it is not unapproachable by any means. At one point, even our QA department had branches of their own.
Amber Johnson: From an artist perspective, it can be a lot more intuitive to work with than other version control tools. You can easily visualize the “flow” of your changes and see what other people are working on. Most of our art team had no experience working with it beforehand and little to no experience with other systems, and I was able to get them up and running after a few demos.
Marie-Christine Babin: We also offer Unity Learn tutorials that can help you get started with Unity DevOps without prior experience.
How does Unity Version Control compare to other DevOps tools?
Jon: It’s quite a bit simpler in that you won’t be fighting LFS (Large File Size) or wrangling the bash terminal. It will also scale with your project size, and it integrates directly into Unity, allowing you to lock files in-Editor to prevent merge conflicts.
Amber: I’ve found it easier to fix issues if we lose files due to bad merges. It’s easy to jump back to a previous version of the project, create a Unity package of the files you need, and jump to the latest version. Being able to work in different branches for experiments or to do “messy” things like import in asset packs is helpful as well. I can abandon the branch if things don’t go well.
I’m also a professor and have taught artists how to code in Unity. This was easy for our artists to learn. One of the things we utilized were internal wiki pages with important information they could refer to.
How can a small team manage a project to create games faster?
Marc Nelson: Making games faster comes in many shapes and sizes. My recommendation is to start by leveraging our cloud transformation service, Unity Build Automation, to expedite builds to test and ship your finished product to users everywhere, quickly.
Marie-Christine: Even when working on a solo project, implementing best practices related to version control will help you get organized and save time. One of our GDC talks this year was focused on project organization and version control, and introduces some of the best practices you can put in place in your projects to be more efficient. We also have an e-book available that goes into more detail on the topic.
What was the most difficult part of implementing the processes that you are using today?
Jon: It all happened very naturally. The issues we had to address were, for the most part, obvious from an early point in the project. Standard practices in version control still apply. We established a chain of command for art, main dev, and every major platform branch. Only those with authority could push to them. This kept our version control clean while we adopted particular methods of preventing developers in the project from stepping over each other.
For instance, having the art in a separate scene loaded asynchronously while the programmers operated in the base scene. Utilizing Prefabs instead of directly editing the scene also went a long way to prevent difficult-to-deal-with merge conflicts. Everyone was quick to adapt and pivot when we discovered new roadblocks. Perhaps it was a bit of luck that Unity DevOps matured when it did, as we were equipped with all the tools we needed to avoid major headaches.
Amber: The chain of command was critical for us. Once we had that sorted out, it solved almost all of our issues with handling files. It was a slight bottleneck with the process, but it was only a problem at the end when we were trying to build constantly.
When onboarding new members, what were some of the common hang-ups for someone getting used to working with DevOps?
Jon: Our structure and chain of command for who pushes when prevented any hang-ups that this could have incurred. Unity Version Control offers two ways to access the repository: a local version where you push and pull from the online repository, and a cloud version, where every time you check in, it goes directly to the online repository. This simply removed an extra layer of complexity when having to manage a local version of the repository that might not be in sync at any given time.
Did you have automated tests setup? Or was your testing largely manual?
Jon: We had a QA department internally and made builds regularly for them to test. We had a small amount of external tests done, but mostly it was done manually in-house.
How do you recommend approaching structuring UI Prefabs and components that differ greatly across different platforms?
Jon: At the Prefab level, we would typically have one Prefab per major element, and would have each platform as a child, all disabled by default. Then at the script level, we would use preprocessor directives, custom ones included, to enable or disable the child objects (#if UNITY_ANDROID, #if UNITY_PS5 for instance). Most UI elements were shared across all platforms.
Please explain the “Shift left to reduce failure” concept in DevOps?
Jon: Finding out as many unknowns as possible is crucial to successfully shipping a game. DevOps allows us to rapidly prototype and parallelize builds for multiple platforms so we can get it into players hands quickly, and validate our assumptions. Being able to step through each part of the process, both on the production side and in-game, prevents us from getting blindsided by potentially large complications in the future.
Amber: This is an interesting idea from an art side perspective, because the spirit of it has been in the art pipeline for a while. We block out our levels and test them. We put rudimentary art and test it. We put basic lighting in and test it. We get characters in and test, etc. I couldn’t imagine trying to put everything art-related into a project before testing how the process goes. You block in your sketches first, fix your issues, and then refine.
Marc: Shifting left is a practice aimed at shortening the time it takes to identify and remediate issues. In our world, it means bringing testing, quality control, and performance evaluation tasks together earlier in the development lifecycle.
Any advice for this type of the “stop to do it right” DevOps scenario?
Jon: Being able to pivot with your process is so incredibly important. If you’re unable to fundamentally change foundational processes in your workflow, you may be able to integrate some aspects of DevOps to combat entropy and technical debt. For instance, cloud builds could free up machines and dev time. And if you’re able to personally adopt good practices in your own area, it can still go a long way to add stability to a project and decrease friction as you scale and work with others. Some form of version control is a must, and the way you operate in relation to it and the engine can always be optimized, even if it’s only you making changes.
Whether you’re new to DevOps or a seasoned professional, the key to being successful is to tailor your practices and tool selection to your needs. DevOps is ever-evolving, and it’s important to be open to change, new processes and tools to optimize your game development process.