Announcing Unity Cloud Build v1.0!

I am really disappointed by the final release. I was a huge advocate of the cloud build so far but the plans are simply ridiculous. Who has a repository including art assets that is below 1 Gb? I have a relatively small game but still it is already 6Gb. This means, I would need an enterprise plan already far exceeding $100!

If I read through the discussions where people share repository sizes that does not seem to be such an exception. Having the plans as they are right now, especially for me as a pro buyer and user, is simply a punch in the face. I am very disappointed. Back to offline builds for now.

 

Yes I was beta user (and gave quite a lot of feedback) and still let it build when I do updates which did not happen often for the last months as I am planning the next project now. I have PMed you and hope others post some opinions on the plans as well.

My proposal: limit other qualities but not the size, e.g. only X builds per day/week, only Y items in the history... etc. If these numbers are very small studios would instantly upgrade but indies could reasonably use it.

 

Unity Cloud Build is incredibly exciting!


However, I have to agree with @10FingerArmy on the disk space. We just tried out our app with UCB and hit the 2 gig cap immediately. It's just a bit too little for the "Pro" and "Studio" packages. It's strange because the local build is only 700 MB... and our repository is ~650MB. I'm probably doing something wrong for our UCB. We'll most likely upgrade to the Studio Plan for the extra space... but we sure would like to see if it works with our project before committing to the plan. Also - even low level support would be awesome with the "pro" plan.

Besides that, keep up the great work!

 

Yeah I'll just chime in to agree on the repo size limits as well, we used cloud build in the beta for a relatively simple 2D mobile game, and our repo is at around 2.5 GB. I could probably trim that a bit, but then again thats work that I'd rather not have to be doing.

Other than that, it's been a pleasure using cloud build during the beta, congratulations on 1.0!

 

I can only agree with the former speakers in this thread. I do large infrastructure projects. For this current project the Asset folder is 24 GB(Mostly textures). No Desktop, No PlasticSCM. Perhaps this is only meant for small Mobile projects or Web projects?

 

I'm trying for the life of me to figure out what this cloud service is useful for. Could someone clarify? Is the main point of it to give you quick build times? Are long build times a problem for a lot of users? If your entire repository (the sum of every source file and every check-in you've ever made!) is under 2 gigs, can your build time really be that long? Would the cloud build be useful for making standalone builds as well? Do you have to download your whole exe from somewhere once its built?

 

It looks to me like the biggest advantage of Unity Cloud Build is for mobile developers. Being able to download a build of your game straight to your device saves all the hassle of plugging it into your computer and building manually (especially if you've got team members who are working long distance).

As useful as it looks though, I feel I do have to chime in with my agreements with the previous posters.

I make games mainly for mobiles and the smallest project I've worked on so far came in at just over 1.4GB in size. Admittedly I probably could have reduced this a little with a bit of tidying up, but that would be an extra step of work that would take extra time (and time can be even more valuable than money when you're only a small team).

I'd be happy with alternative limits, such as just a certain number of builds per week as was suggested above, but the repo sizes really need to be bigger. Otherwise I may just not use the service at all.

 

I'm not sure where I stand tbh.

On the one hand, Cloud Build is brilliant - it's one of my favourite features, if you measure how much it gets used day-to-day compared to any other individual Unity feature or service.

On the other hand, while initially the build times seemed to have improved when it went Live, they look like they're going downhill again - I'm seeing anything from 7 minutes to over an hour. Early days, I'll be interested in seeing how Friday and weekend pan out.

