Develop locally, deploy globally

Indie Gameleon is over, so it’s time to get a bit more technically again.

Programming resources are rare in most projects, so it’s important to work as effective as possible. The most time wasting things are compiling and, if you are developing for another platform than PC/Mac, deploying the game to your device to test it there. This post is about saving time by deploying as little times as possible.

To test our game we need at least an engine that allows to deploy our game on our development platform as well as on our target platform.

Most likely you already fulfilled the basic requirement by using Unity. In multiplayer games you have to run a local server as well.

Mapping input

Now you have to make sure that your game stays compatible with several platforms. This means for example to allow multiple input methods. For mobile games you need touch input while for PC the mouse and keyboard act as the input devices.

You can achieve this independence by separating the physical input from your game input. For example you don’t send the command “Space pressed” to your game, but instead catching the space press in your input manager and forwarding a “Fire weapon” command to your game.

This should be done no matter if you are developing for multiple platforms or just for a single one. It allows to support different input schemes for your game and to change them without touching (and possibly breaking) your game logic.

Using and creating 3rd party plugins

This kind of separation is also supported by many 3rd party plugins, e.g. FingerGestures for the input or OpenIAB as an payment solution. If they want to support different platforms (Android, iOS, Windows Phone,…), they have to abstract the functionality from the platform specific implementation. This can make your local development really easy. Or a bit labor-intensive at first.

Google Play Games Services: A concrete example

One of my main tasks in the sprint of our current project was to allow the user to connect his game with Google Plus, so he could play on multiple devices and his progress is safe even if he deletes the game from his device. Therefore I had to login to Google on the client and send the credentials to the server to validate them there and connect the Google account to the game account.

To do this for a Unity game, Google fortunately offers a Plugin for Unity to easily authenticate with Google. Unfortunately though this plugin only offers a very unfunctional implementation to run in the Unity editor. This implementation will only log the functions called in the implementation to the Unity console.

This doesn’t allow us of course to test any functionality we have to test locally, but only on the device itself. Which would be very time consuming. Even if you think your feature is done and should work immediately, there are most of the time a handful of little things that break on first try, so you have to do multiple deployments.

If there were multiple plugins to provide the functionality I need, I would probably try a different one at this time. But for Google Play Services it’s probably best to go with the official implementation. So before working on the feature itself I bit the bullet and added my own implementation for the editor.

First iteration: Sending what we need

The first attempt was to set the token we need on the server hard coded in the editor client and returning it when the client was asked to authenticate with Google. There is a developer service called OAuth Playground where you can generate such tokens.

This way I could already develop the server-side of the connect feature with the correct implementation to validate the token sent by the client. But the token is only valid for a limited duration, so it would have to be changed regularly (every hour to be accurate). This is not really optimal for the further development.

Second iteration: Asking the user for his credentials

The optimal implementation on editor side would be to ask the user for his Google credentials. So it works the same way in the editor as it does on the device.

Unfortunately (the second time) there wasn’t even a method to call the authentication endpoint for the Google service in the editor. Writing an own one should be possible as it’s just an HTTP service where you send your credentials and get your tokens back.

But I decided that in this case it’s not really worth it and it would be enough to have a way to insert the token you got from the OAuth Playground manually instead of having it hard-coded inside your code.

Google Play Games for Unity Editor
Google Play Games Client for Unity Editor

So every time the player tries to authenticate with Google, an editor window opens to allow the user to enter his ID token. This allowed me to test almost every use case inside the editor:

  • Connecting a game with Google for the first time
  • Connecting with a Google account that’s already connected to a different game
  • Connecting to a game that is already owned by a different Google account
  • Sending wrong/expired tokens

Implementation

If you are using the Google Play Services in your game as well, here is my implementation for the Unity editor:

If you extended it (maybe to allow the user to enter his real Google credentials), feel free to send me an updated version 🙂

An appeal to asset developers

If you are developer of assets that other developers use, try to develop them in a way that saves your comrades as much time as possible. This is the reason for using 3rd party assets anyway, so make sure to consider the deployment time as well.

It’s not really required that you build a fancy UI in the editor. Most of the time a really quick editor UI or even some inspector functionality will do just fine. The closer your editor implementation is to the device one the better though.

Conclusion

Deployment time is one of the big time wasters when it comes to developing for a mobile or console platform. So every minute you invest to create tools that allow to test on your development platform instead of your target platform may save you hours later on.

Unity already solves a lot of cross-platform issues (aside from some catches you discover quickly). So make sure your game-specific code works on your development platform as well.

If you are using third party assets you may be lucky that the developers already considered your needs as a cross-platform developer. If not it may make sense to add an editor implementation yourself instead of having to test your feature on the device solely.