To see my first post about Unity Cloud build, go to I Wish I Could Hug The Cloud.

This will be short and sweet, but I’m so excited I had to post something. At Unite 2015 in Boston, Unity announced that they would be adding a few new features to their Cloud Build suite.

  1. They’ve added support for more targets, specifically PC builds! Windows/Mac/Linux builds can now be generated; they are handily delivered in a downloadable zipped archive. This includes x86/x64 builds for all platforms and universal builds for the -nix platforms. This functionality is in beta, but has worked like a champ for me so far. To test this new functionality, visit Unity Cloud Beta.
  2. Mercurial has been added to the list of supported version control systems. This is in addition to SVN, Perforce, and Git.
  3. These features are supported for all tiers of Cloud Build Plans, so even the smallest of teams using the Personal version of Unity stand to benefit.

I don’t have much more to add, but I continue to be impressed by Unity’s commitment to providing excellent services to developers. They truly are making my life as an indie developer easier. I wish I could high five the whole team. Thanks, Unity!


I’m seriously in love with Unity Cloud Build. It’s enabled me, as a solo developer, to focus on other aspects of development and business. Anyone using Unity for Android/iOS/Web Player should examine whether it would be an asset to their development pipeline.

At each of my previous employers (even the small ones), we used build servers to do continuous integration and build mastering of our console games. While it was sometimes a fragile process, it paid off in spades. Our on-site build servers handled merging all the work together and cranked out fresh playable builds for QA or for delivery to our publishers. The only cost was setting up one or more build machines and the occasional programmer/IT time to add new hardware, update software/libraries, or add new target platforms.

Given that it’s very comfortable to work in that kind of environment, it’s one thing that I wanted to have even in my solo development. Thus it became the first thing I set out to implement when I ventured into independent development last year. It ended up being a bit more time-consuming than I imagined it would be at first.

The Hard Way, Part 1: Creating A Custom Solution

I definitely wanted to target Apple devices, so this meant that those builds had to be authored on a Mac machine. So I started off by firing up my Mac Mini and installing my CI build service of choice: Jenkins! is definitely worth checking out; they take care of much of the hassle and leave minimal work for the developer. Everything can be accessed via their web client: monitoring and triggering builds, tagging and archiving, sending notifications on success/failure, along with a host of other features.

A Google search for “Unity Jenkins” pointed me to a great tutorial that I started to follow.  As it turned out, there was already a Unity Jenkins Plugin.  It appeared to automate most of what I would need. I was ecstatic! In 20 minutes, I felt like I already had the tools to get continuous integration rolling for my games. Soon I had the build server pulling down all of the game content from an SVN repository and was well on my way, or so I thought.

The Hard Way, Part 2: Results of Custom Solution

Fast-forward to the next day (after a late night of frustrated attempts), and the situation was not quite so joyous.angry

No amount of arguing, bullying, or pleading would get the entire process to work correctly. I had followed all the steps from setting up provisioning profiles to configuring Xcode to creating a build slave that ran on the same machine…nothing worked perfectly. Granted, it worked beautifully for all builds that were not targeted at the Apple platforms. It should also be noted that Jenkins performed admirably and made it so I could customize things every step of the way. The biggest problem was Apple’s arcane and annoying development process.

Another long day of debugging and testing and I finally had the process working from beginning to end.  Builds for iOS and the Mac App Store were finally created and signed correctly and were properly uploaded to TestFlight to be pushed out to my devices. The whole thing was elegant in no way, and very closely resembled a Rube Goldberg machine. But it worked. God help me, it finally worked.


For the next few months, this cobbled-together CI system ran beautifully with very little maintenance required on my part. Despite being a little unhappy with it, it was a passable solution, and I resolved myself to revisit it in the future.

The Hard Way, Part 3: Disaster Strikes

One day, I got a notification that I had an OS update available on my Mac and I applied it, thinking it would be no big deal. This update wrecked everything. Nothing worked at all. The server installation was ruined, the slave wouldn’t connect, the signing was broken, Xcode was pitching a fit…but that wasn’t the worst. The worst thing was that I had not backed up my system before applying this update. I had no easy way to recover.

In all my years of programming, I’ve never been so upset that I cried over something breaking. This time was the closest; I was distraught.

As I was sitting in my chair stewing and contemplating my options, I get a notification from my e-mail client: “You are invited to try Unity Cloud Build Beta!”

I began to wonder if someone from Unity was spying on me. The timing was almost too fortuitous. Pushing aside my crazy paranoid thoughts about Unity, I decided to give it a shot. What could it hurt to try it at least?

The Easy Way, Part 1: The Clouds Part

I followed the link and did the basic setup, which went quickly. Twenty minutes later, my game was building in the cloud. I kid you not, it was that easy. I was playing a WebPlayer version of my game built on their servers just a few minutes after completing the setup. It monitored my SVN repository, sent e-mail notifications, and supported a few platforms (most importantly, iOS.)

