4 ms·

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 thin

• johnnyanmac 3y ago
  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/ 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.
  • gabereiser 3y ago
    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.