Hello there and welcome to another Blightmare dev blog! We recently wrote about what tools and services we use to manage code and assets, but that doesn’t tell the whole story.
The editor and the logic for the game itself are developed initially inside the Unity editor, but that is not how we build content or test levels. The game editor is published from Unity and uploaded to Steam for distribution to the rest of the team. This has several benefits:
- Stability – The editor is a release so changing code or other source assets doesn’t have an effect. This allows us to quickly and easily roll back a bad build to unblock content creation.
- Ease of use – Keeping Unity up to date and coordinating on the “right” version can be a major time sink. By taking that out of the equation, the editor stays always up to date just like any other application on Steam.
- Ease of use (pt 2) – By having the editor be a fully built application, startup time is very fast. Changing data does not require any rebuild or import step which allows for quick iterations on content.
- Delivery practice – Blightmare will be shipped on Steam when it is ready, and we can be very confident in that process because we’ve been shipping builds to ourselves for a long time now.
As you may imagine, we made some tradeoffs and had to build several utilities to get into this position. The largest time investment went into building the editor itself which we’ve covered before and I won’t go into here. The largest potential tradeoff is the lack of built-in support. In theory, using an engine like Unity should bring with it many utilities and features that we can reach for to help us make our game. In practice however, we’ve found that many of the features are too rigid to really solve the problem that we’re trying to solve, or that it takes at least as long to understand how to use the pre-built version as it does to just build one ourselves. We find ourselves using less and less of the features of Unity these days as we iterate on our code for correctness and performance.
Creating and distributing builds is the area that I want to focus on for the rest of the post and perhaps next time, I’ll talk about our content services. The problem that we need to solve is how to take a Unity project in git and get it to the whole team. We have people on Windows and Mac, so creating builds for both operating systems is also a requirement – this is another area where it’s also just good practice to do this because we will be shipping on multiple platforms.
The basic pipeline that we go through is:
- Fetch the latest code
- Create a build for each platform
- Publish builds to steam on a development stream
- Promote from development to live
The first 2 steps – getting the latest and creating builds – are handled for us by Unity’s cloud build service. It could be said that I don’t have a lot of nice things to say about Unity, but the cloud build service is a definite bright spot. It’s great value for the price, and we’ve had very few issues with getting it to work reliably. It very conveniently has an API that we use for the later steps which makes it integrate easily. Setting it up was a very simple process, and it even integrates into discord to let us know when a build has failed.
Publishing builds to steam is a step that we have automated with a custom tool. As I mentioned, Unity Cloud Build has a server API that allows clients to search for builds and download the artifacts (the build output) for use. Steam has a publishing SDK that allows someone to create an automated process to submit builds. I put together a little server that combines these two systems with a management interface. Steam requires builds be on a local filesystem, and our builds are almost 1GB now combined, so it was easiest to get a little dedicated server that can have the correct configuration without needing to exist on any of our personal machines.
The server is controlled through a REST API – a series of HTTP calls that describe what you want it to do – and I wrapped them up into a little shell application that I run on my home computer. The whole system is written in Java because that’s what I was most comfortable with at the time, and I think it’s turned out very nicely. To publish the latest build, all I have to do is type: “bm-content publish editor” into my shell, and the server takes care of the rest.
What it actually does is:
- Ask Unity’s API for the latest editor builds for all platforms
- Download these build artifacts into the directory structure that the Steam SDK is expecting
- Generate the required metadata for the Steam SDK
- Invoke the steam SDK’s publish function
- Return all the output to the original HTTP request
Publishing a build typically takes about a minute, which could probably be made faster, but we don’t publish all that often and a minute isn’t really that long. Right now, we don’t have automatic publishing of builds because the team is small enough that when a change goes in, it’s not a big deal to publish manually, but there’s nothing preventing us from hooking up the publish server to the Unity Cloud Build notification hook and automatically doing it.
Newly published builds are put on a development branch on our steam application which means that they aren’t automatically pushed to everyone by default. I have my copy of Blightmare setup to pull from the development branch so that I can do a quick test of things to make sure they work before sending it out to the whole team. In a larger team, we would have a lot more information and process around promoting a build, but for Blightmare we’ve tried to keep things as simple as possible. Once I decide that a build is okay, I can promote it to be the default, and the whole team will get it whenever Steam decides to auto-update. If there’s a big problem with a build that is blocking the designers, we can easily roll back the promotion and Steam will again auto-update back to the previous build. This gives us a very easy way to make sure a broken build doesn’t stop work for too long and is a nice safety net. We can additionally add notes to builds to indicate that we may not want to promote them if they are known to be bad.
That’s pretty much it! The process boils down to a single command on my command line and then a quick change in the Steam admin UI. We’ve been using this process for well over a year now to publish a few hundred builds to the team, so I have pretty good confidence in it working for us in the future.
Thanks for reading and for supporting Blightmare! Please head over to our Steam page and put us on your wishlist to make sure you don’t miss the release and head over to our Twitter to make sure you’re updated with all the latest news. Have a great week!