Also, I've been wondering why I'm seeing "Pending..." states on the History page. None of this "30 minutes" stuff is explained in the product sheet - I'd never have known about it if I hadn't come to this thread. The delay between builds for the Pro version...30 minutes...is crushing. That means turn off Auto Build for one because you're suckered if you /need/ to do a build but something that doesn't work (WIP) has just built itself already... and plan your builds carefully. As I know, because I keep seeing "Pending..." ... and what happens if the build fails or restarts? (I'm looking at Pending now after a build failed after 4 minutes due to a pushed typo in git).

I don't want to sound like the half-full-glass guy because this is an incredible accomplishment for the guys involved and they've been great during the beta process, but the shiny new toy isn't quite so enchanting today :/

 

Hello,
i like that a 12 month subscription is included into the perpetual license , but my project is not that far in production that I can profit from this feature at the moment.
So my question is: Can I choose when the 12 month for the cloud building starts or did they start at beginning of March?

I couldn't find anything about this so far.
Thank you very much for your answer in advance

 

People forget that if you save the project as text it does not take up much place. One off my projects is 12 GB but only 1.3GB on my SVN server...

 

Okay, one more thing, I'm a little disappointed that we only get 12 months of cloud build with the pro license. It's one of the few differentiators left compared to the personal edition, and I know I'd feel much more comfortable with my investment in pro if I knew I could rely on pro level cloud build until it came time to upgrade the pro license the next time.

Also, how do you handle subscriptions with this scheme? It would seem I could be better of by getting a 12 month subscription to pro, with 12 months cloud build included, then at the end of that, I could get a new 12 month subscription with another 12 months of cloud build?

I'm also curious if we can choose when to start our 12 month period, because we have more than one license maybe we could spend the 12 months on one pro license first, and then switch to a different pro license for the next 12 months?

 

I agree with steego, the 12 months does not seem good if you already paid for pro. It should cover the same time period as the pro license does, monthly covers each month until end and perpetual until march 2017 or when ever next upgrade period begins.

Also unless I understood it wrong, it seems there is no benefit at all when paying for all three pro packages (core, iOS, Android) if the first one covers the same things. It does not seem fair. At least in the case of many there should be no month limit and more likely have some other perks tied to amount of paid pro addons (build interval, repo size?). I hope these can be forwarded to the people that decide the business strategy.

Generally the repo or project sizes in all packages seem very low.

 

I agree, too. I'm on a team working on a fairly simple "Gone Home" style game, and the project is 10 GB.

I haven't tested yet how much it uploads to Cloud Build because I'm waiting to hear the answer about when the clock starts ticking on the 12-month subscription with Pro.

 

Unity: It would be great if you could include the shareable link along with the build report email (on the Free Plan).

I'm working with one other developer and since I can't add him as a collaborator, I have to log into cloud build, copy the shareable link and send it to him each time. I know you want us to upgrade to a paid plan, but we're not there just yet

Thanks! Love the service otherwise - it's incredibly easy to use.

 

As a Pro customer who doesn't immeadiately need the 12 months ... does the time start ticking immediately or can I start the 12 month free Pro-User when I actually need to some time in the future?

 

Early Pro User, it seems UCB doesn't recognise my serial number. Otherwise, I'm really exited to try this out.

 

I also agree with the previous posts. As a single developer who bought a pro license and 2 pro add-ons I think the cloud build plans are really not very well balanced. While I used cloud build quite a lot during the beta period, I definitely won't/can't spend $100 per month to be able to build my projects in the cloud, just because the project is more than 2GB.

Another thing: Why is only 12 months included in a perpetual pro license, while it is without limit with the subscription pro license? This doesn't make any sense to me. Or do I get 12 additional months for each pro addon I bought?

I think the introduction of the personal edition last week is a great thing, but now I really need a good reason to not get a refund for my pro license. A good, unlimited cloud build plan would be a reason, but just a nice splash screen and a dark editor skin is *not* worth enough to spend thousands of $$$.

 

Do I need to run Unity 5 for this? I am hesitant at the moment to use Unity 5 as some have complained it's causing a drop in desktop performance.

Also, if using, will it allow me to circumvent Apples new interpretation of Test Flight???

 

@David Berger - thanks for the info! I'm glad to know that I'm not already burning into my 12-month period.

In the projects I'm working on, artists as well as coders use our Subversion and Git repositories to keep their files in sync, including source art. It's a shame that we'll have to maintain a separate branch with a different fileset (e.g., compressed png versus psd) just for Cloud Build.

 

Very good to know. Thank you

 

I also don't quite understand this notion. It first of all makes project handling much more complicated and it would also dramatically increase the size of the overall git repo.

But more than that: Why should I save an optimized version of my graphics in a separate branch instead of the high-res original? The beauty of Unity is that it will take all kinds of source files and convert them on the fly depending on the build platform and specs I chose (which can be vastly different if I do a low-res build, high-res build etc, branch for each??). That would be counter-intuitive to that mantra.

The only benefit I see right now is for Unity's cloud servers that do save a couple of megabytes but other than that I cannot see any good reason to do that. Please shed some light into the rational behind this guideline

 

I also think the size constraints are a little ridiculous.

I'd also like to see Plastic SCM support and Desktop builds.

 

I just looked at two fairly typical projects that I'd call medium mobile-sized, content-based games -- so something like an RPG versus something like Angry Birds that's able to heavily reuse a small set of art assets. The Assets folder in one is 5 GB; the other is 9 GB. They use Subversion. I don't know how much Git would compress them. But even with 2:1 compression this would put them in the $100/month Studio Plan -- and these are just 2-3 person indie teams, not big game companies.

The entry level plan for many cloud version control services seems to be about $10/month for 10 GB. Admittedly Cloud Build is more than a repository, but $100/month for just 5 GB seems a bit steep.

 

The project I'm currently wrapping up (which is lot bigger than Angry birds) is currently 724MB in Assets - this includes a lot of deprecated, WIP and test data - but the git repo is 556MB. So you get some benefit, and I've heard suggestions you can get more in some circumstances if you encode in text (most of my data is binary), but if you have a texture (especially lightmap) heavy project that's obviously not going to help much, and things are only going to increase exponentially as more people move to PBR workflows (hello 16bpc textures).

I don't include raw source art for the bulk of content in git repos (with the exception of smaller textures) as git repos are size limited anyway, i.e. 2GB on Bitbucket, unless you shop around; rather I have a script-based pipeline to update everything when source art changes. I'd have to be mad (not to mention unpopular with my low-bandwidth cohorts) to put 200MB .PSDs in a repo anyway.

Of course this is mobile, where the worst is having to store retina + standard art.

I'm surprised I'm the only one who doesn't like the time-lock

 

The projects I cited above make heavy use of the Asset Store, which is something I imagine Unity would want to encourage. A project might import a 500 MB art pack and only use 50 MB of its content. Import just a handful of art packs from the Asset Store, and you could easily be in the multi-GB range. Designers could be tasked with manually deleting unused assets, which is something you wouldn't want to automate because you want to have a human eye over content that you may plan to use in the near future. But this is time-consuming and can be undone the next time someone imports an updated version of the package. The 9 GB project I mentioned above currently builds to a 0.6 MB desktop build because it only uses a smattering of content from each Asset Store package.

 

@David Berger

To be frank, there’s not a lot to like about time-locks. They're the sort of thing you expect to find in a freemium game…”Wait 30 minutes to recharge, or pay to continue playing right now”. While this may work for games, it doesn't work in a fast moving working environment.


In practise it’s a bottleneck and a pain that works against what was so attractive about the service in the first place: always having the latest code built with auto-build, and being able to quickly respond to requests for tweaks, changes and updates at a moment’s notice...make your changes, commit, and it’s pretty much fire-and-forget.


The 30 minute lock means Auto-Build has to be disabled, as real-world demands mean you usually have to provide a demo test build at short notice (short notice being five minutes ago), and if AutoBuild was doing something you’d have to wait for the whole system to flush itself out before your latest commit can be built. Even when you manually build, if there’s a problem with the last commit and it fails or needs cancelling, you have to wait the whole 30 minutes again...that easily turns what could be 15 minutes into over an hour, in which time I could provision, build, test and distribute ad hoc builds by rotating my chair 90 degrees. It’s not a more pleasurable experience, but it’s better than telling someone they have to wait another hour.

I realise we can get that down to 5 minutes by upgrading to Team, but for the price increase to Team I’d want a lot more than just a reduced time lock and slightly bigger repo size (and we personally don’t need huge repos as is).

I don’t like being all negative about it, because I think Cloud Build is ace, the support was excellent during beta, and it has been rock solid since going live, but I feel like the business model is doing it (and us) an injustice.

 

Just chiming in here to add to the chorus. My repo is 12GB+ The CloudBuild limits are making it prohibitive for me to upload to UCB. I would have to flatten all my raw photoshop files losing all my layers for later editing to get that size down. There needs to be a way to have unlimited asset folder sizes so artists can freely work without having to watch file size. Also, as a pro user I want to have at least 20 collaborators for testing etc.

 

@hyperNate - All the cool things that were suggested/thrown around during beta

At the fore-front, the Testflight type stuff - a client App and front end for users; nicer way to manage and organise build sharing and build history (bundle versions as well as UCB build numbers); closer syncing with production patch builds (it's obviously a big deal if you can’t use UCB at all because you need an emergency fix from a particular build).

I guess basically, putting teamwork into Team. Team-tastic. I'll stop there.

I know these don’t happen overnight of course, but as value-added goes they bring a lot to the table.

local timestamps would be nice too, though I guess everyone deserves those

 

Is there any way to schedule regular builds? It would be really convenient to have nightly and noon builds so that testers and production staff can get new builds on a regular basis without eating into developer time.

 

We just noticed that even a failed build clocked as a build and we need to wait 30mins for another build. Its a long wait...Its better if the failed build doesnt count because we wanted to build immediately after it fail.

 

Any chance on this getting added in? Would love to be able to grab the build file and move it somewhere on the free plan via script.

 

I really love Unity and what they've done. But I'm having an incredibly hard time understanding all these new changes. UCB seems WAY overpriced, and not 100% useful. This is the only major benefit to Unity pro now, so I will only be purchasing pro if/when we exceed the 100k cap. I've been over the features/comparisons and ... Ya I honestly hope people are actually buying things. I think I'd rather have unity free go back to how it was before so I can justify spending the cash for all the licenses for my team. I want all the goodies. The image effects, the profiler, the editor themes and custom splash screens... Then everything that I wanted was given to me except the stuff that isn't worth paying for. So, as a responsible manager of I money I just don't get to have that stuff. I look st cloud build, and the team server, and premium support... the payment models and usefulness seem borderlines useless in most cases. At this point I'd pay maybe $100 just for the dark theme and splash screen. I don't need anything else. I was about to throw down the cash too and then 5.0 came out and I was forced to put my wallet away and leave the subtle goodies I desired by the wayside.

And to stay on topic I'll reinforce that the pricing of UCB is laughable, imho. Keep in mind this is just a time saver. Sure, time is money, but managing builds isn't that complicated of a process, and paying a monthly fee for endless months just to save time is likely going to cancel out the returns on saved time. Again... IMHO.

 

Loved Unity Cloud Build during the beta, love it now (with a pro 5 account), but the pricing structure now is honestly baffling to me and I absolutely would not and will not pay for it whenever my subscription expires. Cloud build is a great timesaver and automation service, but it doesn't provide any tangible product (like Unity Ads or Everyplay). It's benefits are entirely in time saved and headaches avoided. These are nice, but when you introduce 30 - 60 minute time gates between every build I'm afraid you've missed the point entirely. As has been noted many times, the repo size limits are a bit of a joke as well, as even small indie games can and do quickly exceed that. Add to all of that a monthly fee (even for pro users?!?!?) and the whole thing is laughable.

This is exactly the sort of convenience service I would expect to see given freely to pro users, who have already paid $1,500 plus for what now amounts to a smattering of services that can be accomplished for much cheaper through sellers in the Asset Store. Unity Analytics isn't built in, so you might as well use a different service for the same amount of work. The same goes for Unity Ads. There is so little reason to buy Unity 5 Pro now that I'm surprised it still exists as an option. I mean why not just offer all the services separately à la carte? Guess you couldn't charge $1,500 for custom splash screens then.

The CB beta was great, and now this. So frustrating.

 

From the product management perspective it is much better to start with limited features and then gradually give out more than the other way around (remove features already granted to users). And it requires some experimenting with actual users to get the feature sets, pricing models etc. right. So even though some of the limitations are a bit frustrating, I quite understand what UCB people are doing (and also expect things to improve once they have gained enough understanding on how the service works best).

 

First off the Unity Cloud Build service is awesome, we used it a ton in beta for two projects and it helped development mainly to test when things break across platforms and for faster build prep so thank you.

The 3 things I like about cloud build:

1) Run builds at any time and not have to wait while we can continue to work (build processes are longer and longer with IL2CPP so this is even nicer now so you can keep editing on next while it builds).

2) Repos don't have to be on all my machines or build machines on our servers, we can dump our GBs on a cloud server and not think about it because projects get big even with smart git submodules and careful culling of project fat.

