Godot is one of the most awe inspiring open source projects out there. It's vast, but yet so well documented, user friendly, and incredibly well maintained. If you're thinking about using Unity for something, but was weary of the business model, Godot will surprise you.
I actually gave up on Godot early last year because of frustrations trying to get basic in-or-under-documented things working. Even simple things like getting 2D sorting working correctly so that sprites overlap correctly was surprisingly hard (documentation said to enable y-sort flag, but in reality there were some gotchas that took me a long time to figure out). It’s a nice engine and it’s constantly improving, but it’s not really as user friendly as people make it out to be (or at least it wasn’t in early 2018, it might be a lot better now on that front). I even contributed to GDNative so I was somewhat bought into it, but in the end it wasn’t worth it for what I wanted to do. I’ll probably check it out again in the future (for now I’m too busy with non-gamedev stuff)
I gave up two times but I wanted to learn game development and I'm planning to spend the next 10 years into it. I thought Godot is my correct choice but the docs are hard to read I agree but lot of youtube tutorials out there and at this point YouTubers covered pretty much everything to create AAA or platformer game.
It's often easier to just try random things and see what works than to find answers in the documentation. It usually does not miss topics or tutorials, but the API is incomplete.
The good part is that API documentation is the easiest one to create. The troubling part is that API documentation is the easiest one to create...
I was bitten by navmesh merging in 3D, say you have several loaded scenes, each with a navmesh. If the navmesh points are matching up to an undocumented degree, the navmeshes will be merged. This is dependent upon the scene own Transform, as floating point will yield slightly different float results depending on how the navmesh point are transformed to world space. I ended up generating navmesh from an apriori description instead of Godot scenes. "optimized" path-finding into these navmesh was surprisingly poor too (considering a lot of the rest is great).
The problem is that none of the problems are documented.
I believe there is a lot of financial support from gambling / casino gaming companies - where the entire source code is required for auditing purposes, and solutions like Unity are just unsuitable given this constraint.
The irony of creating opensource to improve the world freeing it from private-only alternatives only to be majorly financed by one of the worst parts of modern society: instant online money gambling
Would absolutely love a pointer to such auditing requirements. Very interested in how they are specified as well as what entities are driving the requirements (state law, insurance, casinos, ?).
Ah, yeah. Found this now(1). Awesome to see when open source financing actually works. And amazing that two full time developers (and non paid open source contributors) can compete with the financial muscles of Unity.
It was originally a commercial engine so it was used to build commercial games. Then they open sourced it. Now its funded by patreon and it looks like the lead devs have consulting companies for the engine itself.
Their subscription model gives Unity the ability to change the TOS under dev's feet. [0]
Unity eventually walked back this change after a prolonged negative press campaign on Twitter, but counting on Twitter mobs to solve your future problems is a really bad business strategy.
I occasionally use closed-source programs for development, but I don't use programs where the output is constrained by a license, and I don't use programs where the TOS that binds me can be changed on a whim. I'll use a closed-source program like Aseprite or Reaper, I won't use Creative Cloud or Unity. The benefits aren't worth the risk.
I've been messing around with Godot for a hobby project over the past week, and I've been pretty impressed with it so far. After using it for a bit, I think it'd be interesting to see more non-game applications written in the Godot engine. It's simple to export your project to other platforms, and being a game engine, it has all the graphical customization the web devs say they use electron for. The built-in Godot IDE is actually built with Godot. Another benefit is that it has a C compatible API, so it's fairly simple to write CPU intensive tasks in a more performant language and call them from the included scripting language.
I've heard of people using Unity for cross-platform apps, and it seems absolutely crazy to me. I mean, if they have some really clever modularization which would allow you to skip shipping all the "game engine" components then maybe this would make sense, but if people don't like shipping electron apps because of how heavy Chromium is, then shipping a physics engine and a PBR renderer inside your "ToDo" list app seems absolutely bonkers.
This is looking really nice. I'm a bit sad that Godot crashes on my kids' MacBook Air (apparently there's a bug in the URL filtering subsystem that takes down the entire OS when Godot tries to reach its library - see https://github.com/godotengine/godot/issues/24890 for details)
Apparently they fixed a UAF there in the last release of macOS, then introduced a double free in the same file in the next release.... and they still haven't fixed that either.
Apple are negligent, and they hope their customers are stupid or loyal enough to think they're doing their best.
I guess you weren’t around in the 90s. I recall the times when a single application bug would bring down the entire operating system, forcing a reboot. Ahhh, those were the days!
That’s news to me! I haven’t had an operating system crash (kernel panic) in 2 years, and I think that was caused by a sharp bump sustained by my laptop when taking it out of my bag, not a bug.
Weirdly, iOS has been pretty smooth for me (despite a one or two embarrassing bugs, like Smart Invert barely working for long), whereas the state of Catalina on release is a cause of concern..
I exaggerated, for sure, but I have been encountering a ton of bugs. Off the top of my head, cropping screenshots often doesn't actually crop them (I have to do it from the photo gallery instead), on iPad OS, the dock icons for open but backgrounded apps often stops working, I've had apps crash (especially Safari), generally buttons and things not working. Stuff like that.
I haven't actually used catalina, so can't compare.
They also seem to not care about extreme monolithic coupling in their operating systems. I can't tell you how ridiculous it seems to me that I've been able to crash iOS during WebGL development (for as long as it's been supported), setting aside the general misbehaviour of their drivers. It is extremely silly, they clearly do not gain any performance from this coupling: The component that Godot triggers a bug in, IPC, is extremely slow on Darwin, when compared with basically any competing OS.
I get the impression that Apple only does manual integration tests, only on mainstream features, and then they cross their fingers that other users don't have such a bad experience that they lose a customer.
When my new company starts developing an iOS application, I think we'll spend as little time on macOS and XCode as possible; try to build and test our core on Linux like we do for everything else.
Apple’s code quality is way down. The OS has become more complex and distributed due to ambitious projects like userspace drivers and the separate “T” CPU that manages Touch Bar and security functions; yet they don’t seem to invest in stability versus churning out a release every autumn, damn the bugs and torpedoes.
For me, Mojave on a 2017 15” MBP crashes hard about once a week. I remember Windows 98 being roughly as stable. It’s immensely disappointing.
My father in laws windows laptop doesn’t crash, but slows down so much it’s unusable every windows update. He gave me his laptop to fix it recently and it took 6 hours to get the update through before it sped up again. We’re buying him a used MacBook now
My Windows PC at work didn't have a working start menu and task bar for about 3 weeks. Since the newest update I can at least use them now but search is still broken.
It's a known bug and the only workaround right now is to re-enable Bing search in the start menu which I cannot do due to company policy.
It's still not stable. I see lot of lagging when I click the online Godot asset library and the Editor itself goes to Not Working state when I tried to close it.
One of the hopes of Vulkan on Godot is a higher performance API on mobile. Apple is a sticky company to develop for and it isn't practical to have direct support for metal, but moltenVK might allow for vulkan based games to run on it. If this abstraction really is possible then vulkan seems to be an excellent choice for supporting multiple platforms. I'm nervous about it happening until I actually see it happen. There is also not very much discussion on this front, even though it must affect many people trying to make games for mobile.
Because professional game developers prefer to use native APIs for the ultimate performance on each target hardware.
The actual 3D API is a tiny part of the whole game engine, so every professional game engine has pluggable backends anyway.
So while it isn't practical for Godot, all major commercial engines like Unreal and Unity do support Metal.
Also in spite of Switch being the only console with Vulkan support, around 50% of the titles are done in Unity using the NVN API.
Also Vulkan keeps collecting extensions, slowly it won't be any different from OpenGL with multiple code paths for OEM, graphics card model, depending on which features one is trying to take advantage of.
> Also Vulkan keeps collecting extensions, slowly it won't be any different from OpenGL with multiple code paths for OEM, graphics card model, depending on which features one is trying to take advantage of.
API-level fragmentation is an inevitability as long as GPU vendors ship hardware with different feature sets. It might be harder for graphics programmers, but I suspect consumers don't want to live in a world where graphics advance at the pace of the lowest-common-denomenator hardware. Still Vulkan takes a much more sensible approach to extensions than OpenGL, and it's far and away easier to avoid unpredictable results on Vulkan than OpenGL.
I think long-term it would make sense for Godot to support Metal, but if they are supporting Vulkan anyway, it would seem almost silly not to support Apple platforms almost for free using MoltenVK in the short term.
> Apple is a sticky company to develop for and it isn't practical to have direct support for metal
Why is it not practical to have direct support for Metal? Honest question.
You get access to a market of over a billion devices across desktop, phone, tablet and TV, with iPhones and iPads having some of the best graphics performance in their class. Even more important for developers, Apple platforms generally have a much higher percentage of users on their latest OS versions than Android etc. Why wouldn't you want to get the most out of that by using their native API?
You can get pretty far just by adopting SpriteKit/SceneKit which use Metal under the hood. 3D is outside my ken so I haven't measured the performance for that, but for 2D even my sloppy pet project [0] could update 3000+ sprites every frame at 60 FPS on the 2 year old iPhone X. You can even mix in SwiftUI without affecting game performance! (that I can tell so far.)
This is a case where adding one feature adds a 2x scaling factor to your test plans. Add a game effect? Now you need to test it in Vulkan and Metal which means two test computers, twice as long to run a test, etc. It's just a logistical nightmare.
It makes even less sense when there are shims like molten which will translate for you. No need to run all of your test plans through their shim. Just a subset will do since they're likely testing their code.
You haven't eliminated it but it doesn't scale your workload the same. You'd likely be fine with having a tester play through your game on molten. In any event it is still much less code and testing than supporting multiple backend APIs.
It's not practical to have direct support for Metal because nobody who wants it is volunteering to write and maintain a new backend for it.
Godot is a project with limited resources and the Vulkan backend works fine on Apple platforms through MoltenVK, so as far as the people doing the work are concerned there's little point in adding Metal support and lots of other things are higher priority.
This is not a question for me. It's a godot decision. They seem to know what they're doing and have claimed that platforms that use metal are "not used very much".
They talk about macOS, "a platform not used very much" (despite there being over a 100 million users the last time someone counted), not "[all] platforms that use Metal" which also includes iOS/iPadOS and tvOS.
> Still, the lack of support on macOS made it unappealing. Having to write a Metal backend to support this OS is a lot of effort for a platform not used very much.
It seems with MoltenVK, Vulkan would use Metal anyway?
> MOLTENVK GOES OPEN SOURCE
> However, today, in a completely unexpected turn of events, it seems Valve has found an arrangement with the developers of MoltenVK (the commercial and proprietary Vulkan over Metal wrapper), ported Dota 2 to it, and got it open sourced.
> It seems to be a mostly complete Vulkan implementation that runs on macOS and iOS. This pretty much lifts the only barrier we had for moving Godot to it.
Yes and that is the last they’ve said about metal support. Mixed signals about its importance. It’s unclear how important it is to the godot development team and if it isn’t important it might simply not happen.
It's not quite there yet, but WebGPU will soon be a very good option for doing cross-platform 3D work. Using the native implementations you can run modern GPU code on Vulkan, Metal or D3D12.
Vulkan is already a very good solution for cross-platform graphics. It's possible to target Windows, Linux and Mac using Vulkan.
WebGPU is interesting, but I doubt that it will ever be able to compete with native graphics API's on pure performance because of the security considerations it has to take into account. I'm glad we will have a more capable alternative to WebGL, but it would be a shame if computer graphics were limited by the limitations of web.
The native implementation are generally planned to have options to turn off the more expensive security functionality.
WebGPU is also a much more ergonomic API than Vulkan. And as far as I know, there is no Vulkan-to-D3D layer, so you are relying on your graphics card manufacturer to supply a good enough implementation, which has not worked out great in the past.
> WebGPU is also a much more ergonomic API than Vulkan.
I really doubt that a JS/Typescript API is going to be better for graphics work than a C++ API. Game developers need every bit of performance available. They're not going to want to embed web technologies and the overhead which comes with them in their native apps.
It does have vec3, mat3, mat3x4 and the camera does have things like raycasts.
It's been a few months since I tried godot so I forget all the missing math stuff that made me give up, but I remember there were a bunch of small annoyances due to the lack of mat4/vec4 like unable to use homogeneous coordinates
