I recently switched almost entirely from Unity to Godot 4.0 (not a career game dev, I just make small/indie/itch.io type stuff) and I've been absolutely loving it. It's such a breath of fresh air. It's light, fast, easy to learn, and can do 90% of what you need as a solo/indie type developer.
The only thing stopping me from swapping over entirely and giving up Unity for good is the bug that means games take forever to load on itch.io if the user has MacOS (long enough that they think it's broken and close the tab). A majority of the games I make are educational and/or targeted at kids who are using iPads or MacBooks, and being able to link them to itch.io is a LOT easier than teaching them (and convincing the device owner) to install the game locally.
They say they're working on it (quoted below), but until then I'm pretty much stuck using Unity for a few projects still. If/when they fix this, I think Godot could really take off for the itch.io/gamejam/etc type crowd.
> As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
> We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.
I'm in a similar boat, and eventually realized that Godot 3.5.2 is still the LTS version and still exports just great for the web -- this is the example that convinced me it was time to switch:
https://yet-another-lucas.github.io/plumbing-adventure/
After I realized this, I decided to switch from Godot 4.0 C# to Godot 3.5.2 with GDScript and I've been happy ever since. I've even got it set up with a CI/CD pipeline to automatically build-and-deploy to Github Pages whenever I commit to master -- these CI/CD pipelines are pretty sweet.
This was a while ago, he recently put out a ton of new tutorials for Godot 4, good stuff for quickly getting your hands dirty. You're beyond that point I'm sure, just throwing them out here for anyone else looking for nice intro content.
Thank you for the link! I didn't make the linked example -- my work is MUCH simpler than that. :D This was what someone else built and packaged and convinced me that this performance is finally rivaling the Flash experience that I've been missing for so long.
I would say Heartbeast's courses are overall much better than your typical tutorial content, primarily because they are structured and built like courses rather than tutorials. I paid for a couple of his courses a while back after doing one of his free ones and do not regret it, they were excellent.
I've built 5 small browser-based game-jammy games (e.g. nothing that took me more than ~2 weeks) in Godot 3.5 this year[1] and have largely enjoyed the experience - I'll echo other folks and say that you might just be happy using Godot 3.5 until Godot 4 has functional web exports.
Godot 4 _does_ come with some language improvements that I'm excited about, particularly around better typing support and fewer places where you need magic strings (e.g. you can refer to signals by name!) - I suppose if that's a big sticking point for you (totally reasonable!) then waiting might just be better.
I will say that at times I've been frustrated by the Godot 4 team's perspective that the MacOS breakage is a Chrome bug and not a regression in Godot[2]. It's really a question of semantics and prioritization more than anything but it's hard for me to not see the behavior as a regression when a feature that I rely on in Godot 3 is broken in Godot 4.
That said I'm very grateful for all the work that's gone into Godot 4 (and prior versions) and I'm very excited for the day that I get to use it!
> Browsers with bad WebGL 2 support, such as Chrome on macOS.
This caught my eye. I haven't run into any WebGL2 problems so far on Chrome/macOS, would be interesting to know what specifically those problems are (however I'm also staying away from some WebGL2/GLES3 features which are known to cause trouble not just on WebGL2, mostly uniform buffers and generally some buffer update patterns that work well on native, but not on WebGL (such as 'buffer orphaning').
Any opinion on the state of VR on Godot? I’m using UE4 which I have 9 year’s experience in and not the biggest fan of Unity but would be curious to try out Godot.
It’s a dream compared to UE. I tried on and off over a couple years to power through building some toy VR apps in UE and was never really able to make much progress past their prefab maps. It’s just so freaking complex that, IME, the fun of the process gets crushed under the weight of making zero forward progress.
As I started a NixOS immersion program a few months back I was looking for a new platform that I could do 100% of my dev on Linux. Ran into godot searching vids on YouTube and was really impressed with the workflows so I installed godot and steam (home.packages = [ pkgs.unstable.godot_4 pkgs.steam ]). With openXR support built into godot 4, it automatically picked up the shared lib that stream dropped and in under an hour was walking around using my index and Vive in a VR env and could also build a package for my son’s quest.
Within a month on-the-side I had built a tabletopesque tank battle game with a custom ray-based suspension over high poly terrain, particle effects, ballistic artillery, and a unique controller input scheme based on the tilt of the controllers (left for body rotation, right for turret). The physics engine is great, rocking the body on fire was simple as an inverse impulse of the shell spawn vector, and the body properly rolls under both lateral and longitudinal axis by virtue of the damped shocks.
All that to say, I think the biggest difference is that with godot 90% of my effort, code, and time was spent writing implementation code for my game while on UE it was spent writing integration code.
You obviously miss out on hot topic things like nanite et al, but I learned a long time ago that fidelity has no correlation with an engaging game. The other con will likely be around performance, it’s passable at 90hz, but if you want to start hitting framerates like 144hz, the critical code will probably need to drop to C++ using GDExtention.
I’ve also noticed that, with the popularity gaining in gltf, that it was rather trivial to find quality assets with native support.
I just very recently started working on a VR game in Godot and the setup was very easy. They also have a project where common parts such as teleporting are implemented, which I didn't try yet, but which seems cool.
I'm a macOS user who makes games using Godot and publishes them on itch.io, and I haven't experienced this issue. Can you link to an example where this occurs, and provide some information on how the build was exported?
This is definitely a known issue that I've personally experienced but is even listed as a warning on the docs[1].
> 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.
> Godot 3's HTML5 exports are more compatible with various browsers in general, especially when using the GLES2 rendering backend (which only requires WebGL 1.0).
Web exports are essentially unusable for Mac users. It's the biggest complaint I get from my games using Godot 4.x.
I have both installed and am migrating a game between them now. I don't believe I've actually exported the 4.x version for using the HTML5 profile just yet, so I'll have to give that a go.
It'd be worth your time before you get too deep. The two issues that I ran into:
* CORS issues -- deploying on some sites (esp. gitlab and github pages) runs into issues because of shared buffer requests.
* Assuming you get past the CORS issues, there is still extremely slow load on OSX Chrome -- the app eventually loads, but holy smokes it takes forever.
Both of those nearly made me give up on Godot, but I'm very happy to stay with 3.5.x until those get resolved.
Thanks for the information. I am mostly migrating the game to get a first-hand idea of some of the changes I'm most likely to run into while developing the next one.
I, too, am happy to stay with 3.5.x. It works pretty well for my purposes, though hopefully 4.x will be a viable option for me soon.
> I recently switched almost entirely from Unity to Godot 4.0 (not a career game dev, I just make small/indie/itch.io type stuff) and I've been absolutely loving it. It's such a breath of fresh air. It's light, fast, easy to learn, and can do 90% of what you need as a solo/indie type developer.
There were concepts I've used in Unity that I didn't really understand until I'd rebuilt them in Godot. Everything feels more lucid on that platform. If nothing else, it's the best Unity tutorial on the market.
It's worth noting that Godot 4 is using actual .NET instead of Mono, so you get all the tooling support that implies, including seamless debugging with Visual Studio, etc. Unity has been promising that transition for years, but I'm pretty sure they're still using some customized version of Mono.
So you can write a game with .NET 7 and everything is great. There's a little bit of extra overhead when making calls into the Godot engine, so you still may want to use bits of C++ for performance where it matters, but otherwise there are only a few rough edges left.
Unity wants to transpile it to C++ code. IL2CPP where they take the IL code of your C# and translate it into C++ for speed. So yeah, not only are they NOT using dotnet tooling but they are going the opposite direction.
It works relatively well, and actually better than in Unity (which use an older C# version), but unfortunately it does not work everywhere. For example, it's not possible to export to the web, which was to me the main show stopper. I needed C# due to some libraries, and I needed that it runs in a browser, so that was game over, no pun intended.
Apart from that, I really preferred Godot over Unity. Faster, more consistent, better learning curve, etc.
Are you sure it can't export c# to web? I would have assumed that as true but Godot's documentation does not list that as a limitation, and in fact offers c# code on how to use the JavaScript interop, something that would be pretty meaningless without support.
> Note that as of this release projects made with C# still cannot be exported to mobile and web platforms. We are working on providing the support as soon as possible, but the resolution of this limitation will likely depend on the release of .NET 8 at the end of 2023. This means that the work on enabling mobile and web platforms can only truly start later this year.
It's still a bit janky compared to their own GDScript, but C# is supported yes. Because there are two languages though, and C# is the second class citizen, you won't find as many examples on how to do things in C# as in GDScript.
Thanks for the input. Given my background, I think I can figure out the syntax just fine if necessary. I am just sceptical of languages where typing is not strictly static (and I give a hard pass on pure dynamic typing).
FYI a lot if not all of the core docs actually have tabs on any code samples to switch between c# and gdscript so while tutorials from third parties tend to focus on one or the other, the core docs are a bit better.
I've started going through a tutorial on youtube from I think finepointCGI about a horror game in Godot, he is actually doing it twice, once with GDScript and once with c#, so if you want to see someone with some godot experience using c# give it a look.
> ...who are using iPads or MacBooks, and being able to link them to itch.io is a LOT easier than...
The instant game streaming service I develop targets Unity (see https://appmana.com/watch/virtualtestdrive for an example) and I was considering supporting Godot. But it would probably make more sense to fix web exports.
Other than time and money, what obstacles did you face contributing a web export fix for Godot? I am not saying that you should, but I'm sure it crossed your mind.
In the game services business, it's my opinion that in order to thrive, you target people who pay. Because Unity costs money, it attracts developers who pay. It's the halo effect. I wonder how the Godot ecosystem attracts developers who pay.
The only thing stopping me from swapping over entirely and giving up Unity for good is the bug that means games take forever to load on itch.io if the user has MacOS (long enough that they think it's broken and close the tab). A majority of the games I make are educational and/or targeted at kids who are using iPads or MacBooks, and being able to link them to itch.io is a LOT easier than teaching them (and convincing the device owner) to install the game locally.
They say they're working on it (quoted below), but until then I'm pretty much stuck using Unity for a few projects still. If/when they fix this, I think Godot could really take off for the itch.io/gamejam/etc type crowd.
> As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
> We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.