3) Having all platform builds iOS, Android, Web run at close to the same time and being able to see if things break or distribute from there.

The benefit of 1 + 2 have been lessened greatly with the pricing structure and possibly uneconomical when compared with our own build automation, whereas before UCB beat it even though it took longer to get builds out, the parallelism to keep working while building was awesome.

GB Limit

I think the GB limits need to be 10x current limits at least and the wait times removed above free (or a submodule allowance as long as actual repos are under 2GB like bitbucket forces). Otherwise it is cheaper to setup a build server or two to run just when needed to update builds in other cloud services with more setup yes but the current limits are too low. Bandwidth and transfer are cheap these days, this shouldn't be a problem.

The asset store prevalence also makes larger projects than are used, sometimes only 2GB of a 20GB project is used but culling too much is time consuming and would discourage larger asset store purchases/importing. Maybe a better way to only push a build ready culled build to UCB would help this, but most people aren't going to want to limit asset store behavior/usage.

If build history and keeping all those big builds are also a problem in terms of storage, set limits like only keeping the last 10-20 and being able to pin/star up to twenty which need to be kept i.e. major revisions etc.

Time Limit

I can understand the limitation on time/frequency due to the cost of CPU and VMs running but it still seems too limited. Maybe a limit per day instead of time lagged? We typically build projects in bursts and might have 5-10 builds in an hour but then maybe not one for a day or two or a week.

