____________________________________
Unreal 4 - (https://www.unrealengine.com/) Godot - (https://godotengine.org) Lumberyard - (https://aws.amazon.com/lumberyard/) Source 2 - ...____________________________________
A bit of background - in the old days the concept of 'engine-jump' was a real commitment and a huge deal. They were all so different and required very specific workflow for both the code and art pipeline. The idea of creating a project that would be deployed (to whatever degree) to multiple engines at once was just unthinkable.
These days it's a bit easier, due to the nature of universally functional standards such as Collada (from Blender), PBR materials and scripting languages like Python and LUA. Together with our 'art-centric' workflow that is mostly text-based and transformable/translatable, instead of committing and "jumping" to an engine, the concept is now "branching out" and not just to one engine, but like a curious octopus with each tentacle in a different candy jar. Yes, it's not the easiest and fastest thing to do, but it's a lot easier than it used to be especially because of our ability to do powerful data-management using GAWK/Regex to completely translate information between text formats and standards like Collada, and that almost all of our tools use text-based formats that are able to be translated. The flexibility we gain from being able to deploy complex environments full of art that can really stress-test each engine with actual use-case scenarios is something that really should have always been done from the beginning of any serious project, but this has always been a contradiction - how can a developer be expected to create entire worlds full of content before even deciding which engine to deploy to, yet how can a developer know the engine is reliable and can actually handle it without feeding it such content? This is the problem we had with NeoAxis and will never make the same mistake again. It really had no proven track record and we relied so heavily on the author of the engine to fix fundamental issues (mostly related to performance) instead of bulldozing ahead and just throwing new toys on top. The very presumption that we could just rely on these issues being fixed in later releases was a mistake, as logical and reasonable it seems to have believed that, the lesson to learn is this - if it doesn't already exist and already work, never rely on it.
So far, Unreal is ahead in terms of proven track record, but I'm going to spend quality time researching each candidate and then asking questions in their communities. I'd like to get a few more on the list, but notable omission is Unity, for various reasons, I want to stay away from it.
.
.
.