Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Does anybody know how well Unity Pro plays well with-in small teams? Our team makeup is 2 programmers, 1 audio, and 2 graphics peps.

How easy is it for somebody to mess up a Unity project? The graphics and audio people will likely only have a simplistic knowledge of Unity, and mainly in regards to only there area.

Do the graphics/audio even need access to the Unity editor?

I've seen the Asset Server and it seems like a very bare bones versioning system.

Before people start telling me that they should just learn it (as I agree) this is a rather last minute student prototype project.

share|improve this question
Regardless of the answer, you need to train your people on Unity. This will be a major help. I've heard unity doesn't play well with version control, but let someone more knowledgable answer that. – ashes999 May 14 '12 at 16:41
@ashes999 Yeah, unfortunately because they have todo it on their own before hand, it means they wont. – PhilCK May 14 '12 at 16:50
@ashes999 Unity Pro works very well with version control, because it gives the option to specify that you're working with version control, in which case it will change the way it stores object metadata. Unity Free used to be almost impossible to work with, but now I believe 3.5 Free has the Pro version control option available. – ktodisco May 14 '12 at 17:35
Thanks @ktodisco, that makes me very optimistic. – ashes999 May 14 '12 at 18:13
I haven't tested it specifically (I'm on a project that's given me a Pro license for now) but I was told by a Unity rep at GDC that, yes, 3.5 includes the VCS button in both Indie and Pro. – chaosTechnician May 14 '12 at 23:31
up vote 2 down vote accepted

Generally, it's easy for someone to mess up any project, Unity or not. What matters most is that people learn how their project works and what could mess it up.

Unity, on the plus side, is very easy to learn. I've worked on three Unity-based projects, all with small teams of 5-10 people, and I've never seen anyone mess the project up... much. I mean, there were some misunderstandings, wrong files committed to source control, etc; but nothing that couldn't be fixed in half an hour tops.

Unity is pretty easy to use, and one of its strengths is that it allows your audio/graphics guys work in the same editor as everyone, and easily test their work in-game. Being able to immediately see one's work ingame is a big boost to productivity. Also, Unity is very easily extended. You'd probably find yourself coding dozens of little tools to help both programmers and artists with their work, and this will probably add up to big savings.

Regarding source control, don't even think about Asset Server, it sucks (AND costs money too). Since 3.5 Unity supports external source control even in free version; and also text-based asset format that is more-or-less merge-friendly. I've successfully used SVN with Unity projects, and I believe Hg or Git would work like a charm too.

share|improve this answer

I have myself been using Unity for two smaller projects now on teams of 5 people, and it works pretty sweet. By putting up the asset server your team can collaborate well with each other and version control works swell as well. With that in mind it is important that you maintain communication even when using Unity Asset server as it is still possible to mess things up a bit, though the Unity Asset server history can resolve many issues as well.

You mention that your a team consisting of programmers and a graphic/audio guys. In our current project, we are three programmers and an audio guy (We make audiogames), and our sound guy just spits out audioclips like a fountain into our Project with ease and without any issues.

The biggest problem we have is when the programmers are changing the scene (We only use one scene), though it is always quickly resolved.

share|improve this answer

We use Unity Pro and Mercurial for version control and things works pretty well. We didn't feel we needed the Asset Server.

One thing to notice is that before Unity 3.5, we had problems with people working with the same scene: those files were binary, therefore there were no way to merge. Now, Unity provides a YAML-based asset serialization option, so everything can be easily merged. But that option is for Pro only.

Our artists doesn't use Unity. Sometimes, an artist use Unity do make some things, but that is rare. One example is the terrain. But everything else is made with other software and imported by a programmer.

share|improve this answer

How easy is it for somebody to mess up a Unity project?

If you have a lot of data defined via the Inspector, and therefore stored in a scene, it's quite easy for someone to make a change that potentially conflicts with someone else's. If you use the text-based scene format then it's possible that your source control software can merge the changes, but not guaranteed. Be prepared to have to resolve merge conflicts to continue.

If you don't use version control, then people will tend to overwrite each other's work on a regular basis, because of the shared scene data. One way around this is to avoid storing anything in the scene and instantiate everything from code - but going down this route starts to lose you many of the benefits of Unity.

Do the graphics/audio even need access to the Unity editor?

This depends how much work you want the programmers to do, and on the type of project you're making. The art and audio people can just export assets and programmers can import them, if you like. But some teams prefer the artists to check their assets work properly in the engine, and to have the audio people place the ambient sounds in the correct locations and check the relative levels as they walk around, etc.

share|improve this answer
Adding onto this - scene files are definitely the biggest bottleneck for teams. Structuring your project so that contributors can mostly work on prefabs (or custom assets) independently, rather than all editing the same scene, will save you weeks of headaches. – DMGregory Apr 15 '14 at 14:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.