Hello!
So I am researching for a project I am planning and I have a few questions for Unity users. I figure this is the best place to ask them. 
If you are a Unity user and you are curious about learning Godot Engine:
Is Godot more optimized for mobile devices?
ScriptableObject event architecture, DOTS and Animation Rigging
NaughtyAttributes, Timeline and xNode
How does one scale a GDscript based architecture? A loosely typed language with enforced overreliance on things like direct node name/path references and direct asset path references seems fragile and likely a nightmare to manage at a team level.
How viable is C# really? As far as I’m aware, editor tooling can only be done in GDscript and editor integration falls short of what GDscript has. i.e. it seems like C# is still a second-class citizen to an extent. Not sure if/how this is changing in Godot 4.
Are custom C# types serializable to the Godot editor? Things like abstract classes, interfaces in the vein of [SerializeReference] or what Odin Inspector provides.
Thanks for the info! Super helpful!
Thank you for the info! Very thorough questions.
Biggest question, by a long shot, is why? If I’m not an open source fanatic, what advantages does Godot offer?
The biggest lure for me is lack of bloat - Godot has one solution for every given thing and it’s typically well documented. Meanwhile, Unity has 2 Input systems, 3 UI systems, 4 very different render pipelines, two graph tool APIs - one experimental and the other in preview, 3 text engines, Visual Scripting package that for 8 months couldn’t deploy to IL2CPP platforms due to a shortsighted decision they’ll now reverse in the next LTS release, etc.
And people still recommend Rewired over the new Input system due to bugs that go unaddressed for months of even years and lack of documentation and samples. There’s a lot of mental load and time that goes into continuously evaluating all these options, many of which are still rapidly changing to the point solo asset store developers are sometimes more reliable than Unity both in functionality and bug fix response times.
It’s incredibly refreshing to pick up an engine and simply work on the game, no PhD in package manager and asset store necessary. And all users are on the same page because they’re using the same tools - there’s no fragmentation.
It’s incredible seeing that people actually bashing Unity and praising Godot over bug fixing after Godot went for years with glaring 3D performance bugs (and not the Unity-kind: which are annoying, but ultimately can be circumvented relatively easily) and no one bothered to even look at them. The curse of open source software: you never know if and when a bug will be fixed if you don’t do it yourself.
Are you taking Youtube and Github into account there? Since I’d quite confidently say that there’s no other engine with more examples and tutorials than Unity out there.
For example for the new input system I watched a certain 1h video and it gave me all the key information necessary.
That is true. At the same time that provides massive freedom. If there are multiple ways to do something, it’s more likely to find something that works for you Open source also provides massive freedom, but you don’t wanna do stuff yourself all the time. In recent years Unity turned more and more parts into packages and thus also open source.
Simplicity and straight forwardness is, in the end, limiting. We shall see if Godot reaches remotely feature parity with Unity in version 5 or 6 - and whether it’s still smooth sailing to use by then.
That’s only true if you don’t know what you’re doing when you’re doing it. If you plan ahead, you make a conscious choice and don’t care about it anymore. Like if you know what game you’re making and what is your target platform you choose rendering ONCE, when you start your project and don’t care about the rest of the rendering offering anymore during the lifetime of your project.
Of course this means you need to know what you’re doing. The same is true for the input system: if you do what input system was made for, it works quite well. It doesn’t support a bunch of exotic controllers, sure, but it works well in general (I can’t evaluate VR or touch, I don’t do mobile or VR). You need to adhere to the rules like don’t fire more than one action with one binding? Sure, but that’s logical and actually a good idea. I mean disable fricking UI bindings during gameplay and gameplay bindings during pause menu and those things. People don’t like to do things like that so they are complaining. They also don’t like to read documentation so they tell you that it’s lacking. It is not.
Ill flip this question back to you; what advantage in development workflow, that Unity doesn’t have or lacks in, would you deem a valuable offer?
For me (I’ve started toying with the latest betas a couple weeks ago) it’s mainly 3 things:
Insanely fast iteration speed. So far I’d say it’s 10-20 times faster than Unity. Hot reloading code, no compilation time, exporting takes few seconds, etc
Architecture and philosophy. In broad strokes it’s similar to unity’s but I’ve found many little details that makes it feel more well though-out. This is not the same as polished, mind you. It’s got lots of rough edges and clearly feels less mature, buy the foundations “make more sense” in a way. A couple examples that come to mind right now:
Unifying the concept of objects and components in just nodes generates less bloat, makes it easier to reason about your setup.
The scene tree is given much more importance than in unity. Instead of just being a spatial-transform-thing, it codifies practically every relationship between nodes. Nodes are initialized and updated in strict depth-first order, much more reasonable and useful than Unity’s undefined behavior.
Asset management is more powerful. Godot’s resources are much more flexible than Unity’s ScriptableObjects. You can create them in-place (embed) when you need a quick one-off data piece, then promote them to their own file later. You can choose if resources stay shared or are copied when instancing a scene that uses them, etc. Also the serialization file is almost plaintext, making it much easier to debug your data and source control it.
A reassurance that the engine will not become a glass ceiling. Knowing that I can do whatever I need with it (legally and technically) gust gives me peace. I’m not knowledgeable enough to just go in and tinker with the engine’s bowels right now, but If in the future I need to, the only limiting factor are my own resources
If I would switch engines, workflow speed is important but in addition I would have to be convinced Godot has a brighter future than Unity. What I don’t want to do is to learn yet another soon to be “dead end” engine. Of course Godot is not going to die anytime soon but I believe Unity is always going to support more platforms and will implement support for new platforms faster than Godot, for an example.
Another weakness of Godot and I think one of reason why not many commercial projects picked it up is that they don’t protect anything, your codes can be decompiled pretty easily, and they can restore your whole project 1:1, along with the # comments you put in that codes. and if you dare to brought up “obfuscation” as a new feature proposal, you will get shot down. because of “If people want your code, they’ll have your code” cult mentality of godot community.
The saddest part is, there was a dude who implemented this, using python or something to obfuscate gdscript. Posted prototype… only to receive overly negative feedback from the cult. That github project is now
archived.
When they say, GDscript turned into bytecode isn’t anything like Unity C# turned into bytecode or java → javabytecode. Meanwhile in GDScript there isn’t much minification nor stripping. What people decompile will be exactly 100% as the original source, complete with your comments. All links, connections, symbols preserved.
It is the same thing with unity. You can literally rebuild C# source in many projects, and that’s why people love modding unity games.
The biggest weakness of Godot is their fans. Those people deal massive damage to engine reputation while trying to “spread the word”. Because nobody likes door to door preachers.
Unity has the exact same weakness. Just a few days ago I opened up a binary in an asset that didn’t include source code using JetBrains dotPeek.
I’ve reverse engineered code that was obfuscated (Gazillionaire Deluxe by LavaMind) to fix a bug in the code that was annoying me, and that was a couple decades ago when I had far less experience. Last I heard Minecraft was still obfuscated and that game gets reverse engineered as soon as a new release comes out.
@neginfinity @Ryiah You need to understand that when you Export using Godot, you will see two files
The MyProject.pck is nothing more than your project directory, compressed, like right click, and zip it using WinRar (albeit different packing method). This pck file, can be decompressed, and it is 1:1 restoreable as per whatever steps written in the pck_packer.cpp as if you have the original source.
thats because Godot IDE is actually Godot (+ editor functions) that opens a folder.
meanwhile Godot Game is Godot (with editor stripped) that opens a .pck file
I wish I save that reddit thread about someone sharing stories about their project that was submitted on charity game jam, ended up on app store.
Okay, but the method to learn how to do it is the same for Godot, Unity, and Unreal:
https://www.google.com/search?q=Godot+extract+resources+from+game
https://www.google.com/search?q=Unity+extract+resources+from+game
https://www.google.com/search?q=Unreal+extract+resources+from+game
All three of these searches return accurate information on how to extract assets.
With that extraction, can they yield the exact same things that you have in your source control? Complete with the comments that you put?
To be fair, Unity decompilation and asset extraction can be pretty lossy. Lots of effort has to go in to rebuilding the project if it’s at all possible. And bullying the obfuscation guy is weird, seemed like a legitimate approach for people who needed that. Godot has the same issue Blender has or at least had back in the day - the vocal user base consists mainly of hobbyists and upcoming hopefuls who don’t really understand many everyday issues of industry in depth. Per recent community poll, 85% of Godot users are hobbyists.
Here’s some of the reasons why I don’t use Godot right now: