This isn’t about running Unity games in Docker, it’s about running the Unity editor in a container, for use in automated continuous integration processes.

exactly; anyone who doesn't see the use case hasn't built a business based around unity (not recommended btw!)

Unity is essential to my business and it's fucking great at it. Over the last two years it has increased it's utility exponentially increased the function and workflow is top notch. 3D application development is one of the most interdisciplinary things you can undertake, but Unity is rad as hell.

I feel the same. It’s easy to hate but it’s always a grass is greener between Unity, Unreal, or a custom engine. At the end of the day all three of those are valid choices in the right scenario, but Unity is certainly never a “bad” option.

I'd love to hear your thoughts on why you don't recommend that. Think I could learn.

There was a time when Unity was by far the best tech platform for building your game on. Then they took on a ton of VC money, grew very fast, and went after all forms of mobile, VR, and desktop development, at which point they morphed from the best platform for game development to the worst platform for enterprise development.

Speaking as a 10 year customer of Unity, I can’t wait for Three.js, gltf, and a couple other components to get just a bit more solid so I can drop my dependence on Unity. Three or four years ago it would have been inconceivable for me to say something like that, as I was a long term hardcore fanboy.

It’s just not the same company or solid development experience it once was.

Speaking of Three.js, have you heard of PlayCanvas (https://playcanvas.com)? It's pretty much a Unity-like IDE based on Three.js, and allows a whole bunch of cool features, like live collaboration.

Here's an example game made in it: Tanx, https://tanx.io. And here's a lightmap-heavy scene for eye candy: https://playcanv.as/p/txPePQvy/

It looks good, but on my Macbook Air I get really bad framerates (<10 FPS). I'm not sure if that's because of this tool, or WebGL itself, but I'm able to play Unity games like Cities: Skylines without any issues.

I see, I also look forward to Three.js / WebGL stack to become a suitable replacement. These are exciting times.

For that WebGL needs to be able to offer the same feature set as native 3D APIs, which will never happen due to security and the new direction of graphics programming.

It only a suitable replacement for those not requiring more than what OpenGL ES 3.0 offers.

> For that WebGL needs to be able to offer the same feature set as native 3D APIs, which will never happen due to security and the new direction of graphics programming.

I work with many of the people involved in the Web GPU effort, and I'm sure they'd be surprised to hear that they aren't actually working on what they're working on!

This is just silly.

Silly is pretending WebGL will ever match 1:1 the capabilities of native graphics APIs.

It is absolutely a goal to match Vulkan/D3D12/Metal with the new Web GPU efforts.

If you're talking about matching every single feature in every API ever, of course no API can do that; no "native" API does that either. There are always gaps around the edges where some API has features others don't (e.g. conservative rasterization support is spotty). But general feature parity with the new generation of APIs is the target. I'm going to the W3C Web GPU meeting next week to talk about just that…

I like WebGL, just don't like having it lacking features like geometry and compute shaders, or having to manually white list the GPUs on devices where native applications execute without problems.

Looking forward to the outcome of W3C Web GPU meeting.

That is only worthwile if your games don't require anything more than OpenGL ES 2.0, or eventually OpenGL ES 3.0.

i'm primarily a programmer not designer nor game dev - so a priori an ide that store program state in the ui is weird (e.g. fiddling with booleans by either checking boxes or setting procedurally). but that's fine - you just get used to your state being spaghetti. the real problem with unity is it's closed source and all of its goofy bugs and breakneck release cycle make for really nerve wracking times. maybe the real thing is you shouldn't build your software business around a closed source vendor.

I made this CLI installer for Unity that will install any semantic version range for OS X (hard coding URL not necessary): https://github.com/zettaforge/unity-installer

I would accept pull requests for Linux and Windows package support.

You can also avoid hard coding any install paths using unity-path: https://github.com/zettaforge/unity-path

I would accept PRs there too to professionalise documentation (emotional appeal was an experiment that brutally failed) or help with marketing.

Both these tools could be useful for customisation of this Docker image. They are thoroughly tested with full coverage :)

That's pretty cool actually. I knew you can run VNC in Docker container but I never managed to do it :)

I adapted this to run Godot Engine: https://github.com/TeddyDD/godot-docker-vnc It's not useful I think since Godot has headless server you can use for CI but it was fun anyway.

What are some use-cases for this sort of thing...?

Unity is extremely useful for all sorts of things outside of and gaming adjacent. Compiling 3d assets, spatial calculation, audio processing, procedural tasks, physics and material modeling, GIS/Architectural/Structural simulation.

