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.
Seems to me like they point out the issues starting at 0:55, and that it’s clear those issues are not because of their game or development in general. That the editor was increasingly adding friction on top of concerns they were already ignoring.
I would say they probably should’ve tried the Godot 4.X (or 3.X) Rust bindings before switching over to Bevy (especially if they could try something else with data structure, potentially something from the assetlib… Nodot is a thing but I’m not sure if it’s what they want).
I would also say that 4.X does have some improvements to 2D (here’s an animated eye I did with a feature new to 4.X, also scene tilemaps allow in-engine polygonal art there too), plus just because they’re making a 2D game does not mean they never want to do anything with 3D. (I mean sticking for 3.X for 2D certainly could be a thing, but it may add confusion if they need to switch over to 4.X for 3D)
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.
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.
Seems to me like they point out the issues starting at 0:55, and that it’s clear those issues are not because of their game or development in general. That the editor was increasingly adding friction on top of concerns they were already ignoring.
I would say they probably should’ve tried the Godot 4.X (or 3.X) Rust bindings before switching over to Bevy (especially if they could try something else with data structure, potentially something from the assetlib… Nodot is a thing but I’m not sure if it’s what they want).
I would also say that 4.X does have some improvements to 2D (here’s an animated eye I did with a feature new to 4.X, also scene tilemaps allow in-engine polygonal art there too), plus just because they’re making a 2D game does not mean they never want to do anything with 3D. (I mean sticking for 3.X for 2D certainly could be a thing, but it may add confusion if they need to switch over to 4.X for 3D)
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.
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.
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.