For iOS, which had been the thorn in my side, I just had to get a couple of items for signing apps off of my Mac. They turned a process I had struggled with for three days into a simple 5 minute task. It worked right out of the gate. 10 minutes later, I was playing my game on my phone with no hiccups.happy-happy-joy-joy-o

I almost cried tears of joy. Seriously. I could simply bring up the Unity Cloud Build project in Safari on my iPhone or iPad and install from there. No TestFlight required. No yelling at my machine, no begging the ghost of Steve Jobs to take pity on me.

As an added bonus, I got back one of my Unity Pro keys since it was no longer needed on my Mac Mini. I re-purposed that key and put it on my laptop. I could now safely ignore Apple machines and the bizarre provisioning requirements entirely (sorry, Apple guys, my personal preference is PC.)

Another great bonus I discovered was that I could choose which Unity installation to use for each project in my list. No need to upgrade Unity on my build machine anymore, because the Unity Cloud Build team handles all of that stuff. I can simply tell it to use the version of Unity I have installed on my development machines, or always ask it to use the most recent published version of Unity.

The Easy Way, Part 2: The Angels sing

Since that day, I’ve exclusively been using Unity Cloud Build, and while it’s been great, it’s not quite perfect. If I could squeeze just a couple more features out of it, I don’t think I’d need to even consider a custom solution for my Unity projects. Here’s my short wishlist:

  1. Support for building on more platforms.  Ideally, it would support all of the platforms that Unity supports, especially Windows/Linux PC builds.
  2. Mercurial support. It’s the one major source control system they don’t support yet.
  3. Options to select Unity installation on a per-platform basis.

Even without those things, Unity Cloud Build will remain my go-to solution for authoring iOS/Android/Web Player builds, and I strongly recommend anyone making a Unity game for those platforms to check it out ASAP.

This is the best way to write prototype code.

This is the best way to write prototype code.


All right, it’s time for some spare-time fun, and nothing says fun like prototyping a game idea.

After taking a quick inventory of my home office, I have all the things I need.

  1. An idea worth prototyping
  2. Spare time
  3. An industrial-sized barrel of motivation
  4. Unity3D
  5. OUYA devkit
  6. A method of source control (SVN/Git/Mercurial/Perforce/etc)

Since I figure I’m not the only one that might have some or all of these things lying around, I thought I’d talk a little about what I do when I prototype a game or game mechanic.  It’s really a pretty simple process.  The first thing I do is set up a Unity Project.  Basically, all that I need is a project that compiles and an executable to deploy to my target platform (today it will be the OUYA).  Once I reach this point, I CHECK IT IN TO SOURCE CONTROL.

Source control is my best friend when I prototype.  I’ve learned to love pressing that “commit” or “push” button.   My mouse is probably wearing out faster than it needs to because I’m always hammering on that button any time I make progress on a gameplay mechanic.  I know it’s only a prototype and it might get thrown away in the end, anyway, but trust me when I say that it is a benefit to have frequent check-ins.  Just having the ability to easily roll back a prototype to a stable state is amazing.

After this I pull out a few notecards and start writing down little stories for the things I want/need to accomplish (this is sorta like a user story in Scrum/agile development.)  I try to phrase these stories as though there is an end-consumer in mind.   Usually the customer is the player, but sometimes it is a designer/artist.  As an example, I might write a story that says, “The player can move a 2D sprite-based character around on a grid using the controller.”  This sounds like a pretty big task, and I could break it down into smaller sub-tasks, but this is just about the size of the things that I want in the beginning.  It’s clearly a feature, and it’s the sort of thing that should take less than one day/evening of work to accomplish.

In the end, I might write 4 or 5 cards based on the highest priority items for the prototype.  High priority tasks do NOT include things like “Main Menu” or “Game Icon Creation” or anything that does not specifically lead to gameplay testing.  It should also be noted that I spend very little time making my own art. I tend to start with an online search to see if someone else may have already done art/music that I like.  I go to a place like OpenGameArt, for instance (there are plenty of others out there, look around.)  I find my order of importance for the overall tasks is:

  1. Gameplay/Mechanics
  2. Gameplay/Mechanics
  3. Gameplay/Mechanics
  4. Gameplay/Mechanics
  5. Gameplay/Mechanics
  6. Thematic Elements (Art/Music)
  7. Menus and other low-hanging fruit

Now that I have some placeholder art/music, it’s simply a matter of trying out new ideas (and not being afraid to throw out ideas that just aren’t working) and completing the stories that have been written.  I always feel free to write messy code if it’ll let me get to the core of the gameplay faster.  Sometimes I’ll end up writing a new card to explore an interesting aspect I’ve stumbled upon while completing another task or I’ll throw out a card if it no longer fits with what I want to accomplish.  It’s a lot of rinsing and repeating at that point.

If it’s a successful prototype after enough work or a given amount of time,  I’ll restart the whole process in a clean project as though I’m doing real development.  I rarely, if ever, re-use any of the prototype code or assets in my new project; it was just for learning purposes, after all.

So I guess that pretty much wraps up my description of how I prototype and it appears the first major check-in for today’s prototype has uploaded to source control.  Time to get on with the fun!