I tried to get a single Unity project to build for multiple platforms over the weekend. The code I’m writing is probably best suited to a flat screen with mouse and keyboard quite honestly. That said, I’m interested in working with VR systems and thus intend it to run on the platforms that I have available. This gives me:
- Flat screen with keyboard and mouse.
- Google Daydream VR with Daydream controller.
- HTC Vive with two Vive controllers
- Possible Google cardboard with no controller (perhaps a game controller as a stretch?).
Multiple Platforms from One Project
Sam had run across a couple of projects that claimed to work across platforms last week and sent me a link. Over the weekend I pulled the projects down and ran them on the Daydream without problems. They were a bit awkward to use as neither of them used the daydream controller effectively (one seemed to be built as a cardboard app, using the sight axis for selection).
I took the project that had been targeted on the Daydream and re-targeted it to the PC with a Vive headset attached. I got errors (don’t have the exact form) that suggested that I needed to load the Steam VR SDK in order to make things work. In the end I loaded the SDK from the asset store. This did allow the Vive headset to connect but did not display the information panels that the project was designed to show. At that point I shelved the project…I’ll probably return at some point to look deeper into the implementation, but for now I’ve had enough.
Switching Platforms in a Project (the hard way)
Later in the weekend I tried simply creating a project with a few simple assets and adding in the two SDKs. I was able to get the Daydream up and running (tried that first) by making the usual additions to the scene for that SDK and setting up the platform. To get the Vive running I had to delete all of the Daydream items from the scene and add in the usual Vive content. That too worked as expected.
The surprise came when I switched back to Daydream again. I continued to get errors indicating that the Vive input mapper json file was missing. It appears that something Vive related was still attached to the project and looking for Vive specific assets. This is another area where I may dig deeper at some point. For the moment I’m moving on.
Modular and Layered
I did dig through a good bit of content over the weekend (both video and online blogs/documentation) that suggested Unity supports external code assemblies linked in. This leads me down the road to a more modular approach.
- Provide multiple .NET core assemblies that aren’t Unity specific code to implement the ‘business logic’ of the game. This keeps the complex code (game rules, world generation and storage) and other such items in a place where they can be unit tested and managed as pure code assemblies.
- Manage all Unity assets that aren’t target specific in free-standing packages that get bolted into a target specific frame at the last moment.
- Build the SDK specific parts of the game as thin wrappers over these other assets. These will be asset packages and projects that contain only target specific items and user facing elements.
I’m going to head down this road next and try structuring a new version of my Cluster game to support this approach. I started coding up the game generation part on Sunday and will likely try bolting a version of that into a VR frame as soon as it is complete enough to be usable.