- #Unity mac build support full#
- #Unity mac build support android#
- #Unity mac build support pro#
- #Unity mac build support software#
There are still some things that can be improved. What this does is start Unity with the project that is currently being built in batch mode (no window is shown), execute our main build method and quit at the end.
#Unity mac build support android#
So, for example, if you want to build an Android version, you can have the build agent start Unity with: "%UnityPath%" \ Regardless, a simplified version that you can use as a starting point for your own pipeline can be found here.
#Unity mac build support software#
We wanted to open-source our own build pipeline, but unfortunately parts of it have software with proprietary licensing. You can also access all of the command line arguments that Unity was started with, allowing you to pass and use your own. Note, there is no command to execute a build, but -executeMethod argument can be used to execute pretty much any method. Luckily, Unity supports a bunch of command line arguments which can be found here. The build server can start Unity with the provided arguments, but it is up to your build pipeline to actually execute the build correctly. They tend to speed up builds by an order of magnitude. Textures that ended up in the source control repository have already been compressed by the people that imported them into Unity, so the build agent would just be doing the same work again, which is why it is extremely important to have a powerful Cache Server in your infrastructure.
The trick is: Build agents shouldn’t compress anything. PVRTC compressor), which can significantly slow down the build process. Texture compression can take a really long time and use all of the available cores on your machine (e.g.
#Unity mac build support pro#
For us the optimal number of agents running on a single Mac Pro was 5. Since most of Unity’s build process is single-threaded, we decided to use Mac Pros (6 core CPUs with hyperthreading) with as many build agents as possible. In regards to hardware, all of our build agents are very powerful Macs, because having iOS builds is a must and we wanted to avoid the additional overhead of managing a mix of OS X and Windows machines. In our case, we compared Bamboo, Jenkins and TeamCity and finally decided on TeamCity due to its flexibility and ease of use, but pretty much any CI server should work great depending on the feature set that you need. CI servers are excellent for this, even if you don’t want to use anything CI specific. Three major pieces of the puzzle were:īuild server is the heart and soul of the system, since it monitors source control (git in our case), coordinates between multiple build agents and executes builds. This is why we decided to build our own infrastructure, in-house. As an example, Top Eleven has a lot of auto-generated code that requires starting Unity four times in a row for all of it to compile properly, while another project uses 2 different source control systems at the same time.
#Unity mac build support full#
The biggest problems were our code repositories not being exposed to the internet, and complex build pipelines that we need to be in full control of. A really good solution is Unity Cloud Build, but most of our games don’t fit the imposed limitations.
And since it only takes one push to the source code repository to get the latest version to run on your device, our artists and game designers became much more involved with the faster iterations on the project.Īutomated builds and continuous integration (CI) solutions have been widely researched and implemented, but there is very little information that is specific to Unity. This is one of the main reasons we wanted to automate our builds and offload them from the developer machines into the cloud.
In one of our projects, developers were waiting for upwards of 15 minutes to get the Android version of the game. Building any large Unity project can take a lot of time while preventing you from using the editor during the process.
0 kommentar(er)
