Unity, the popular cross-platform game engine, already comes with a ton of features and many user-friendly tools. However, all of us might have reached the point where we recognised the need for a missing feature and thought: “Ok, that is something that Unity should have built-in already!” The moment you realise this, you might want to start working on your own packages, which you then share with like-minded developers across the world.

That’s precisely how we think here at Endava! When we detect that a piece of code or a tool is used more than once within multiple projects, we build a shared package to improve maintenance and simplify reusability.

Creating tools helps you to improve your productivity. Tools can save time, reduce the cost spent on repetitive tasks and reduce the risk of errors by streamlining the build and deploy processes. The time and effort saved by using a tool will enable you to spend that time on more important tasks or may simply help you to shorten your time to market and make your builds available much faster – especially for Games as a Service, shortening release cycles is critical for the success of a game.

We think sharing our experience with you is the next logical step in trying to make such tools universal since every piece of feedback and usage will help to improve them further – and maybe convince Unity to include these features into their product…

Let’s take a look at some of our new tools and Unity packages in this 2-part series!

Unity Build And Deploy

• Developers: Robert Stamm, Christopher Etmer, Olaf Spiewok
• Unity compatibility: 2020.x – latest
• BuildAndDeploy on Github

Introduction

Once your development gets to the point where you can build your project for your target platform and test it there, you may need to create variants for each build target and environment. Unity is doing a great job of streamlining the build process by using platform-specific project build settings where you can configure all the parameters properly. But as soon as you want to have multiple builds on the same platform – like having Production, Staging and Development builds with different properties, like project name, version, ID, preprocessor flags etc. – you reach the limit of Unity’s current build capabilities.

With our BuildAndDeploy package, you can reconfigure the build settings of a project by using multiple build configurations, thus bypassing the restrictions of the general Unity Build Settings.

Our motivation

BuildAndDeploy allows you to create multiple different build configurations, so-called Build Process files, for the same target platform. Think of targeting a standalone Windows build, which needs Steam, Epic and retail build configurations that all share the same Project Player Settings. Thanks to Build Process objects, we can support different target properties and library configurations since each process takes care of the necessary preprocessing and building steps. Another example could be an Android build, which needs to adapt depending on Google, Amazon or Amazon Kids targeting, with different keychain settings and library configurations.

Each build can be configured and extended through various settings and pre- and post-build steps, including code adjustments, library inclusion, asset building, file process methods and more. You can also add custom steps and custom ‘modules’, which will allow you to completely adjust the build to your needs and desires.

Streamlining the build properties and the options for pre- and post-build tasks can be quite a time saver since every task that has to be adjusted manually takes away from other great things you could do during that time.

Control your build using build process objects

Once the package is installed using the Package Manager, Build Process objects are available on the BuildAndDeploy menu and allow you to re-adjust the build as you need:

In general, every Build Process will ‘mimic’ the main build settings, which you can find within the Unity Build Settings menu, but it includes many additional features.

The Build Process contains so-called ‘modules’ that allow you to configure every part of the build pipeline.

Any inconsistencies or errors flagged by the package will help you configure each build process correctly. Validation is an essential part of the build process since it can become very frustrating to wait for a build – which can take hours – and then discover that some steps were misconfigured. In addition, you can toggle, extend and properly test every module, including specific parts of your pre-executed steps, like file copying. You can also choose to create an isolated logging file within the build process, making it easy to track and inspect any errors and warnings without the need to navigate through all of the Unity log files and their complexities.

Once you have completed your Build Process file, you build your variant using the ‘Build’ button and wait – as you would typically do since this is generally a time-consuming process.

BuildAndDeploy can be used if the build is started within the Editor, is a Unity Cloud Build or is started as part of a command line pipeline.

Customise your Unity build

Since building a cross-platform game always requires adjustments in several of the platform-specific project settings, a core element of the build process is its extensibility. For example, if you need an additional module that takes responsibility for downloading additional data, like updated localisation information or assets, before building, you can create your own module to do this and add it to your build process.

There are several ways in which you can customise the build process to your needs:

The package itself includes the ability to perform some common steps, like changing compiler flags or running platform-dependent tasks. These are a good starting point for understanding the possibilities of build customisation.

Furthermore, every build process can detect additional ‘module code snippets’ within the project and render them inside its Build Process Inspector. There are no limits to the code you can add; within a module, you can do whatever you want. Just bear in mind that a module should be something essential that every part of your build requires.

Finally, if you just need to adjust a small part of your settings for a specific platform, consider customising the pre-/post-build steps. These are responsible for performing tasks before and after the execution of a build and are a good place to include simple file execution processes, like renaming files, changing project setting properties, adjusting Xcode or Android Studio project files, increasing version numbers etc. It’s up to you what you want to use these steps for, and extending them is usually good practice.

Validation and parameterisation of each build step entry provide flexibility and create well-documented, highly reusable tasks within your custom build process.

Conclusion

Our BuildAndDeploy package enables you to easily create highly customised builds for multiple platforms. We’ve added many customisation capabilities that allow you to include and extend our package within your project code base or build an add-on package on top of it. Streamlining a build can spare you a lot of time and headache, and using a continuous integration system for your build will increase the benefits further since every place where we can automate configuration adjustments is a win.

Even if Unity decides to extend the existing build process feature to allow for similar platform setting entries, our tool will still be useful since having pre- and post-execution tasks is a valuable feature that our engineers love to use.

In the next part of our Unity tools series, we’ll meet our UXML Binding Generator.