Switching Game Engines... Twice? - Devlog #7
www.youtube.com
In the last 6 months I have remade my movement-based roguelike game, originally made in Unity, twice in two different game engines.0:00 Intro0:21 Unity2:40 A...

A devlog on switching from Unity to Godot and then to Bevy.

  • MJBrune@beehaw.orgEnglish
    2·
    1 year ago

    Every game engine that I have used (Godot, Unreal, Unity) has a bloated or buggy editor. It’s inevitable. They complain about closed source but then when they hit the issue in Godot it doesn’t seem like they utilize the open source nature. If they are just going to wait for fixes then the openness of the source truly doesn’t matter. Lastly for 2D or 3D, I see more reason to switch to Godot 4.x over Godot 3.x if you are using 3D. For 2D there are still features but it’s not like everything is busted or missing key features like 3D was in 3.x. There is a reason 3.x is still LTS and 4.x isn’t. For hobbyists willing to put up with bugs, 4.x is fine. For professional studios and those not willing or able to deal with all the bugs that 4.x brought, waiting until 4.2 or 4.3 would be ideal.

    • insomniac_lemon@kbin.social
      1·
      1 year ago

      Every game engine that I have used (Godot, Unreal, Unity) has a bloated or buggy editor. It’s inevitable

      From a user perspective, bloated generally means it’s sluggish to open and/or run. Never tried Unity, but I tried Unreal a while ago and on my old machine it was almost a minute (on an SSD I bought specifically to try Unreal!) to open up the project launcher and then even more time to open up a basic project. Godot by comparison is instant. Similarly it was a 100GB+ compile whereas Godot is significantly lighter even with 4.X.

      They complain about closed source but then when they hit the issue in Godot it doesn’t seem like they utilize the open source nature

      I mean yeah… though open source can sometimes mean looking at the code or even the ability to test/give feedback on PRs. If someone doesn’t know C++ and can’t fix every issue I wouldn’t say it’s a failure.

      For 3.X vs 4.X you’re absolutely right, but I see it as more of a guarantee for existing 3.X projects or even existing users. If someone’s starting completely fresh I don’t really blame them for wanting to start with the current/future workflow. And FWIW the showstopper they encountered seems to be specific to C#, thus one reason why I mentioned the bindings (especially as they switched languages anyway).

      For most people I think the features will outweigh the downsides, especially being good enough that one can hold out for workflow/release improvements. Though even 4.2/4.3 might not be perfect, especially with a faster release schedule. Some people might want to stick to 3.X even then, but I think it depends on the user.