Maybe a limit of n builds per day. We probably build 5-20 times per day and making us wait across half hours is a bit of a bummer if not a deterrent. Or maybe alternate build plans that give allowance that you can use at will at any time limited by quantity. If you have the pro plan at 2 builds per hour to make that cost effective, 24 per day would be better to use at will rather than throttled by time.

(Git) Submodules allowed or included in GB size?

In regards to repo size, most of our apps have all repos under 2GB but we have 5-15 submodules per project that can also be up to 2GB per project. Most of our games end up in the 8GB-20GB range We can easily get to 20GB per project even if all git submodule assets aren't used in the project, that is how we set everything up to help workflow and our build solution has to fit that.

We try to setup our production branches or remotes with less checkins to limit overall size from the development cycle, limit asset sizes, constantly cut project fat, but there is no way most market Unity games are under 5-10GB. As of right now we can't even take advantage of the free year at the 2GB/30minute throttling which is a bummer.

Overall Pricing Thoughts

Side note, I also worry a bit with pricing based off of sizing and build times that Unity controls via development. In theory, there is no reason for Unity to prioritize increasing build times or compression on projects if it means it impacts other parts of the business pricing models. That is why if you set them above typical limits rather than below then Unity has a desire to make builds faster and smaller to help their own bottom line as well as the developer, rather than impact revenues by improving developer usability/build times/project sizes and management of project assets etc.

