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.
Yeah, it’s either bloated or buggy. Godot’s editor isn’t bloated but I’ve had a lot of issues with some basic QoL features. Drag and Drop, copying nodes from different projects, etc. Overall Godot’s editor is fast but broken or missing things. Unreal itself takes a moment to start but once you are in it, it speeds you up a ton. They have tons of QoL features, with stability, and it takes me under 45 seconds to open it on a large project. Godot is under 5 seconds. Compiling Godot takes a surprisingly long time for what it is. Unreal takes longer to compile but there is far more of it. I suspect one reason is that a lot more people compile Unreal than Godot and Epic has put tons of effort into their C++ environment. Godot on the other hand has put a lot of time into their gdscript instead.
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.
I would say the open-source-ness of the code starts to matter less. The only way it does matter is that they could, if they had the resources, pay someone to fix it for them. I wouldn’t use a game engine that didn’t provide the source code to me but I also wouldn’t hesitate to jump in and mess stuff up. If they know C# they probably could at least figure enough out to do some changes.
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.
Absolutely but I just don’t get them switching without even trying anything to solve their problem in Godot. They could have switched to 3.5 or like you said, switched bindings, or anything else. It feels like they jumped into Godot, started porting their game, hit an issue, and bailed to Bevy.
That said I think they’ll find Bevy to slow them down in the long run. Bevy is great and will likely be a contender to make games someday. Just not today. Most of the games industry doesn’t even see Godot as production-ready, much less know of Bevy. I half-agree them. Godot isn’t an engine I would stake a multi-employee studio on. Bevy far less so.
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.
Yeah, it’s either bloated or buggy. Godot’s editor isn’t bloated but I’ve had a lot of issues with some basic QoL features. Drag and Drop, copying nodes from different projects, etc. Overall Godot’s editor is fast but broken or missing things. Unreal itself takes a moment to start but once you are in it, it speeds you up a ton. They have tons of QoL features, with stability, and it takes me under 45 seconds to open it on a large project. Godot is under 5 seconds. Compiling Godot takes a surprisingly long time for what it is. Unreal takes longer to compile but there is far more of it. I suspect one reason is that a lot more people compile Unreal than Godot and Epic has put tons of effort into their C++ environment. Godot on the other hand has put a lot of time into their gdscript instead.
I would say the open-source-ness of the code starts to matter less. The only way it does matter is that they could, if they had the resources, pay someone to fix it for them. I wouldn’t use a game engine that didn’t provide the source code to me but I also wouldn’t hesitate to jump in and mess stuff up. If they know C# they probably could at least figure enough out to do some changes.
Absolutely but I just don’t get them switching without even trying anything to solve their problem in Godot. They could have switched to 3.5 or like you said, switched bindings, or anything else. It feels like they jumped into Godot, started porting their game, hit an issue, and bailed to Bevy.
That said I think they’ll find Bevy to slow them down in the long run. Bevy is great and will likely be a contender to make games someday. Just not today. Most of the games industry doesn’t even see Godot as production-ready, much less know of Bevy. I half-agree them. Godot isn’t an engine I would stake a multi-employee studio on. Bevy far less so.