I am working on a mobile game that I eventually want to be on both iOS and Android. I use my Windows PC as my main workstation as it has all of the content creation software on there, and I also have a Mac Mini exclusively to run Unity and export to iOS.
Iāve found that simply coping across the project folder from the PC and opening it on the Mac results in all kinds of things going wrong, really poor editor performance and refusing to build at all being the main things.
In past projects my workflow has been to produce the project for Android on my PC, then make a brand new project on the Mac, import any plugin packages (ie Playmaker etc) then export individual scenes from the PC project as packages and bring them into the clean Mac project. It has been then a case of rebuilding the framework of the project again on the Mac.
This previous workflow got me a clean and stable game on iOS, but as you can imagine itās far from an ideal solution. My current project is considerably more complex and the thought of this ārebuildā workflow fills me with dread.
I know there has been several posts on this but I havenāt been able to find an elegant solution. I have seen in other posts people mentioning SVN VCS. For a 1 man dev with zero experience in this sort of thing it just sounds like another terrifying minefield to cross. Maybe someone may be kind enough to explain this in laymanās terms?
My only other option Iām thinking is switching to the Mac platform and rebuilding sooner rather than later, before the project gets any more complex but it should mean I can painlessly export to both platforms from the Mac? It will mean copying files across every time I update something but it may be better than a soul crushing total rebuild at the end.
What do you think dudes? Surely there is a more streamlined way of doing this? Is building from a Mac to both iOS and Android as painless as Unityās marketing would make out?
Well, PC and Mac use exactly the same project folder format. You typically only want the Asset folder and a few other files. Copying across the whole Library folder sounds like it might be messing with you. See:
which describes the files you should care about. Note also that Mac file system doesnāt care if something is called bob.cs or Bob.cs. Itās case insensitive. This can cause subtle problems.
Maybe Thursday the 10th of April 2014 is a good day to learn how source code revision software works? Thereās never going to be a better day than today.
Except yesterday. Yesterday is ALWAYS a better day to learn that
A simple Git setup (local, local server, free Bitbucket, your own remote server - anything, really!) will help even the single developer case. There are assets to help you use various version control systems too, but Iād say get one for Git and never bother with the others. SourceTree is a decent tool to use outside of Unity, should you need to manage a repository that way.
Ok cool, so it would seem this version control would be the way to go then? Iāll look into it.
However all of these technical terms are really meaningless with my current level of understanding!
It would be great if someone could give me a really simple overview explanation of what this revision software does, how it works and how it is beneficial to the Unity user.
You submit (ācheck inā) files to it, and previous files are stored in chronological order with some sort of marker to indicate a version in the system. If you made a huge mistake it lets you get back any previous version. The default checkout gives you the most recent file. You can also inspect differences between any two text files.
Most systems support a global version tag so that you can mark a collection of versioned files as one program version. After going through a few betas you can mark the current stable version as ā1.0.0ā for release, or perhaps you prefer words, so you could tag all the files āsmurfā. Whatever floats your boat.
It gets complicated when several people use one repository of files, but most systems also have ways to sort out simultaneous submissions of the same file. If there is a file conflict you may be able to inspect the differences and pick the bits/whole files to keep. Graphical clients make this much easier to do.
Some systems even let files be locked, but many consider this a bad practice. Git and Mercurial are set up to just let you get any file, then have an admin sort out conflicts.
You follow the link Graham posted about which files are required, and only check those in. Then youāll get it right every time automatically, rather than having to manually pick and choose every darn time you copy it back and forth
Also, youāre not screwed when you make changes you shouldnāt have.