I have a containerized set of headless unity processes that take a map selection from a variety of public and private sources plus user data and compile it into a detailed modeled environments to be later served in WebGL, mobile, desktop, and 3D printed. Doing it in the users client would involve a lot of memory management and storage on sometimes restrictive devices, also unity can hand things off to numpy/scipy, ffmpeg, etc easier on my server than it can your phone or desktop.

There is also a huge push from Nvidia[1] specifically and others to build new tools for remote GPU use taking the load off of thinner and thinner clients doing more and more things. OSX High Sierra offers remote GPU usage in Metal2. Connecting all these vector processors will frequently be for data ETL, but rendering that data is going to fall onto tools like Unity a lot, which will also be sharing in the role of assembly and iteration.

With the new new embedded machine learning chipsets in every new gizmo, tools like Unity and Unreal are about to be ubiquitous doing all sorts of heavy lifting. There isn't quite a written playbook for what's going on, but it's pretty crazy and exciting. Almost like it was 1996 internet again.

[1] https://devblogs.nvidia.com/parallelforall/goai-open-gpu-acc...

You should write a blog post! It's an awesome reply.

Thanks! I've been working on a series. We are about to go live and start pushing out my devlog content too. We've had to be sort of protective about some of it to make sure important launch IP is protected, but soon! And thank you for the compliment, I've been sneakily building up my blog chops with anonymous Reddit and HN posts. It seems to be working!

my man :)

Imagine spinning up 1000 instances of your game through Kubernetes and running automated end-to-end tests, with automated inputs and screenshot capture.

Well for that you would probably just spin up containers running your game itself, not unity. This is more for building the game on like a CI I would think.

Perhaps. I'm not very familiar with Unity and the development kit itself, but I would imagine it contains the necessary testing harness and other infrastructure.

I'm using it in very specific [undisclosed yet] scenario where Unity needs to do something, and that needs to scale.

Much of the process is explained in this post https://medium.com/@tonywangcn/how-to-build-docker-cluster-w...

Testing your project I guess - meaning custom editor tools, importers/exporters, assets. Also game script tests other than end-to-end ones.

Not sure of the full capabilities of this but perhaps spawning game clients to test out your multiplayer server?

Should `rm` the downloaded package after here to save space:

https://github.com/nenadg/docker-unity3d/blob/master/Dockerf...

it's already solved @ https://github.com/nenadg/docker-unity3d/commit/b7e4bc702fdf...

Having just done this for my company, this is awesome. I probably won't move to using this for the time being, but there are a lot of pitfalls to doing this, many of them subtle.

We use Unity3D + Docker for CI and automated builds, which has massively decreased the number of "builds on my machine" issues (which Unity3d is very prone to)

Hmm interesting, would a good use-case be deploying a scalable fleet of multiplayer servers?

You wouldn't want the full Unity editor for that use... you'd make an executable build of your game in server configuration and build a docker container of that.

Sorry that's what I meant.

Well that would be nobrainer with something like: `docker-compose scale unity=n` where n = 1...n

*You will only have to assign pool of ip addresses for your services, since it's fixed in this example.

Reference: https://medium.com/@tonywangcn/how-to-build-docker-cluster-w...

Easier and cheaper to run your MP code as a plain old .NET process and client lib.

You are assuming you can divorce your authoritative server logic from Unity.

You can I believe - your server will end up being a standalone binary with all the necessary Unity things bundled in.

I believe the parent means writing your game logic in pure C# and avoiding the need for Unity entirely server side. For some types of games that’s doable, but when you start needing physics or nav agents or even animation driven logic a headless Unity binary is the only real option.

Or you could use nodejs & socket.io for the MP server which is even cheaper

Not sure how it's cheaper cost-wise, since the .NET runtime is free, but his solution avoids a re-write of game code in JS.

Real-time 3D graphics over VNC sounds painful.

Automated testing of video games is less painful than manual testing though.

Probably not what OP is doing, but there are way better ways to do that than VNC. You can adaptively stream gaming pretty effectively over any network especially a local wired one.

I wonder if Steam Home Streaming works for the Unity editor? It's a popular and accessible option.

You can literally dump frames out of a headless copy of a game into FFMPEG and transcode it into an adaptive stream.

I haven't tried this specific thing with video games needing live input, but you can run headless on AWS GPUs and dump those frames to an AWS Lambda process[1] to do the conversion and only have to manage the input. In this situation the only thing you are running is the game and not all the other bullshit that an operating system has to deal with in a remote desktop situation. All you would have to manage is the sync from the controller over a socket.

Another nice feature would be being able to save your gameplay and maybe edit it later for broadcast if you wanted.

[1] https://github.com/binoculars/aws-lambda-ffmpeg

It works for the whole desktop, so yes.

Seems like we do have an UE4 container. https://hub.docker.com/r/wshearn/ue4editor/