Clearly Unity is the most important engine to support solely based on its success. Yet, it is not the only one, especially on the web. For example Mozilla recently released Aframe (based on threejs) which is specialized for WebVR content. Unfortunately despite having glTF support, physics support (via Cannon.js), multi-player supports (via firebase) and yet no persistent worlds. SpatialOS could properly fill that gap.
We are currently working on Unreal. The early access date for this is still not confirmed as we are currently focusing on improving the Unity workflow.
We also have language integrations for C#, C++ and Java. These are currently experimental but you can integrate your own engines if they are based on those languages. See these doc pages for more details for C++, Java and C# for more details. If you start using the language SDKs please let me know as these are really new and we want to get as much feedback as possible.
The UE4 community has grown exponentially since the engine went free in 2015. The size of Unity’s installed user base is due primarily, it appears, to the simple fact that it has been available to lower capitalized independent developers for a long time – it was, more or less, the only game in town… A huge number of independent commercial games are being developed today with UE4 and many Unity developers are moving to UE4.
I understand that it is prudent to finalize a product line, in this case the Unity SDK, but I do urge that all available resources be devoted to a UE4 SDK as soon as possible.
Both have different areas that they can and have to improve on. Recently UE4 has been gaining on Unity but we’ll have to see what Unity is going to do as a counter-strategy. Either way in the end it’s the users/developers who win.
I would contend that a prototype can be created in UE4 with blueprints much faster than one could be created in C# and anyone with any experience in any sort of programming can pick up blueprinting in a matter of hours. The single redeeming aspect of C++ is that it is faster than C#, but that is a game changing difference.
Blueprints in UE4 are still severely limited, a lot of the things accessible from code are not accessible from there. The Networking Blueprints API for example is very very basic. But as I said, yes UE4 is catching up and Unity will have to do something.
And in many cases the performance overhead that C# has doesn’t matter all that much because Game Engines are used for all kinds of things nowadays and in a lot of them that doesn’t change much. And with Unitys IL2CPP we’ll have to see how much all that even matters at all in the long run. If we want to hyper optimize everything we might as well all work with assembler code.
The biggest down-sides I personally see with Unity is that it’s not free with source access as UE4 is and that it uses a really outdated Mono version, which also restricts libraries you can load in to everything before .net 4.0.
I believe your characterization of the limits of UE4 blueprints as “severe” to be misleading and inaccurate. While blueprints do indeed lack direct access to certain engine features, a fully functional multiplayer game can be created with UE4 entirely in blueprints.
Our game, for example, is 99% blueprints currently.
Unreal is likewise developing a feature to convert blueprints to c++ that should see the light of day this year.
Having first investigated Unity, I can say without reservation that UE4 has a by far much easier learning curve.