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.
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.
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.
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.
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.
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.
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!
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.
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.
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!
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.
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.
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'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.
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.
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)
Is there any UE4 docker container? I would like to use UE4 instead, Unity3D is a horrible choice for a game engine. Maybe it is good for enthusiasts and hobbyists, but it is definitely not good for us pros
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.
52 comments
[ 9.5 ms ] story [ 1629 ms ] thread*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...
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
Much of the process is explained in this post https://medium.com/@tonywangcn/how-to-build-docker-cluster-w...
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...
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.
It only a suitable replacement for those not requiring more than what OpenGL ES 3.0 offers.
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.
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…
Looking forward to the outcome of W3C Web GPU meeting.
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/
https://github.com/nenadg/docker-unity3d/blob/master/Dockerf...
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)
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 :)
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.