I feel like, realistically, for a lot of the people that feel might be affected by this change they could probably do their games in an engine like Godot without much trouble.
Though as it says in the article, Godot does lack proper support for consoles.
> Though as it says in the article, Godot does lack proper support for consoles.
None of the open source engines do, or ever will as publishing to consoles requires that you sign an NDA. If you're a godot dev and want to publish on console look towards https://lonewolftechnology.com/
interesting, but I can't imagine someone battle-testing a proper unity scene porter that would be faster than simply re-importing your assets (easy?), re-writing game scripts (easy-ish, since Godot has c# support. but annoying and time consuming), and re-doing your shaders/materials (basically a complete re-write, unfortunately).
Assuming C# support is rolled out to all platforms soon, its still a massive undertaking to port over scripts from Unity's lifecycle and libraries to Godots. I assume shaders are actually much much easier to port in an automated way. But also many assets are custom to Unity, like their animation system.
Yeah, anyone who hasn’t had to rewrite and/or port will think it’s easy. Not knowing Unity has its own lifecycle for scripts and has its own APIs for doing things the “Unity” way. Want to create an instance of something? No, it’s not just new Thing()…
I say "easy" in a relative sense, since we're talking about leveraging the use of automation here (and we know how that ends: https://xkcd.com/1319/). And I'm assuming you have a decent engineer assisting in moving the scripts. they can learn the differences in the game loop and port over a lot of the high level scripts with a bit of thought. But not in a way that is easily automated.
And to be honest, I don't know how easy asset migration is (hence the question mark). it's a surprising pain point when moving from Unity to Unreal even if you keep everything as the industry standard FBX. I don't know if it "just works" in Godot or can be its own undertaking. Histoically it does mess up a lot of texturing and animations, even if you manage to get the base model in intact.
Yeah, even a seasoned engineer would take as long. The issue with porting C# code from Unity to <engine> is the different ABI. It’s like trying to port Win32 C++ code to MacOS with the minimal cocoa obj-c required. In the end, they are two completely separate ABIs that have to be targeted. There is no such MonoBehavior API in Godot. They have different lifecycle management APIs, so creating, destroying, and triggering code has different signatures and different calling conventions. You simply can’t transpile code from one engine to another simply because you’re using the same language.
There are commercial companies offering Godot-based games a path to consoles, so it isn't technical at all. It is entirely a matter of licensing with the console makers not wanting to allow open source support. But they don't mind 3rd parties developing proprietary extensions to support consoles and following their licensing restrictions.
mostly Political. Console dev kits from the Big Three are all under NDA, and you need to apply to get them. So we're talking about access to closed sourced code with use in an open source engine.
Godot created W4 Games to get around this. So while Godot is open source, W4 can work on a fork that implements console-specific code that cannot exist on an open source repo.
Though as it says in the article, Godot does lack proper support for consoles.