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.
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!
As for what it's like actually using Godot: I've found it to be a well-designed, consistent, easy-to-learn engine (CB is my 1st Godot project), and flexible/extensible. Creating new engine plugins to improve workflow or add file format support is dead easy.
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#!
@tccoxon for me raw performance isn't a factor versus effort of porting.
Ideally with C# I may be able to take existing code and rework it to fit how Godot does things. Changing languages pretty much forces a complete rewrite of whatever games I end up porting from unity to Godot.
Skimmed the thread so I'm not sure if you addressed that point already.
@beeoproblem changing the engine is gonna completely change the API you're working with. You can't just take C# code written for Unity and expect it to work in Godot
@tccoxon I didn't think that needed to be said outright. Basic stuff like what Node (in Godot) is and how it works kinda gives that away right at the outset.
IME it's still less effort to rip apart and rework a piece of existing code than it is to recreate it from scratch. The more custom/engine agnostic code a project has, the more the equation tilts toward porting being less effort than a rewrite.
@tccoxon Ah! Related side-question: how much of your code was in GDScript, C#, or C++, would you say?
Like with Unreal, we're about 95% Blueprint, which is important for not getting bogged down in C++ (which is fine but is iteration-speed kryptonite). Unity, of course, all C#, for better and worse. Where does Godot fall on that?
@glassbottommeg Cassette Beasts is about 90k lines of GDScript, 0 C#, and probably less than 500 lines of C++. We could have done all C# instead of GDScript but it didn't feel like there was much point when GDScript has tighter engine integration, and C++ is right there anyway.
@gord@glassbottommeg Some fixes (all now in Godot 4), some stuff to help me debug, some engine optimisations (that we can't submit back because they make other things worse), and some code I ported from GDScript to improve game performance.
@tccoxon@glassbottommeg I'm currently at the "how do I export my blender character and animations" stage have not even poked at code yet. Saw godot had a direct blender -> godot importer and said "not today Satan" because that's what I did when I first learned Unity and it caused so much trouble later down the road!
@gord@tccoxon@glassbottommeg Unity's blend file support isn't 'true' blend file support, though. It just silently uses Blender's FBX exporter and then imports the fbx. Godot's blend file importer actually natively reads the blend file.
@DKesserich@gord@tccoxon oh heck, that's wonderful. Yeah, Unity's "yeah we import .blend! (it'll corrupt if you ever don't have Blender also installed or have the wrong version)" was extremely, uhhhhh.
@glassbottommeg@DKesserich@tccoxon The part that got me was Unity changed their fbx script to ignore animations and for two years I needed to manually edit a unity script to switch a flag back that they never told anyone about.
@zebu Godot is a lot more flexible in that respect. You can fork and change how physics works, or even completely replace the physics engine https://github.com/godot-jolt/godot-jolt
@tccoxon it would be really nice if godot would eventually add console support to the engine. I'm generally pretty impressed with the work that the godot team has done.
@tccoxon Yeah I actually played through Cassette Beasts with my Switch and while it had some minor issues at launched those were patched later so it wasn't the engine itself having compatibility issues.
@tccoxon Also since you worked on Cassette Beasts I gotta say its a very good game. Probably one of my fav monster collectors I've played in a while and I've played a ton of those (from modern indie games like Nexomon, Monster Crown and Coromon to some of the older Pokemon competitors made by larger studios like Spectrobes and Fossil Fighters)
@tccoxon I'm so glad y'all managed to dodge a major bullet on this one 🙏 you're half the reason I had any faith on beginning the process to bring my C# stuff into Godot before gallons and gallons of fuel were dumped on the fire to do so.
@tccoxon I'd add one corollary about switching engines mid-project; you can probably get away with it once, if you find you really need to. More than once, and you run the risk of ending up like Duke Nukem Forever or Half Life 3.
Do it once, and you could end up with Metroid Dread or like FF Versus 13. Though yeah, it's not really a guarantee (Given that FF Versus 13 became FF 15 because it didn't really take focus.).
@Ray_Of_Sunlight@DaniES 4 is practically a different engine. Definitely not an upgrade you do during a project, never mind 1 month before your game's release
@tccoxon@Ray_Of_Sunlight This. I wasn't able to migrate even small gamejam projects, I cannot think any reason to justify trying to migrate for big projects about to be released.
Add comment