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.
There's just very little overlap in sensible use cases, they barely even count as competitors.
Unreal, of course, has more features and is more powerful.
Choosing Godot means you are more likely to actually finish making the game. Choosing Unreal means you can potentially make a better game. For me, that's a tough choice, and I often have trouble deciding between one and the other (for 3d games)
There is a vocal amount of people (can't say whether they're a minority or not) that tout/desire the major open source engines to be a valid replacement to the commercial ones. This is also happening in Rust, where Bevy is extremely hyped.
So, while it's absolutely true that comparisons don't make much sense, practically, there is a lot of talk about such comparison, so it does make much sense to make this very clear, at least in order to inform developers.
It's not even the most advanced open source 3D engine right now, considering O3DE (a fork of CryEngine) is open and backed by a fair few big players.
VR support is there. Again, I think not the engine's priority. Last I checked some of their new core tech behind ue5 (lumen, nanite) didn't work correctly in VR, though that was around launch time. I would probably start a new VR project in Unreal, and Godot for mobile.
edit: the RE4 VR remake was in Unreal for example
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.
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".
Like
x += v * dt
draw(x)
Also, physics is costly to run, so usually it's not run on every frame.
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.
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.
Sorry I have nothing else to add to your comment, but I just wanted to say I love your analogy. I am stealing this one.
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.
That's their purported scripting language for Unreal. By far the most "serious hobbyist" unfriendly aspect of Unreal has always been the heavy macro based C++. They tend to be people who don't like the idea of visual programming, so hate Blueprints (no hat in this race, I think they're ok), and have come from the cushy tooling you get with C# like Rider
Verse has a good chance to give Unreal a fresh start with some tight focused tooling and good ergonomics.
It's also a little ironic to say that since that's the opposite story of Unity, which dropped Boo and "Unityscript" to great effect... but that's how daunting C++ is for some people
List https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games
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.
Good marketting I guess!
- 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
Doesn't that depend entirely upon the artwork used in the game?
- All of the above except language
- Library rather than engine
I've had really good luck with it versus Babylon or Unity.
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
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
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.
Godot, not being beholden to shareholders and quarterly growth targets, can hopefully make more clear-headed decisions around product roadmap.
That said, Unity ads is where the real money is at.
Huh... looks like it did stop
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?
lambdas, closures, support for error handling, constructor overloading, list comprehension, packing/unpacking (arguments/lists), varargs
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.
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.
While I'm here, I might as well give my $0.02 about bevy. It's got an amazingly sturdy foundation, but it lacks essential game engine features like asset preprocessing and render postprocessing stacks. Those are both slated to land in time for 0.9, which should put it ahead of most OSS engines.
Currently, there's also some very annoying stuff related to managing when and in what order systems run. There's a mostly-done big refactor called "stageless" which totally fixes this, but it touches a lot of code and needs to be merged. I'll quite be happy if that makes it into 0.9 too.
There are lots of other features missing, like everything UI, but these are the near-term changes and should put it in a good place for future growth.
Being able to use `auto` would make the code already a lot less verbose IMO.
Autos and lambdas are not allowed from a style guide decision.
The commenter is lamenting that they don't feel comfortable contributing to an open source project that they use because of the language choice of the project. It's far easier to simply write the couple of sentences involved than to coax GPT-3 to do it. Your apparent inability to understand the commenter's point doesn't make the commenter an algorithm. The correct response, if you are puzzled by a comment, is to ask a respectful question about the comment.
"Assume the best interpretation of a comment" is a core assumption that HN readers are asked to make when reading and commenting on threads, and it's a remarkably good place to start here.