Crossplatform Windows and Android: How to share same codebase?

Hello everyone,

we’re developing a GUI in Unity which shall be deployed on Windows and Android. Currently there’s only 1 scene. We need to have the same scripts for both versions, including input control and so on. We’re changing the behaviour on input or serial port communication via defines at the moment.

The problem is the different layout. We need a different project - or at least scene - for the Android version compared to Windows version. It’s only one developer (me), so there’s no team for testing stuff forth and back. I would work on Android version for let’s say 2 weeks and then go back to Windows version. All improvements and changes should apply to the other version with very small effort.

Is there any possibilty to do that quickly? My idea by now is to have just 2 different scenes for the layouts and then use the “Advanced Builder” asset:

for compilation. I have to deploy the compiled “game” on Android each time for testing anyway, as the performance and the bluetooth communication play the main role, not the touch input.

Hi there,

firstly, I’m (again) a bit disappointed that Unity seems to ignore their own forum completely and never provide answers to these commonly asked questions.
Anyway, I wanted to update for anyone who might be interested.

What happened in the last months was that we were working on the standalone version alone, so no cross platform switching. As it became important recently, our solution will probably be to use the genius technique from this blog:
http://blog.deozaan.com/2014/09/22/fast-platform-switching-in-unity-made-easier/

With the difference that we won’t keep all our assets as a junction, but our codebase. This basically even avoids the synching process and just shares the exact codebase in two different projects.

Hi @emthele,

You should be able to use the same scene on both Android and Windows. Of course switching between the builds allows you to see the layout in the Game setting with out compiling. It’s important that you make prefabs of everything. That way any changes you make are automatically updated across scenes/platforms.

As for the scripting side, ‘defines’ are the way to go.
The easiest is the create defines that call your separate communication classes or functions. You might also want to look at some of the tools out there that can handle input for you (you can also define your own input). If you have time, check out Rewired Input Manager. If you can have your input to work with their system, it greatly simplifies things - especially if you want to go to iOS, Apple TV, etc… in the future.

PS: I had another question for you on ‘Quaternion from IMU sensor to GameObject Orientation problem’, but I couldn’t respond because it was closed. Mind if I ask you an additional question?

  • Blaine

Something that i had in mind is to make different UI versions as prefab and load them depending on platform you building. But it’s not enough, it will required some adapter architeture to abstract the input of the platform in question to the base game functions. I made some tests and just was needed some scripts to hack canvas aligments and some components fit to their relative position.