Ultimately, if the pricing can't change or limits/sizes, it would be awesome to have the ability to price the cost of a single build * amount of builds. I still dislike limitations by size or timing but you should be able to get a per project cloud build cost by the size of the project or some estimation, then price the tokens to build above that. If I see it as some amount per build that I can just use (even right in the editor - a 'cloud build this build for an estimated $') run that month and it tallies up in cost that month until I need to stop like buying apps on iTunes. I guess more of a token/toll system instead of a monthly service at current limits. We can also easily push this into client costs if it is broken down by project.

 

It has become a bit quiet here again. Are there any updates on the tiers or future plans? I am now in a stage that I leave early prototyping phase of my next game and it would be great to have it on UCB. It is already 11.3Gb though (git folder, on disk 23Gb) containing many assets I will use later in the game. That makes it pretty much impossible to use UCB which is a shame.

 

Some constructive criticism:

Regarding sizes. Our project is at 74.6 GB and with a team of 5, 2 of us programmers doing commits several times a day each, the pricing far outweighs what we spent while waiting for PC support during the beta to set up a Team City build server of our own.

Studio Tier should include a single dedicated build machine or dedicated VM with at least 2 cores at the price charged. A build server running from RAID SSDs and a good UPS can easily be set up for under $1200 which is the annual subscription cost. I can't see many managers approving the cloud subscription over a dedicated server without at least an annual cost and feature set that is par with the latter.

Suggestion:
Rather than Cloud build, for non-mobile platforms, a custom wizard for TeamCity installation and configuration, and maybe even GUI frontend for TeamCity with an in-editor administration panel might be a good direction to go for Unity Pro users.
That would definitely be a useful feature for us. It would have saved us a week setting it up and saves one of us having to go to a different desk and check the logs when a build fails.

 

Repo Size 2Gb with Pro?
My starter template is around 3-4GB which includes basic assets from asset store. I believe repo size is too small.

 

I really have to say, the sizes of all plans are simple rediculous small. Even our Astroslugs project had nearly 2GB and it was way before Retina iPads.

Now I'm sitting here, with a Pro Plan (thanks god I had nothing to pay, besides GitHub because UCB do not Support Plastic SCM) and can't build because my project is 300MB bigger.

The price, the size and the time limits are not well planned. Sorry to say that.

 

What if I have to build a project 60 GB in size? It is possible with 'Build in Cloud' option? Other options, as AssetBundles may work?