In our Unity script, for making Mono builds: So at Hitcents we are currently building both IL2CPP and Mono versions of our Unity games in parallel, since we’ve found a few issues in IL2CPP builds. Unity is in the process of replacing its Mono scripting backend with a new technology called IL2CPP. 64 bit support on iOS is somewhat experimental/beta but is fairly stable as of Unity 4.6.3. We are also somewhat in a transition phase for iOS builds with Unity. In the case of iOS, Unity generates an Xcode project that you have to build afterwards. iOS BuildsĪndroid is easy, since you get an apk directly. So the slash direction for keystoreName has to be an absolute path and Unix-style? OK, that's cool. So then our Android build could be improved to take advantage of the version number like so: It also helps out in cases where a developer might overwrite these settings in the Unity preference pane on accident. I personally trust this a little better than the player settings file Unity stores this information in. One thing to note is that I am declaring many of the Unity build and player settings in C# code. I also setup my own environment variable, VERSION_NUMBER, that we can take advantage of inside our Unity script: I take advantage of the environment variable that TeamCity declares during a build, at the top of my FAKE script: Setting up proper version numbers during a build is fairly straightforward. So then to build for Android, the simplest platform, I would setup a FAKE build target as such: Setting up automatic versioning and other settings I generally use these FAKE helper methods to invoke Unity: I’ll show how to invoke Unity directly, which should still apply for your game. If you are starting a new set of build scripts for a game, definitely check out his library. So after setting this up for our games, I found out that has a nice FAKE library for Unity. Yeah, Unity can be pretty janky in a lot of places… But it is awesome enough at doing pure game development to ignore some of these rough edges. I think this causes some weird behavior in FAKE with invoking Unity on Mac with Shell.Exec - I have some workarounds when we get there. On Mac output is logged to the console, but terminal windows will lose focus as Unity is opened.(Maybe someone can provide a workaround in comments?) This is certainly annoying for automated builds, since TeamCity doesn’t have a great way to capture this log. On Windows output is not logged to the console, but to the default log file location.Android is the only mobile platform that Unity spits out the app directly. Creating a build with Unity is generally two steps: build the player, then build the native project that Unity spits out.So what are some gotchas with Unity builds? The GetScenes method we’ll reuse throughout, it grabs the level settings you have saved in Unity. This would use the default player settings you have declared for Android in your Unity project. Then you would need a class in your Unity project in an Editor folder such as this Android example: Generally you invoke a Unity build like this from command line on Windows: For making a build, you invoke a specific method in one of your scripts that starts the build via Unity’s editor APIs. Basically there are a set of command line options for running Unity.exe documented here. So how do Unity builds from the command line work exactly? A little weird. Some of the features of IL2CPP and PlayerSettings.shortBundleVersion are not available prior to 4.6.3. NOTE: we are currently using Unity 4.6.3, so code in the BuildScript class will change slightly for different versions of Unity. If you are looking for an intro on FAKE, check out my earlier blog post on it. We also chose to use FAKE, as we get all the benefits of checking our build scripts into source control, etc. So setting up Unity builds ourselves, seemed like a great option. We already have TeamCity setup, with a build agents running on a PC and a Mac for other apps. Builds can a really long time… Like an hour and a half… Ugh.It could be tough to figure out what went wrong with a build - you can’t exactly RDP into the build agent and open Unity.Our SCM we use for Unity, PlasticSCM, is not supported.Not much control over Unity player settings.Only iOS and Android are currently supported (we need Windows, too).Unity has released Unity Cloud Build, which is a nice solution, but it doesn’t fulfill our needs: Unity builds can be painfully slow at times, so not automating them is a huge productivity killer. So among the different types of games and apps we build at Hitcents, one particularly troublesome type to deal with is basically any game built with Unity.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |