51–60 of 195 posts
>Mixing fast and slow APIs as discussed above would leave us with headaches for decades
Meh. Unity has allocating and "NonAlloc" methods, even on the raycast API in question here. It's a really minor issue.
Sounds like Godot will need more time to bake before its perfect but we already knew that.
Curious if anyone here has tried Bevy (Rust game engine). Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features). Another post in this thread said the C++/native interface was not great and difficult to work with. And…
This matches up with what I've heard from people with experience in both Unity and Godot. As convenient as it would be if Godot was ready to swap in for Unity, it's got some significant issues that would make that difficult to unfeasible for many people.
Funny that they have to use a custom dictionary setup when C# supports dynamic types. >Mixing fast and slow APIs as discussed above would leave us with headaches for decades Meh. Unity has allocating and "NonAlloc" methods, even on the raycast API in question here. It's a really minor issue. Sounds like Godot will need more time to bake before its perfect but we already knew that.
> That’s right, our raycast is returning an untyped dictionary. This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?
Presumably because GDScript doesn't support structs.
So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for G…
Unreal seems to have the most features and the steepest learning curve.
Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains.
Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many features as the other two and the commitment to GDscript seems... odd.
If I were picking a game engine today, it'd be between Unreal and Godot, but I'm not sure I'd feel great about either choice.
Earlier quoted context omitted.
I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.
If you use C# then you can use Visual Studio or Rider or VSCode and get that
That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forums for over a year. (He used to be quite active on Unity's forums.) The entire leadership of the ECS/DOTS team has resigned.
I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.