In the Labs: Custom Build Configurations
“In the Labs” is a series of blog posts that put focus on features that have been prototyped internally but are experimental in nature and are not guaranteed to be included in Unity.
In this issue of “In the Labs” we’ll have a look at an experimental feature that introduces user-defined custom build configurations. The idea is that custom defined build configurations replace the fixed set of target platforms, and the things you used to be able to specify per target platform can be specified per build configuration instead.
This way it’s possible to specify more than one build configuration for the same platform; for example one for iPhone and one for iPad, or one for regular desktop builds and one for Steam builds. These are not built-in options to choose from; rather each build configuration is defined and named by the user and there is no limit to the number of them.
Support for inheritance
The custom build configurations support inheritance. One build configuration can inherit from another and only override select player settings.
This means it’s possible to define custom abstract parent build configurations, for example one shared by all builds for touch devices. All player settings common to these builds can be defined there once and for all instead of having to be duplicated for each build configuration.
Build configurations can either be for a specific platform (e.g. iOS) or be abstract. To keep inheritance rules simple, only abstract build configurations can have child build configurations.
Player settings integrated into build window
For each custom build configurations it’s possible to specify specific player settings. As part of making the player settings be per build configuration rather than per platform, the feature also includes the player settings inside the build window.
The build window and player settings always had a special connection apparent from the button in the build window to open the player settings, and the new build window takes it a logical step further and includes them directly in the same window. The new build window shows the build configuration tree as a replacement for the Platform list, and has tabs for Build Settings, Player Settings, and Scenes in the build, for each build configuration. Like player settings, each build configuration can also override (or not) the list of scenes that are included in the build.
In Unity it’s currently possibly to specify per-platform overrides in a texture, where the texture max-size or format can be overridden for certain platforms if desired. While not yet implemented in our experimental prototype, custom build configurations would provide the ability to specify these overrides per build configuration instead. This would allow for example for a custom iPad build configuration to specify a higher max-texture sizes than in the abstract parent Touch Devices build configurations. Naturally each override is still optional.
Build config defines
Unity includes the ability to write code that’s only compiled for certain platforms using platform defines. Another feature that’s not prototyped yet, but has powerful potentials, is the use of build config defines, so each custom build configuration can have associated code that only applies for that configuration.
By default when creating a new project, a set of build configurations are created out of the box. One configuration is created for each platform, and they all inherit from a common base build configuration. This means that the workflow can be just as simple as it is currently in Unity, and the extra flexibility (and complexity) that build configurations offer is entirely optional.
If you had access to custom build configurations, what would you use them for that you can’t do today? Or what workflows would become simpler for you?