You can run Unity in a serverless function-as-a-service (FaaS), with graphics, in less than 70 lines of code! Full demo code is on github. I think this is useful to game developers and robotics researchers alike.



But why? FaaS spin up resources to execute them per execution. It completely eliminates idle serves saving money. It’s stateless, it’s simple to use, and it scales massively when you have traffic bursts or bulk operations, yet scales to zero (i.e. free) when you have no usage!



We managed to get a stack working which we use to generate thumbnails for our game. Unity is a pain to get working in a Docker, so instead we used Node.js and off-the-shelf browser automation. To do this we used a few tricks:

Unity builds can be compiled to Web Assembly (Wasm) and WebGL, which can be hosted in a Cloud storage bucket as a website.

Inside a function you can pilot an automated Chrome session using using Puppeteer.

Chrome ships with a WebGL software rendered called swift shader, so you can take live screenshots.

So, putting it all together, you run Chrome in a function, which navigates to a webpage that hosts the Unity WebGL build and runs it. At this point you have your game running in a function!

You can you pass data in and out of the running game by reading the Unity log via the Chrome console and reading the URL parameters from within Unity.

Whilst this was useful for us to keep the Unity build as the source of truth for game development, I think this approach could also be useful for machine learning training simulations too. The development ergonomics are very nice, as you can navigate to the webpage using Chrome to experience what the function sees, and development of the simulation is done in a commercial tool designed for this very purpose (Unity). This, hands down, beats using academic tooling. Furthermore, it scales horizontally when you need it (e.g. a massively parallel training batch), and costs nothing when idle!