I work at a University and plan on running a class on Unity iPad development this semester. We are just planning the project at the moment and I want to ensure what we are wanting is possible.
It will be a group project with around 15 small groups developing a single iPad app. 1 group would build the 'container' (intro, main interface etc) and the other groups would then develop content / mini-games that would be loaded into the container. Will it be easy enough for each group to test their games outside of the container and then merge them with the container for the final build?
Any insight into how best to approach this would be greatly appreciated.
thanks in advance
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.
answered Jul 15 '10 at 07:05 AM
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.
answered Jul 15 '10 at 07:11 AM
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
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).
answered Jul 15 '10 at 08:53 AM
all great answers.
answered Jul 16 '10 at 06:10 AM