Yeah it does have issues, but I managed to pump out my own game very recently called Atlas Fury (Also on Android) [1]. Runs pretty well, but had to tamp down some things/effects I wanted to do. Your other option is Defold engine.
C# is a language but not a limiting factor to making a game. GDScript is for the most part fine to work with. Issues on other platforms is also something that will improve over time. Unity has not shown good faith in the least.
I'm not so confident that it will be fixed. It's been a known issue for nearly a year now:
"Godot 4's HTML5 exports currently cannot run on macOS and iOS due to upstream bugs with SharedArrayBuffer and WebGL 2.0. We recommend using macOS and iOS native export functionality instead, as it will also result in better performance."
Last time I tried Unity I felt like the web builds were awful... ran super poorly in browser even for a super basic scene and also had some compatibility issues with certain core Unity features. That was 2 or 3 years ago so maybe they've gotten better, but in general I think if you're trying to make web games specifically you should go direct to developing for web instead of using Unity or Godot.
This adds more to the evidence that Vulkan / DX12 seems like a failed API design, when too many graphics engineers are reinventing the wheel by building their render-graph API on top of these (propietary triple-A game engines, Unreal Engine, and now Godot...) Instead of real-time graphics APIs providing all these low-level manual synchronization primitives and cumbersome PSOs, maybe they should just provide an official Render Graph API instead? Provide all of the operations and its dependencies in an acyclic graph up-front, and the driver handles synchronization automatically in the most performant manner tailored to the hardware.
I guess there needed some trial-and-error in the gamedev world for about a decade to really nail down a nice to use but also performant graphics API design. Vulkan being originated from the Mantle API from AMD didn't help - since it was a low-level console API mainly accustomed to AMD's GPUs and really didn't seem like it would fit for a more "general-purpose" API spanning a huge range of hardware and can stand the test of time. And with Microsoft's DX12 hastely copying from AMD's initial design it also has all the same issues (The irony is that DX11 is still the best graphics API you can use in gamedev in Windows in terms of ergonomics and even performance - seeing many trying to dauntingly build a DX12 backend and end up performing worse than DX11...)
Nowadays I'm obversing that the industry has known these issues for a while and are experimenting with alternative API designs... there are some experiental render-graph extensions available in both DX12 / Vulkan (albeit in a limited fashion):
Calling Vulkan a failed design is selling it short. There are parts like image layout tracking that should never have been exposed; tracking that at the application level does not offer any additional gains. Exposing explicit synchronization, on the other hand, is in principle the right idea. The driver gets information through those APIs that it cannot derive any other way. I believe it enables certain practical resource access patterns that would be near impossible without that. However, there may be a better way than the current pipeline barrier API to describe data and execution dependencies.
Other parts of Vulkan are clear wins. Pipelines with their explicit state look more cumbersome than the OpenGL state machine when starting out on a toy renderer, but they are absolutely invaluable in anything slightly more complex. All OpenGL based renderers that I've worked with ended up building a state management abstraction on top of OpenGL to work around the debugging nightmare of forgotten state variable updates. Pipeline add this state management at the driver level.
Pipelines (or in general terms PSOs) are the most problematic aspect of Vulkan / DX12 - much more than synchronization! Large parts of the gamedev industry seems to recognize all the performance issues with pipelines and therefore companies are experimenting with newer models like the VK_EXT_shader_object extension ("Vulkan without Pipelines": https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...).
I think Vulkan / DX12 is explicitly designed to make making another abstraction on it possible? It's possible to make a full app on it without any assistant, but it's not the easiest way to use it. For example, you may make a opengl emulation layer on directX, but not the other way around. And dx12/vulkan is designed to be the underlying one (While hide some hardware specified gotcha).
The problem is... even it being low-level it isn't really a good abstraction. It mainly maps well with how AMD's hardware works but not NVIDIA's - NVIDIA has some inherent dynamic state baked into their hardware that makes the whole pipeline object thing a bit inefficient in theirs. But even ignoring this, it's a bit disheartening seeing all the graphics engineers working on game engines building similar things on top of it in suboptimal ways (ex. the pipeline cache), when it could have been just done at the driver level from the start! The reality is that most graphics application developers really do not care too much about the intricacies of low-level device management - and the ones who actually care are also building abstractions around it since they too don't really want to deal with this. Vulkan / DX12 basically feels like the driver developers have just given up and dumped the whole responsibility of managing a GPU onto the application developers.
It's a bit like how even the best performance-oriented engineers rarely go down to directly writing assembly to optimize their C/C++ code - sure you can do that, but excluding the rare hot spots it's mostly a waste of time. It is incredibly useful to get a debugger/profiler and observe how your code is compiled down to, but actually writing it is cumbersome and requires too much of a discipline with too many footguns.
It's great that Godot keeps improving. AFAIK it is still mostly for indie devs though. I don't know why valve isn't open sourcing Source 2. They barely even make games anymore and it would make them money in the long term if it means games could be made cheaper and better. UE5 on the other hand is leaps and bounds greater than both Source 2 and Godot judging from the few games that have released with it so far. There's also O3DE which last I checked isn't ready.
Valve doesn't try to make general purpose engines, they make engines that suit their own games, so unless you happen to be making a game which is shaped very much like HL:Alyx or CS2 you would probably be underwhelmed with Source 2. That includes platform support, Source 2 doesn't officially support any of the consoles because Valve hasn't needed it to, having only ever shipped it on PC and (briefly) Android/iOS.
Then again there is s&box which I would not consider being close to either, well the games that can be made with s&box at least. But I agree that it would probably be hard to build something like Teardown inside the Source 2 Engine. On the other hand: Teardown does not use Unity either.
The AAA industry is eating itself right now. Indie seems like a good place to be.
Also, indie games are a billion dollar market. Maybe it's time to stop using it as a synonym for "not serious." The consumer doesn't care that Undertale was made with Game Maker.
>There's also O3DE which last I checked isn't ready.
I don't think "indie" is synonymous with "not serious," at least if people use it that way I think they're wrong and I think there a lot of people who use it the same way I do.
To me "indie" is usually more a reflection of budget, which heavily impacts graphical sophistication, size of the game (as in how many levels, how many hours of play, etc), and usually means the price of the game will be between $5 and $30. AAA I expect $60 and 100+ hours of playable content. Indie game I expect 5 to 6 hours and I'm pleasantly surprised when it's more. When it comes to choice of game engine, that usually means they prefer less flexibility but more simplicity and "free stuff" from the framework, whereas a AAA game might prefer maximum flexibility, but that comes with complexity. As in all things it's a budget (time & money) tradeoff, not necessarily an "are we serious" tradeoff.
There was a time when Unity was the 'indie game engine' as well. Give Godot some time (especially since it's progress seems to be picking up steam.)
> UE5 on the other hand is leaps and bounds greater
UE5 has the benefit of standing on the shoulders of giants, not to mention giant-sized pockets of cash to spend on developing it. UE has been around since 1998, so we're talking a quarter of a century of development leading up to what UE5 is today. It also has the added benefit of having been used for a huge number of different games, so there's an additional level of refinement in the toolset that it offers, since it's had to adapt to suit so many games.
Good to hear that Godot is addressing this. The Rust graphics crates are bottlenecking on buffer management. I'm seeing the render thread become compute-bound on a static scene, with the GPU under 25% busy. Stack is Rend3/WGPU/Vulkan/X11/Linux.
The latest round of WGPU improvements now has copying content into the GPU memory concurrent with rendering. That level of synchronization has been fixed. But it's still too slow.
I dread having to learn how things work down at that level.
By the way, what's the thread situation in WASM now? Previously, it was multiprocess with some shared memory, not real threads. Various real threading proposals were floating around. Did that happen yet?
> The order of execution of the recorded commands inside a command buffer is NOT guaranteed to complete in the order they were submitted: the GPU can reorder these commands in whatever order it thinks is best to complete the job as quickly as possible.
It's my understanding that commands inside of a command buffer are guaranteed to complete in order. The synchronization must happen when you are `vkQueueSubmit`ing multiple command buffers, no? I think that's what they meant to say?
Commands are guaranteed to start in the order they are inserted into the buffer but not guaranteed to complete in that order.
Per kronos:
> Commands are also guaranteed to start in the exact order they were inserted, but because they can run in parallel, there is no guarantee that the commands will complete in that same order
Readit News
- Can't use C# at all
- Has issues running on MacOS / iOS
Meanwhile as much as Unity irritates me, they're working on even better web platform support in Unity 6 and smaller runtime bundled deployments.
https://unity.com/solutions/web
I think if I was predominantly focused on traditional console/platform gaming it would be a different story.
[1] https://apps.apple.com/us/app/atlas-fury-space-arcade-game/i...
"Godot 4's HTML5 exports currently cannot run on macOS and iOS due to upstream bugs with SharedArrayBuffer and WebGL 2.0. We recommend using macOS and iOS native export functionality instead, as it will also result in better performance."
>Currently, projects written in C# cannot be exported to the web platform. To use C# on that platform, consider Godot 3 instead.
https://docs.godotengine.org/en/stable/tutorials/scripting/c...
I guess there needed some trial-and-error in the gamedev world for about a decade to really nail down a nice to use but also performant graphics API design. Vulkan being originated from the Mantle API from AMD didn't help - since it was a low-level console API mainly accustomed to AMD's GPUs and really didn't seem like it would fit for a more "general-purpose" API spanning a huge range of hardware and can stand the test of time. And with Microsoft's DX12 hastely copying from AMD's initial design it also has all the same issues (The irony is that DX11 is still the best graphics API you can use in gamedev in Windows in terms of ergonomics and even performance - seeing many trying to dauntingly build a DX12 backend and end up performing worse than DX11...)
Nowadays I'm obversing that the industry has known these issues for a while and are experimenting with alternative API designs... there are some experiental render-graph extensions available in both DX12 / Vulkan (albeit in a limited fashion):
- DX12's Work Graph API as preview (https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre...)
- Vulkan's VK_AMDX_shader_enqueue extension (https://gpuopen.com/gpu-work-graphs-in-vulkan/)
Other parts of Vulkan are clear wins. Pipelines with their explicit state look more cumbersome than the OpenGL state machine when starting out on a toy renderer, but they are absolutely invaluable in anything slightly more complex. All OpenGL based renderers that I've worked with ended up building a state management abstraction on top of OpenGL to work around the debugging nightmare of forgotten state variable updates. Pipeline add this state management at the driver level.
I've written a detailed comment about this before here (https://news.ycombinator.com/item?id=37843946#37845431) but for a much more comprehensive explanation by an engineer from Nintendo read the initial proposal for the VK_EXT_shader_object extension: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...).
And the slightly less-official behind-the-scenes tweet thread about the background for VK_EXT_shader_object: https://twitter.com/gfxstrand/status/1641914602756644867
There's also Casey Muratori's mail to the Vulkan advisory on 2015 that basically predicts this whole clusterfuck would happen: https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_s...
It's a bit like how even the best performance-oriented engineers rarely go down to directly writing assembly to optimize their C/C++ code - sure you can do that, but excluding the rare hot spots it's mostly a waste of time. It is incredibly useful to get a debugger/profiler and observe how your code is compiled down to, but actually writing it is cumbersome and requires too much of a discipline with too many footguns.
On a tangential note: I am also excited to see whether Embark Studios will open source their engine once it's ready.
Also, indie games are a billion dollar market. Maybe it's time to stop using it as a synonym for "not serious." The consumer doesn't care that Undertale was made with Game Maker.
>There's also O3DE which last I checked isn't ready.
Literally no one cares about O3DE.
To me "indie" is usually more a reflection of budget, which heavily impacts graphical sophistication, size of the game (as in how many levels, how many hours of play, etc), and usually means the price of the game will be between $5 and $30. AAA I expect $60 and 100+ hours of playable content. Indie game I expect 5 to 6 hours and I'm pleasantly surprised when it's more. When it comes to choice of game engine, that usually means they prefer less flexibility but more simplicity and "free stuff" from the framework, whereas a AAA game might prefer maximum flexibility, but that comes with complexity. As in all things it's a budget (time & money) tradeoff, not necessarily an "are we serious" tradeoff.
There was a time when Unity was the 'indie game engine' as well. Give Godot some time (especially since it's progress seems to be picking up steam.)
> UE5 on the other hand is leaps and bounds greater
UE5 has the benefit of standing on the shoulders of giants, not to mention giant-sized pockets of cash to spend on developing it. UE has been around since 1998, so we're talking a quarter of a century of development leading up to what UE5 is today. It also has the added benefit of having been used for a huge number of different games, so there's an additional level of refinement in the toolset that it offers, since it's had to adapt to suit so many games.
That's still the case, depending on how you define indie. I'm not aware of any major AAA game made with Unity.
The latest round of WGPU improvements now has copying content into the GPU memory concurrent with rendering. That level of synchronization has been fixed. But it's still too slow.
I dread having to learn how things work down at that level.
By the way, what's the thread situation in WASM now? Previously, it was multiprocess with some shared memory, not real threads. Various real threading proposals were floating around. Did that happen yet?
It's my understanding that commands inside of a command buffer are guaranteed to complete in order. The synchronization must happen when you are `vkQueueSubmit`ing multiple command buffers, no? I think that's what they meant to say?
Per kronos:
> Commands are also guaranteed to start in the exact order they were inserted, but because they can run in parallel, there is no guarantee that the commands will complete in that same order
https://www.khronos.org/blog/understanding-vulkan-synchroniz...