Making Playroom Plugin for Unity
Here are a few options we considered:
Benefits: Native to Unity, somewhat performant, works on all platforms that Unity supports.
A Series-A CTO: "Let's just rewrite the whole thing in C#! Sure, it's a bit challenging - but hey, no pain, no gain, right? And just imagine the thrill of maintaining not one, but TWO separate codebases. Let's hire a team of C# developers and get started. We need to spend that VC money somehow."
Benefits: Works on all platforms that Unity supports.
By combining some native code for each platform, we could embed a WebView in Unity and load the Playroom client in it. This would be a lot easier than porting the entire codebase to C#. But it would still require us to write native code for each platform. We could have used a cross-platform WebView library like UniWebView (opens in a new tab) (if we had figured out licensing) or an open-source one like unity-webview (opens in a new tab).
After embedding a webview, we would write bindings for Unity to communicate with the webview. We would then show webview when the user is in lobby. When the user joins a room, we would hide the webview and show the game screen.
We actually prototyped and benchmarked this option for a bit. It works really well and the bridging is performant enough.
But we didn't go with this option for two reasons:
- The installation for the plugin would be a bit more complicated and flaky for the user.
- It would still be hard to maintain as embedding a browser just means native code for each platform.
We may still go with this option in the future but we wanted something more lean for now. So we decided to go with the next option.
Benefits: While only works for browser games, it's the easiest to maintain.
Enabling web games is our mission at Playroom. This integration was the easiest to implement. Unity WebGL has a way to interact with browser scripts (opens in a new tab) from C# code.
One caveat though: When developing locally, we found that it's difficult to rebuild the WebGL export in Unity every time we make a change and test. We decided to make a local mock API that works in the Unity editor, so that you can test your core game without multiplayer and then switch to the real API when you're ready to test multiplayer.
This was a good solution for a small team like ours. We could focus on the core game and not worry about maintaining a separate codebase for Unity. We could also focus on making the plugin easy to use and maintain.
Here is a quick demo of the plugin in action:
One benefit of current approach is that we can add-in other platform bindings as we go. Developers won't have to change their code since the Playroom API would remain unchanged. For example, we can add a Swift binding for iOS and a Java binding for Android while keeping the APi surface intact.
We can even silently go with approach #1 in the future without devs having to change their code. Who knows, maybe we'll have a gazillion dollars in funding and a team of .NET Certified developers.