|
There's a lot of interest in #GodotEngine today, so here's my perspective & advice, as the tech lead on Cassette Beasts, a 2.5D open world RPG that shipped this year on Steam, Switch and Xbox, using Godot 3.5. 🧵 First: I've not used Unity (or Unreal) for more than just trivial experiments, so I can't provide direct comparisons. But there are still a few general points I can make. Also: I will never recommend switching engine mid-project. If you're gonna switch, do it between projects. 10 comments
Of course, nothing is perfect. There are bugs and performance issues, but these also exist in Unity so that's nothing new to you. What IS new is that Godot gives you the source code, so that you can debug and fix issues yourself. You're not dependent on your vendor's priorities! Performance: Godot is optimised for general-purpose cases, and sometimes games hit the specific cases it's not well-optimised for. This is true for any engine; there is always a trade off. It was useful that we could optimise GridMap for our specific open world use-cases though! Bugs: 3.5 was *remarkably* stable considering it's a community-driven project. However, given the number of players CB has, and the number of hours each of those players put into it, we did encounter a handful of weird engine bugs relating to audio & thread-safety. Regarding publishers, none of the ones we pitched CB to (in 2019/2020) seemed to be put off by our decision to use Godot. If they were, they didn't say it. And actually, a few were quite interested in Godot themselves even back then. Godot is perfect for small projects. For medium/large indie projects, if you're not afraid to get your hands dirty with C++ engine code, 3.x is already good enough! I suspect that Godot 4.x will be in a similar state next year, and continue to improve after that. One last point to make for (ex-)Unity users: don't overlook GDScript! You're all so laser-focused on C# that you miss one of the best things about Godot! In GDScript, there's no garbage collector to tiptoe around, the VM uses engine types natively without need of a translation layer, and there's syntactical sugar for common engine tasks like retrieving nodes by path, etc. GDScript is of course slower than C# if you're benchmarking *just* script code on its own, but in my experience it's rare for pure scripting to be a bottleneck in a game. There was only one area in CB where scripting hurt performance, and for that we went straight to C++, not C#! If it wasn't already clear, we love Godot here at Bytten Studio, and we're committed to using it in all our future projects. If you're looking to release something next year or later, try Godot 4. If you need something you can release sooner, try 3. If you're still undecided, check out Cassette Beasts and decide for yourself whether Godot is ready for your projects: https://store.steampowered.com/app/1321440/Cassette_Beasts/  |
Gregory's Server
There's a persistent falsehood among Unity devs that Godot can't do consoles. There are more options available than you realise: several companies have private Godot forks that add console support, and you can either license it off them, or have them port your game.
In our case, we worked with Pineapple Works. They worked incredibly hard to port Cassette Beasts to Switch and Xbox, and did a great job. AFAIK, CB is the first (only?) Godot game to release on an Xbox!