Does Unity Pro Play Nice With 'Small' Teams

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.