this post was submitted on 21 May 2026
107 points (98.2% liked)

Game Development

6181 readers
12 users here now

Welcome to the game development community! This is a place to talk about and post anything related to the field of game development.

Community Wiki

founded 3 years ago
MODERATORS
top 19 comments
sorted by: hot top controversial new old
[–] MurrayL@lemmy.world 64 points 3 weeks ago (1 children)

Unity, including Unity Hub and related components, required roughly 21GB of storage, while Godot Engine needed only around 164MB

It really is astounding how bloated Unity has become over the last decade. It was never a lightweight engine, but 20GB+ just to install the editor is nuts.

[–] jlow@slrpnk.net 1 points 2 weeks ago

That is pretty lightweight comapred to Unreal still, isn't it? I remember being astonished how huge the Unreal download was when I needed to install ot a few months back, cant remember how much it was now, unfortunately.

[–] copygirl@lemmy.blahaj.zone 37 points 3 weeks ago (2 children)

In Grové’s tests, Unity took 15.4 seconds to compile scripts, while Godot Engine took just 0.31 seconds, which is a significant gap. This is likely due to Unity’s standard use of the compiled language C#, whereas Godot uses its interpreted in-house language GDScript, allowing for much faster iteration times.

Both C# and GDScript are (typically) compiled to bytecode, so they are probably more similar than they are different when it comes to the compilation step. (C# does get compiled to native machine code by the .NET runtime, the GDScript bytecode is likely still running in an optimized interpreter.) There is no excuse why Unity should be taking that long to compile its scripts. Certainly that's not a failure of the language used.

[–] Quetzalcutlass@lemmy.world 20 points 3 weeks ago* (last edited 3 weeks ago) (2 children)

I'm guessing it's due to Unity firing up a full modern toolchain during compilation versus GDScript's simpler bespoke compiler.

It would have been a better comparison if he'd used C# for both games, given Godot supports it as an alternate to GDScript.

[–] TheFogan@programming.dev 10 points 3 weeks ago (1 children)

I mean you can go both ways. If godot fell behind then it would be argued that it's not it's primary language. IE I'm not a huge expert on how the languages work. but I'd imagine godot would be less efficiant when using the languages that it supports, but wasn't built for.

That's like competing in a reading contest with your second language, versus an opponent who only speaks the language.

[–] Quetzalcutlass@lemmy.world 4 points 3 weeks ago* (last edited 3 weeks ago)

C# has faster execution speed compared to GDScript, but Godot needs to marshal data when communicating between the core engine and the C# runtime, which can negatively affect performance if you don't keep it in mind when writing your code.

But ultimately I'd argue compilation speed is waaay more important than execution speed when it comes to creating games (which require rapid iteration and testing). There's only a small amount of code in a codebase where squeezing out the maximum performance is required, and those important bottlenecks can be refactored or rewritten in a more performant language if needed.

[–] copygirl@lemmy.blahaj.zone 7 points 3 weeks ago* (last edited 3 weeks ago)

Unity firing up a full modern toolchain

It's funny you say that because Unity's C# tooling is soooo many years behind. They're still using Mono. (Godot also used it in the past.) And apparently only some time this year (end of 2026?) will they have proper modern C# with all its performance benefits.

edit: Actually I just found this in a related article (unsure about whether it's slop or not, so not gonna link it) but apparently the horrible compile times is from something called "Domain Reload" and is caused exactly by that ancient tooling being used.

[–] enbiousenvy@lemmy.blahaj.zone 3 points 3 weeks ago (1 children)

godot mono version also compiles C# faster IME

[–] boaratio@lemmy.world 1 points 3 weeks ago (1 children)

It doesn't use mono anymore, they have been on official MS tooling for a long time now.

[–] enbiousenvy@lemmy.blahaj.zone 2 points 3 weeks ago

I know, it's just called mono but uses dotnet internally

[–] owlboy@lemmy.world 7 points 3 weeks ago (1 children)
[–] RightHandOfIkaros@lemmy.world 12 points 3 weeks ago (1 children)

What are you trying to run it on, a Commodore64 running TempleOS?

[–] UnrepentantAlgebra@lemmy.world 4 points 3 weeks ago (2 children)

To be fair, the hub isn't part of the Unity engine or editor. It just downloads and manages versions of the editor and lists your projects, which you can then open in the editor. There's no real need for the hub to use 512 MB (not that it's even that much memory).

[–] paraphrand@lemmy.world 5 points 3 weeks ago (1 children)

Yeah, and the reason it sucks is because it’s Electron.

[–] UnrepentantAlgebra@lemmy.world 4 points 3 weeks ago

I assumed as much but didn't want to say so without confirming lol

[–] Ziglin@lemmy.world 3 points 3 weeks ago

I could see it wanting that much so it can do weird stuff to download and decompress data crazy fast but it wouldn't be required and I don't think that is what is happening.

[–] RightHandOfIkaros@lemmy.world 2 points 3 weeks ago (1 children)

I can't help but feel like this article is biased in favor of Godot. Looking at the screenshots, its pretty clear that the Godot build appears to have post-processing effects applied to it while the Unity one appears to not have the same effects applied to it, or they are not tuned to the same values.

A person who is good at using a game engine can make a game look graphically almost identical when made in any other engine.

[–] AwesomeLowlander@sh.itjust.works 9 points 3 weeks ago (1 children)

Grové concluded that both engines were fully capable of creating the kind of game he wanted to make. When comparing framerates, he noted that although his target was 60fps, both engines achieved framerates several times higher than that. Even accounting for future graphical improvements, he believes both still have plenty of performance headroom.

It's not like he was knocking the performance or graphics, and the points on which Godot won were objective measurements

[–] RightHandOfIkaros@lemmy.world 7 points 3 weeks ago

I am simply pointing out that those screenshots skew the appearance of the article and make it appear to be biased in favor of Godot. I would imagine that people should want a fair and equal comparison for all elements of the two engines for comparison.

Because there is a difference, the argument could be made: if there is such an intentional difference in the screenshots with post-processing graphics, is there an intentional difference elsewhere as well to skew the data?

Its possible that there isn't, but just how trustworthy is that? That's all.