It’s time to make that indie C# game in Godot
jolexxa.medium.com
It’s time to make that indie C# game in Godot
1–10 of 228 posts
Re: It’s time to make that indie C# game in Godot
#2> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work
Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal.
Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
Re: It’s time to make that indie C# game in Godot
#3With 4.0 getting more and more advanced features [0] and Unity merging with an Ad company [1], Godot is looking like it could be an attractive proposition for a lot of Unity shops.
Re: It’s time to make that indie C# game in Godot
#4> One is an industry behemoth and the world’s most popular game engine, while the other is a free, 30 megabyte program developed by passionate developers in their free time.
I was under the impression that Godot had at least two full-time devs working on it. Between their patreon revenue and the grants they've received they can definitely afford a small team on payroll. It's still important to stress the comparison in scope between Unity and Godot, but the latter is definitely more than a hobby project at this point.
Re: It’s time to make that indie C# game in Godot
#5> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
Anyone who used Unity 2.x in 08 would tell you Godot is far beyond where Unity was in 2008 in terms of features and stability.
Re: It’s time to make that indie C# game in Godot
#6> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
The quoted statement is 100% accurate. Unity is very slow. When I worked on Unity with a larger project, I'd often have to wait 10+ seconds for Unity to rescan the entire project every time I switched windows from my IDE to Unity, or every time I ran the project. In similar project sizes, Godot was always lightning fast.
> Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
Unity does have more features - like more obscure 3D features - but that has nothing to do with how Unity deems it necessary to rescan the project tree all the time. Also, when I used Unity, I never used these extra features, so even if this were true, how come all users have to pay the price for features that only a few of us will use?
Honestly, core Godot is very full-featured, and in my experience the central abstractions are much better thought out than those in Unity. I feel a lot of the FUD around "Unity has more features than Godot" comes from people that like seeing a long list of features, not from people who actually need those features.
Re: It’s time to make that indie C# game in Godot
#7> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
This seems to be a cyclical thing. Every now and then a new solution shows up that is built on new development and UX practices, abandons some baggage that is no longer relevant to most users, makes assumptions in its design that are better suited to the era, etc etc.
Then ten or twenty years pass and it becomes the thing to replace.
Re: It’s time to make that indie C# game in Godot
#8> One is an industry behemoth and the world’s most popular game engine, while the other is a free, 30 megabyte program developed by passionate developers in their free time. I was under the impression that Godot had at least two full-time devs working on it. Between their patreon revenue and the grants they've received they can definitely afford a small team on payroll. It's still important to stress the comparison i…
At least one of them, the original creator, is full-time (I follow him on Twitter). Not positive about others but it's certainly possible
Re: It’s time to make that indie C# game in Godot
#9> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal. Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
The quoted statement is 100% accurate. Unity is very slow. When I worked on Unity with a larger project, I'd often have to wait 10+ seconds for Unity to rescan the entire project every time I switched windows from my IDE to Unity, or every time I ran the project. In similar project sizes, Godot was always lightning fast. > Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product…
Agreed- my limited Unity usage has been horrible just because of how bloated and massive it seems every time I try to give it a go.
Whereas Godot opens up in literally 1 second and boom I am there.
And for 2D projects, there is very little "lacking" compared to Unity. It's way more clear what is going on.
Re: It’s time to make that indie C# game in Godot
#10C# hasn't been an issue for me at all bar a few oddities. Some things not working properly in C# (think some plugins or something back a while ago). Some code not directly mapping from GDScript to C#, causing huge object count issues. For reference, I've been using it since 3.1 in a hobby context.
Really, it's not the developers you have to worry about. It's everyone else. Godot is made with developers in mind, but there's much more to do than wiring signals and writing code. If you can't map things one to one from a different program or close to that through a plugin, you're either giving yourself more work, or forcing not just developers, but artists to relearn processes too.
The small stuff will get fixed over time.