> We did our best job here leaning heavily on the resource system. There's stuff I want to say about the result that's platform specific so I can't. We have a thing, it works, and it could be a lot better.
Literally the only part I wanted to get more information about.
I could use a lot more information on why POSIX is bad and exactly what it means on resource management being “aware” of unified memory. I mostly didn’t get.
Man, Godot sounds like a bit of a mess. I've been building a Freelancer-like game on it for a while now and performance has been a nightmare to the point where I've offloaded most of my code into pure C# and out of Godot. I even had to give up on Godot's Jolt physics. I'm constantly hitting the limits of what Godot can do. The renderer is pretty much the only thing stopping me from putting tons of ships in the same battle, but I'm also not experienced enough at game dev to know if what I want to do is actually doable with a better renderer or on something like Unreal.
I do agree with her take though. Getting up and running in Godot was surprisingly, blindingly fast, so I don't regret picking it at all. I'm just not sure I'll be able to stick with it for an eventual release.
It sounds like a mess, though comments about Godot are often vaguely positive. I appreciate you posting your experience about a limitation you’re running up against.
I can think of only one popular game of note that was made Godot, Slay the Spire 2. I’d love for more titles to be released to prove the engine can be competitive.
The popularity of a game has far more to do with advertising and streaming exposure than the framework used - obviously Godot is capable, thousands of games have been published with it at this point.
Jolt is essentially the same physics engine that was used in the Horizon games, the performance there should be able to get quite good.
If you're making any kind of even slightly ambitious 3d game you probably need to be using gdextensions (ie writing custom engine-extensions in C++). I'll add that the engine source is very accessible. It's deliberately pretty bare C++, so if you have a decent amount of C# / C experience you should be able to find your way around it pretty easily.
Unity is a bit better when it comes to performance foot-guns and messiness (and in some ways much worse). Unreal seems to be pretty frictionless for getting something working that looks impressive, but if you're not very experienced performance is going to be a big issue there too (there seem to be very few games made in Unreal that run well on mediocre / older hardware).
Godot's a mess in the sense that it is trying to expand in every direction at once right now. I think it'll be in a pretty different state in 2-3 years.
Is there actually a huge performance gap between Godot and Unity/Unreal? I've never personally made a game but I have only seen small-medium games in Godot. I would have thought the rendering would be where the slack is tightened first as its the most visible part.
For small projects, especially small 2D projects? No. For big projects being done by pro teams that are willing to do a lot of work to customize their render pipelines and whatnot to really push resources to the limit? Yes.
I am absolutely NOT a game dev experts, so I'm sure I'm missing subtleties, but from what I understand, Unity's scriptable render pipelines give advanced teams more opportunities to tweak custom/complex rendering logic. I get the impression that they are likely pretty comparable out of the box if you just start adding objects to a scene and measuring performance, but Unity has fancier tools for potentially improving on that.
Sometimes it is possible to pinpoint problems if not fix them. In my limited experience the Godot source is quite accessible and straightforward despite the complications of multiplatform builds.
> We did our best job here leaning heavily on the resource system. There's stuff I want to say about the result that's platform specific so I can't. We have a thing, it works, and it could be a lot better.
Literally the only part I wanted to get more information about.
I could use a lot more information on why POSIX is bad and exactly what it means on resource management being “aware” of unified memory. I mostly didn’t get.
Game consoles aren't UNIX, and the way file system access works has to take into account the specialised hardware.
Like for example, streaming textures from CD with cache directly into the rendering pipeline.
Example for PC, however it was inspired how modern consoles work
https://developer.nvidia.com/rtx-io
Man, Godot sounds like a bit of a mess. I've been building a Freelancer-like game on it for a while now and performance has been a nightmare to the point where I've offloaded most of my code into pure C# and out of Godot. I even had to give up on Godot's Jolt physics. I'm constantly hitting the limits of what Godot can do. The renderer is pretty much the only thing stopping me from putting tons of ships in the same battle, but I'm also not experienced enough at game dev to know if what I want to do is actually doable with a better renderer or on something like Unreal.
I do agree with her take though. Getting up and running in Godot was surprisingly, blindingly fast, so I don't regret picking it at all. I'm just not sure I'll be able to stick with it for an eventual release.
For a pure C# engine maybe check out https://www.stride3d.net. It's using Bepu for physics.
It sounds like a mess, though comments about Godot are often vaguely positive. I appreciate you posting your experience about a limitation you’re running up against.
I can think of only one popular game of note that was made Godot, Slay the Spire 2. I’d love for more titles to be released to prove the engine can be competitive.
The popularity of a game has far more to do with advertising and streaming exposure than the framework used - obviously Godot is capable, thousands of games have been published with it at this point.
Jolt is essentially the same physics engine that was used in the Horizon games, the performance there should be able to get quite good.
If you're making any kind of even slightly ambitious 3d game you probably need to be using gdextensions (ie writing custom engine-extensions in C++). I'll add that the engine source is very accessible. It's deliberately pretty bare C++, so if you have a decent amount of C# / C experience you should be able to find your way around it pretty easily.
Unity is a bit better when it comes to performance foot-guns and messiness (and in some ways much worse). Unreal seems to be pretty frictionless for getting something working that looks impressive, but if you're not very experienced performance is going to be a big issue there too (there seem to be very few games made in Unreal that run well on mediocre / older hardware).
Godot's a mess in the sense that it is trying to expand in every direction at once right now. I think it'll be in a pretty different state in 2-3 years.
Is there actually a huge performance gap between Godot and Unity/Unreal? I've never personally made a game but I have only seen small-medium games in Godot. I would have thought the rendering would be where the slack is tightened first as its the most visible part.
For small projects, especially small 2D projects? No. For big projects being done by pro teams that are willing to do a lot of work to customize their render pipelines and whatnot to really push resources to the limit? Yes.
I am absolutely NOT a game dev experts, so I'm sure I'm missing subtleties, but from what I understand, Unity's scriptable render pipelines give advanced teams more opportunities to tweak custom/complex rendering logic. I get the impression that they are likely pretty comparable out of the box if you just start adding objects to a scene and measuring performance, but Unity has fancier tools for potentially improving on that.
Have you tried using the profiler? Where is the bottleneck?
Sometimes it is possible to pinpoint problems if not fix them. In my limited experience the Godot source is quite accessible and straightforward despite the complications of multiplatform builds.