I've been part of shipping one of perhaps the largest used Godot projects in production. It's not a game, and you may not even realize it's Godot. Godot is below average in quality compared to Unreal, and probably about on par with various idiosyncrasies that Unity has.
Unreal is winning the technical race because they ship projects and games themselves with their engine. Unity does none of that, at least nothing that counts. Godot is a bit better than Unity because it's open-source so contributors are often contributing to things they use and want to improve, but it's still got weird opinions at a maintainer level and severe performance downfalls from those opinions.
We're considering another renderer, but for the time being we're still tepidly okay with Godot.
It's totally bizarre to compare Unreal Engine with Godot. One is a AAA 3D game engine with awful support for 2D games, the other is a superb 2D game engine with modest 3D capabilities.
There's just very little overlap in sensible use cases, they barely even count as competitors.
It's small enough of a code base that you can change things to suit your needs, too. Godot is definitely going to win the race long term, just like blender. People can use whatever they like, of course, but if you want future developer talent, youre going to need to use Godot.
How is Unreal on mobile and VR these days? The new UE5 tech doesn't seem to run on it. I can't really speak from experience but it always felt like mobile dev was a much higher priority for Unity than Unreal. Is that still the case?
Hey, I'm curious to know what are some of those "weird opinions at a maintainer level". I would love to know more about your experience using it at such scale.
This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing!
EDIT: I forgot to mention the _third_ possiblity, which is that you write a bunch of custom code in GDScript or C++ which attempts to do the interpolation.
Not entirely true. For a long time Godot has had Engine.get_physics_interpolation_fraction, which permits smooth interpolation of visual bodies ticking at render rate while their physics bodies tick at the physics rate (2D or 3D). I can run my physics at 2 fps (or any increment) and an object will smoothly move from A to B, because rendering is happening in _process and target positions are being calculated in _physics_process.
Placing a camera under the control of a physics node is just the way most people do it because they don't know any better. Decoupling an object's physics representation from visual representation is something many devs never learn, and they pay the price with frustrating visual stuttering under any engine -- as I did for many, many months back in the day under Unity until figuring it all out.
I'm looking forward to playing with the new baked-in physics interpolation (albeit only for 3D so far) with 3.5, but this has been easy to implement in 3.x for anyone familiar with "get_physics_interpolation_fraction".
Why couldn't you just run physics at the graphics frame rate (or double it if the graphics becomes too slow)? I don't think many games need fully deterministic physics do they?
From what I'm hearing Unreal is establishing a big lead over the competition with things like Lumen, face model generation (Metahuman?), asset libraries, ML assisted images/video to model converters, very polished editor tooling ,world builders, ...
All things that take a lot of money to make.
Is there any chance to compete in the near or medium term for things like Unity or Godot? Outside of small indie studios or hobbyists that is.
Unreal is ahead for a couple of reasons (mainly historical + money) and they target industries outside of games as well now - namely film productions.
With that said most big AAA companies still use their proprietary game engines and I don't see that changing. General purpose engines like Unreal/Unity/Godot have their place of course, but to use the full set of features of Unreal you need a big team anyways, so comparing it to Unity and Godot doesn't seem right to me at least. Godot is slowly eating Unity's lunch though. Especially given the direction that Unity has taken after their IPO they might be in trouble in the near future.
Also there are some crazy people (like me) that just write their own engines for the projects they are doing and here's hoping that in time our number will actually grow. It would be very sad if the game engine world ends up like the OS or browser world for example.
This is kind of like looking at a race car and wondering how anything else can compete. First off, Unity and Godot have different license models from Unreal. There's room just based on that. Moreover, a lot of the fancy new stuff doesn't run well or at all on mobile, a huge segment of the market. I'm not saying Unity or Godot have it easy but there's still a lot of room in the market.
Unity is still extremely popular. The Unreal vs Unity engine debate has raged with plenty of people on both sides for years now all over game dev forums.
I don't have any exact stats offhand, but I believe there are plenty of big games recently published that were developed on Unity. The only examples I remember rn are Fortnite (Unreal, but sort of doesn't count because it's made by Epic Games, the makers of the engine...) and Fall Guys (Unity).
Unreal may have an edge on certain areas, and might have a slight edge with AAA level game producers that haven't built their own engine... but Unity has a possible edge in ease of use, a very popular asset store ecosystem, etc that make it arguably better for certain projects. See above examples, Fortnite and Fall Guys both chose their engines appropriate to their teams and project sizes.
Godot is for sure more indie, but has a pretty good trend upwards. Unity had some bad press recently after the merge / acquisition that may push a percentage of their market share towards Godot.
Not my field of work either but my understanding is that Unity, as a public company, should have no trouble competing with Unreal where cost is the limiting factor. They’ve got plenty of resources. Godot on the other hand has a totally different audience. So while they have far fewer resources/staff to throw at their product, they don’t need to try to achieve feature parity with Unity and Unreal. Part of why hobbyists and small studios enjoy working in Godot is its simplicity.
Now that Godot seems to be getting much hotter, I feel like I am having to update my game engine more and more frequently. It's great to see then update the navigation system, but will it break my game? I worry it could be heading to the same problem I see with Unity where things are constantly getting updated and re engineered. I have seen professional teams working in Unity be many version behind because they dread the work of updating.
Plus, I don't know how many more integrations I want to do on 3.x before 4.0. I am hoping that the move to Vulkan will give me better 3d performance on mobile
With Unity the general wisdom seems to be to lock in one version for each project, and only update when you start a new project.
Which I guess isn't the worst? Sure, better forwards and backwards compatibility would be better, but this way you get more features quicker and more coherently, at the downside of not getting any improvements during development
Unless Godot has solved the problem of forward compatibility of binary asset bundles with compiled assets, then what's true of Unity is true of Godot: the cost of your engine upgrade is proportional to your reliance on existing assets.
It may just be a recompile. It's may be that the upgrade requires more, a whole art pass before recompile. Maybe there's mods you don't have the source for, that you can't upgrade at all.
Hopefully the incentive schemes help with this: part of the reason for Unity’s feature churn is that they’re more incentivized to create new features (to acquire new customers) than maintain old ones. You’d think this approach would backfire, but with the amount of lock-in engines have they can afford to piss off current customers at least up to a point.
Godot, not being beholden to shareholders and quarterly growth targets, can hopefully make more clear-headed decisions around product roadmap.
I've looked at 3.4, 3.5 and 4.0a ... and while 4's scripting engine is definitely faster than the others before, it's still way too slow to consider using it.
I can concur - the stated position is that GDScript should only be used for non-performance-critical tasks, but even with a hundred objects running a simple script every frame, performance absolutely tanks in 3.x. The performance wall is so easy to hit that GDNative is almost a requirement to get good performance in non-trivial projects.
TLDR: The problem with Godot is that it tries to be everything to everyone.
They made an engine, an editor (a text editor, resource editor, debugger ...), invented a new language. They "support" export to almost all popular OS platforms. But in my opinion it's lacking in quality. The engine is slow (old style based on OOP), the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.
But it's certainly good for rapid prototyping and learning.
doesn't really seem that slow for me (but of course, i haven't used it in anger yet).
> the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.
the editor is enough for small scripts, but you can also choose to use your own native editor, or switch to the C# version (and use visual studio or jetbrain rider).
I don't find the scripting language any worse or better than any modern script languages. What are the missing features?
Anything beyond surface level is difficult to extract from the documentation and that hurts a lot. From the new user experience, the Godot IDE still feels buggy. Features (like the inspector) populate with values from code sometimes and sometimes not, because of complicated rules or you get the fun blank file script names or dupes when resources are changed/moved/deleted.
But, I really wish it was written in something other than C++. I really can't bring myself to go back to programming C++ again after a decade away using more recent languages like Go and Rust. I even find deciphering the types of variables to be painful when reading C++ code these days.
If you're looking to an up and coming game engine project, there's "Bevy", which is an ECS game engine (like Unreal) that's also open sourced, which is Rust based:
They aren't at first release yet. I think they're at 0.8, and I'm unsure as to their contribution structure, but read their documentation. It's in there I hope.
cptcobalt|3 years ago
Unreal is winning the technical race because they ship projects and games themselves with their engine. Unity does none of that, at least nothing that counts. Godot is a bit better than Unity because it's open-source so contributors are often contributing to things they use and want to improve, but it's still got weird opinions at a maintainer level and severe performance downfalls from those opinions.
We're considering another renderer, but for the time being we're still tepidly okay with Godot.
TillE|3 years ago
There's just very little overlap in sensible use cases, they barely even count as competitors.
fezfight|3 years ago
jayd16|3 years ago
naet|3 years ago
coppolaemilio|3 years ago
robrtsql|3 years ago
This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing!
EDIT: I forgot to mention the _third_ possiblity, which is that you write a bunch of custom code in GDScript or C++ which attempts to do the interpolation.
fergicide|3 years ago
Placing a camera under the control of a physics node is just the way most people do it because they don't know any better. Decoupling an object's physics representation from visual representation is something many devs never learn, and they pay the price with frustrating visual stuttering under any engine -- as I did for many, many months back in the day under Unity until figuring it all out.
I'm looking forward to playing with the new baked-in physics interpolation (albeit only for 3D so far) with 3.5, but this has been easy to implement in 3.x for anyone familiar with "get_physics_interpolation_fraction".
IshKebab|3 years ago
Like
Or is that what this does?the_duke|3 years ago
From what I'm hearing Unreal is establishing a big lead over the competition with things like Lumen, face model generation (Metahuman?), asset libraries, ML assisted images/video to model converters, very polished editor tooling ,world builders, ...
All things that take a lot of money to make.
Is there any chance to compete in the near or medium term for things like Unity or Godot? Outside of small indie studios or hobbyists that is.
_hao|3 years ago
With that said most big AAA companies still use their proprietary game engines and I don't see that changing. General purpose engines like Unreal/Unity/Godot have their place of course, but to use the full set of features of Unreal you need a big team anyways, so comparing it to Unity and Godot doesn't seem right to me at least. Godot is slowly eating Unity's lunch though. Especially given the direction that Unity has taken after their IPO they might be in trouble in the near future.
Also there are some crazy people (like me) that just write their own engines for the projects they are doing and here's hoping that in time our number will actually grow. It would be very sad if the game engine world ends up like the OS or browser world for example.
jayd16|3 years ago
naet|3 years ago
I don't have any exact stats offhand, but I believe there are plenty of big games recently published that were developed on Unity. The only examples I remember rn are Fortnite (Unreal, but sort of doesn't count because it's made by Epic Games, the makers of the engine...) and Fall Guys (Unity).
Unreal may have an edge on certain areas, and might have a slight edge with AAA level game producers that haven't built their own engine... but Unity has a possible edge in ease of use, a very popular asset store ecosystem, etc that make it arguably better for certain projects. See above examples, Fortnite and Fall Guys both chose their engines appropriate to their teams and project sizes.
Godot is for sure more indie, but has a pretty good trend upwards. Unity had some bad press recently after the merge / acquisition that may push a percentage of their market share towards Godot.
lux|3 years ago
https://www.indiegogo.com/projects/the-unity-improver-nano-t...
As for Metahumans, Unity has started on an equivalent of that too:
https://assetstore.unity.com/packages/essentials/tutorial-pr...
Character Creator is also looking like they're stepping up their game to match Metahumans:
https://www.reallusion.com/character-creator/default.html
That said, I'd love to see these things come to Godot specifically, including performance on the level of Unity ECS/DOTS.
jsf01|3 years ago
netr0ute|3 years ago
Untrue, as shown by numerous FOSS projects run by volunteers.
bilekas|3 years ago
Good marketting I guess!
BudaDude|3 years ago
- Open Source
- Cross Platform
- Frequent updates
- Easy to learn in a weekend
- You can use almost any programming language with it
- Godot 4.x has beautiful graphics
- Godette
georgeecollins|3 years ago
Plus, I don't know how many more integrations I want to do on 3.x before 4.0. I am hoping that the move to Vulkan will give me better 3d performance on mobile
wongarsu|3 years ago
Which I guess isn't the worst? Sure, better forwards and backwards compatibility would be better, but this way you get more features quicker and more coherently, at the downside of not getting any improvements during development
dleslie|3 years ago
It may just be a recompile. It's may be that the upgrade requires more, a whole art pass before recompile. Maybe there's mods you don't have the source for, that you can't upgrade at all.
Uehreka|3 years ago
Godot, not being beholden to shareholders and quarterly growth targets, can hopefully make more clear-headed decisions around product roadmap.
birracerveza|3 years ago
Huh... looks like it did stop
KronisLV|3 years ago
mshockwave|3 years ago
ccbccccbbcccbb|3 years ago
arran-nz|3 years ago
MrYellowP|3 years ago
zlsa|3 years ago
unknown|3 years ago
[deleted]
anonGone73|3 years ago
peoplefromibiza|3 years ago
see https://news.ycombinator.com/item?id=32358256
ehutch79|3 years ago
UnpossibleJim|3 years ago
https://en.wikipedia.org/wiki/Waiting_for_Godot
upupandup|3 years ago
https://en.wikipedia.org/wiki/Waiting_for_Godot
sdkgames|3 years ago
They made an engine, an editor (a text editor, resource editor, debugger ...), invented a new language. They "support" export to almost all popular OS platforms. But in my opinion it's lacking in quality. The engine is slow (old style based on OOP), the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.
But it's certainly good for rapid prototyping and learning.
chii|3 years ago
doesn't really seem that slow for me (but of course, i haven't used it in anger yet).
> the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.
the editor is enough for small scripts, but you can also choose to use your own native editor, or switch to the C# version (and use visual studio or jetbrain rider).
I don't find the scripting language any worse or better than any modern script languages. What are the missing features?
markus_zhang|3 years ago
ElCapitanMarkla|3 years ago
Supermancho|3 years ago
Tyndale|3 years ago
iwebdevfromhome|3 years ago
unknown|3 years ago
[deleted]
NewsyJake428|3 years ago
TheMagicHorsey|3 years ago
But, I really wish it was written in something other than C++. I really can't bring myself to go back to programming C++ again after a decade away using more recent languages like Go and Rust. I even find deciphering the types of variables to be painful when reading C++ code these days.
UnpossibleJim|3 years ago
https://bevyengine.org/learn/book/introduction/
They aren't at first release yet. I think they're at 0.8, and I'm unsure as to their contribution structure, but read their documentation. It's in there I hope.
hiccuphippo|3 years ago
nkozyra|3 years ago
demindiro|3 years ago
Being able to use `auto` would make the code already a lot less verbose IMO.
netr0ute|3 years ago