multiple groups developing a single iPad game in Unity

I've added the workflow and version-control tags to your question. I recommend you read over the questions with those tags, as the topic of sharing a project in a team has been discussed before extensively. This question might be a good starting point.

If these are separate mini-games this should be pretty easy using scenes. You would just load different scenes from your main menu, which would be another scene itself. To interact between scenes (global score etc.) you can use GameObject.DontDestroyOnLoad.

If you use different scenes you also keep the sync overhead to a minimum, as the different teams don't really need to know what's happening in the other scenes/groups.

If your question was aimed at how to collaborate in general (version control etc.) then I guess Ricardo's answer is the one you were looking for. ;) However you should be aware, that svn will only work correctly if you have pro licenses.

In addition to what spree and Ricardo said: You should also probably look into exporting and importing packages. That way, you can share assets between the different groups without even using source control. Obviously, setting up one project with source control is the most convenient approach - however, if the groups should be very independent (and having different minigames looks very much like that), each providing their own packages with scenes as spree suggested would probably work just fine.

And yes: If you set this up correctly, like each team using their own folders in the projects, with maybe one "shared" folder that each team uses (if that's even necessary), it should be very easy to test the scenes separately and then putting it all together in the end. You should do some planning and tiny "proof-of-concept"-projects, though, to get a feeling for how this is working in Unity.

The folder structure I would recommend is something like

• Assets/
• Assets/0MainMenu ("0" to always keep it on top)
• Assets/TeamA -> everything for the minigame of TeamA
• Assets/TeamB -> everything for the minigame of TeamB
• Assets/TeamC -> everything for the minigame of TeamC

Or, alternatively

• Assets/
• Assets/0MainMenu ("0" to always keep it on top)
• Assets/NameOfMiniGameA -> everything for the minigame of NameOfMiniGameA
• Assets/NameOfMiniGameB -> everything for the minigame of NameOfMiniGameB
• Assets/NameOfMiniGameC -> everything for the minigame of NameOfMiniGameC

Thinking about it, I actually believe that using packages with the right project structure would be the more appropriate approach for your project than setting up version control. The reason being that probably, each team should work completely independently and one aspect of the project seems to be "putting independently developed parts together".

For the workflow, ideally each minigame would run completely on its own (makes testing much simpler when you don't have to go through a main menu each time you want to play-test). However, for testing the interaction, the team that creates the "container" probably should send their package to the other teams frequently (so they can test both, directly starting only their scene and starting their scene from the container). And, they (the container team) could ask the minigame teams to send them their minigame-packages every now and then to do "integration testing" (testing whether the minigames work together when put into one main project that contains everything).

all great answers.

Thanks everyone.