4 ms·

Rewriting shaders, MonoBehaviors, animations, triggers, levels, and systems? Yeah, not too much trouble.

jayd16 3y ago
I think they mean for future games. Ports will be pretty brutal unless the outrage remains high and someone makes some kind of porting toolkit.
- johnnyanmac 3y ago
  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).
  - jayd16 3y ago
    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.
    - gabereiser 3y ago
      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()…
      - 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.

I think they mean for future games. Ports will be pretty brutal unless the outrage remains high and someone makes some kind of porting toolkit.

johnnyanmac 3y ago
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).
- jayd16 3y ago
  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.
  - gabereiser 3y ago
    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()…
    - 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.