How do you maintain multiple platforms at the same time?

Hi, As I stated in the title, how do you maintain the same project in multiple platforms? (iOS, Android, etc) What is the best practice in this?
1- Duplicate project for each platform and do platform specific things as you like.
2- Use the same project and share the same scripts by using #if UNITY_IPHONE, etc.
3- Something else?

So, I want to hear your practices in the subject. Thanks.

 

Use SVN, switch platform and make builds for both iOS and Android.


If it works on iOS and Android, you can ship it.

 

#2 is what I do with minibowling

 

I do a separate project after an experience losing an entire project while converting between ios/android. Or at least make a complete backup before switching....have had it eat my entire scripts folder as well.

 

@eskimojoe, are you using a specific SVN plug-in?

@lmbarns , that's terrible. Which version of Unity did that?

 

What I think you should do is have a master copy, this is the copy you work in, make updates. For the other platforms you want to have as little change as possible, because lets say you make an update in the IOS, then you would have to make the update in both versions. The lightmaps seem to get screwed up, the textures could get screwed up, a whole bunch of things could break when switching platforms. Some android plugins will screw up the IOS build and vice versa.

 

Also abstract as much as possible and reasonable. Anything that is platform specific, modularize so you don't have to change too much when you do need to update. For example game logic, that shouldn't be any different, keep that separate so it doesn't know or care about the build target.

 

Just use the TortoiseSVN. You really do not need any plug-in.

 

I use one project and a lot of clear directives, Application.platform calls and so forth - prefer to write once deploy to many. So far the only wall I've hit with this approach is that unity's input manager is insufficient but I'll be rewriting this at some point with a custom job.

It's pretty tricky in a team based environment having a lot of separate versions, even if by source control you manage to share the same scripts. You want to share them or bug fixing and changes get out of sync.

1 project benefits: works well within team, and any fixes, updates, changes are deployed across all the platforms in one go. It's the easiest way.

1 project issues: unity lags behind here in a few key areas: The input manager doesn't allow for per platform input options (its one set for all). And Application.platform (and the rest of unity) should allow custom defines.

 

I use #2 a lot i.e. In my PerformanceManager.IsSlowDevice, on iOS I have it check if its an iPhone4 / iPod4, on Android I check how many cores the device has.

@hippocoder, did you know you can do custom defines these days?

 

Custom defines! I'm feeling out of touch now. Thanks a lot Lukas, that's a help.

 

Wahhh! Since when!? I had no idea. That's super helpful dang. I used to code two separate projects for server/client. No longer .

 

Its a really new feature, 4.1.x something, and only 3 lines of text in the manual so don't blame yourself missing it

 

4.1.5.... I think part of it is the mac I was using though, it would freeze randomly 1x daily to the point I had to power off and on, but when it came back on the entire standard assets folder was simply gone and all the script associations were broken. My boss got me a new PC and haven't had the same problem since...

At work we build for android then port to ios after we have the finished android build (finished and sent to client)...then we backup, make new project and convert it to ios and get that build working.

I didn't realize you could use custom defines....will have to try that...mainly we work with android first for several reasons, we can't use Unity remote with the plugins we use and have to build->deploy to the device and it's time consuming to pass it into xcode every time we want to test a build, and we develop apps for other businesses and can simply send them builds throughout development without having to be in an app store.

 

Me too. The only issues I've had are 3rd party plugins which aren't well designed for multi-platform use. Unity itself is surprisingly nice in this regard.

Directives and Application.platform calls are pretty rare for me, as I've handled most things at design time. Where I do need them, I typically try to keep them to their own object (eg: the on-screen joystick for touch-only platforms) and have a component that enables/disables them based on platform.

I think it's been there for ages as an undocumented feature if you stick stuff in a file with a particular name. It's a pretty recent addition to the GUI, though, maybe 4.0 or 4.1?

 

You have iOS already. Simply purchase Unity3D for Android. Make a backup, switch platform and then make an Android build.

1. If you have UNITY_IPHONE you simple have to change:

#if UNITY_IPHONE

#if UNITY_IPHONE || UNITY_ANDROID


2. The same resizing aspect ratio code would work the same.


3. Use #if for platform specific codes, such as AppStore and Google Marktplace IAP purchases.


4. Use the same project and use the same scripts.


5. You need to buy a Samsung, Toshiba, Sony tablet, Samsung handphone, Sony XPeria phone. Try to buy the older ones if you use it just for testing purposes.

 

Well, you can maintain code/projects in seperate branches in your source control system of course.
Although it depends on the platforms too.

For instance for PC/Mac/Web/Metro, you may get away with a few #if tags in your code, and keep them all on the same branch.
For mobile though, you'll probably have a whole bunch of mobile specific assets, plugins and shaders in your project, that wouldn't be relevant to non-mobile builds, so you'll keep everything on a mobile branch.

Talking of branching, here is a great description of a branching model that you can use for all your development...
It refers to GIT though you could apply a similar model to any version control system.
http://nvie.com/posts/a-successful-git-branching-model/

 

Lots of useful information provided, thanks all. So, it seems using the same project across all platforms (at least for mobile) is the most common practice. Also we should remember to backup our project before switching platforms as it's somewhat risky.

@eskimojoe, thanks for the steps. I hate android platform just for the last one

 

I really advice some sort of versioning system, which also acts as your backup.

I'm a sole developer but versioning, in my case SVN, saved my butt several times. I once had an issue with MonoDevelop screwing up the undo and the code was just a total non compiling mess, luckily I could revert that script to the previous state. Another example would be Unity 4.1.2 and switching platform while a scene with NGUI was open. It would crash Unity.

So long story short, use a versioning system like SVN or GIT incombination with platform directives and optionally unity cache server and your golden

 

I'm surprised so many people still use SVN. May I ask why you're not using something newer like Git or Marcurial? Sticking with the familiar, or the "distributed" bit seems like an over-complication, or just haven't bothered?

 

Our next game will make sure everything that has different code for different platforms will receive the wrapper treatment, social media, file access, database, ui overlays, statistics, store, review my game etc etc etc.

The first game we made was wrapped a bit but not enough for an easy transition between iOS and Android so we wont be making that mistake again.

 

I mostly use #2, feature toggling. Google Drive and USB drives can be used to easily transfer between machines if you don't want to use SVN. This is for iOs/Android mind, so pretty similar systems. A PC port would probably require a separate branch.

 

It's hard enough getting artists to use SVN. When conflicts occur with Git it's harder for them to cope.

 

its offtopic but in my case its a combination of things: sticking with the fimiliar, I don't see the point in having distributed VC when I'm the only dev, I hear stories about git and mercurial being slow with large binary files which I have (like a movie in the streaming assets folder).

To be honest, if the AssetServer was a bit more decent I would have stuck with that

 

Our developers make 300 commits in one day. Our artists go haywire after that reviewing all the Syncs.


If you have a small team that makes hundreds of commits, GIT and HG will overwhelm them.

 

As a solo developer, should I set version control Mode to 'meta files' ? Or is it enough to version control only the scripts?

 

Yes.


Then you run a SVN server (either at your office or cloud-hosted). Version-control the /Assets, /Project folder. DO NOT version control the *.csproj, /Library and /Temp folder.

 

That sentence rings warning bells right there.
You should have all your work checked in to a remote repository. Use GitHub or BitBucket.
For source control GUI's, check out SmartGit for Git or TotoiseHg for BitBucket with the Mercurial option.

After each 'task' is completed, you should commit your work to the repository. So if something goes wrong or corrupts, you can immediately revert back to the last state your project was in. Making a 'backup' each time you want to change the project is not the right way to do things. If you switch platforms, and something corrupts, just revert to the most recent working version. As I mentioned earlier, if you now want a seperate platform that you think will be better off on it's own seperate branch, then create a new branch, called Android or whatever the platform.

But this business of 'backing up' is not only a waste of time it's unreliable and prone to errors.

 

How would you handle IPad? Is UNITY_IPHONE sufficient for both devices?

 

Version Control + Platform defines

 

You can use the iPhoneGeneration enumeration to detect if the client is an iPad.

But generally you would use UNITY_IPHONE for platform specific stuff.