For the game engine? Probably. In general having a better Vulkan renderer will result in better performance and correctness on all platforms. A few optimizations may be targeting the platform's strengths but I would expect the vast majority of engine improvements to be cross-platform.
For the Vulkan implementation? Probably not. IIUC Android uses a different driver stack than GNU/Linux. Only the very core layers are shared.
But indirectly more game engines supporting Vulkan will raise interest in progressing and optimizing Vulkan, so there will probably be indirect effects.
First elf/linux vulkan3D AAA games are from 2017-2019.
The problem with the desktop/laptop linux (I am excluding the deck), is msft monopoly on desktop/laptop default installation.
It is a circular dependency to break: windows gets the games because it is mass installed by default, and windows is mass installed by default because it gets the games.
Breaking that circular dependency means a saner alternative to windows to invoke the ultra-hardcore regulation which would be required. Problem, massive and mainstream elf/linux distros out there are no less-worse than windows, and are mostly hostile to binary distributions which are games (ABI stability is stellar better on windows than on elf/linux).
You need to dicipline glibc/gcc devs first (easy out-of-the-box backward ABI support in the toolchain and not that symbol per symbol version handling pain with the binutils gas .symver directive), and make more "common" software package statically link friendly or "app internal packaging friendly" (collisions of app internal shared lib symbols with system symbols).
That has been the case for 10+years and it is still so much accute with so much nothing pertinent being done, I start to think about conspiracies: I am questioning for who those glibc/gcc devs are actually rolling for...
We have quite a lot of disk space these days on computers, so we can just use functional/declarative package managers to use dependencies in any format we like, having multiple versions of the same dependencies simultaneously, if needed.
Steam/Epic/et all. could just host own package registry for games, and there is no conflict with major Linux distributions about binary distribution.
On that case developers can bundle their games as they want, and end-users just use the package manager.
If you look how Steam works under the hood in Linux, it also manages dependencies for each game separately instead of using system libraries in the most cases.
Collabora "pressure-vessel" (used by valve) is limited as it does not follow the ELF ABI for all ELF binaries, and does take of lot of shortcuts for provider software packages it must import (datafile locations, critical environment variables, etc), and if you don't have "ubuntu", you are done for: I have often arguments with one "pressure-vessel" devs because it is breaking my distro even though it is very vanilla and simple, but not "ubuntu" breaking many of their "shortcuts".
And games would like to run en elf/linux distros without "pressure-vessel" (as far as I know, is not open source), as a set of clean ELF binaries.
But there is light at the end of the tunnel: engines, like godot, unity, UE5 (I think) seems very carefull about ABI issues on elf/linux and the game devs don't need to worry about cherry picking backward symbol version, avoid symbol collision with system ones as it is done for them by engine devs.
But you have engines which expect too much from the user system, that beyond video game core libs/interface: like electron (google blink), which expects a specific version of GTK+ on the user system... so the end of the tunnel is still far away for them.
Steam provided libs seems to be from Ubuntu, but the host does not need to be? Or what did you mean.
I used to make OCI containers from games and run them in Docker/Podman, since there were a lot of GPU specific driver issues, so I could easily swap between different drivers. But I did not notice any issues when running games with Arch or other distros.
Except, not even the AAA game studios that target POSIX based platforms like Android, iDevices and Playstation bother with GNU/Linux, Android being the more extreme as all NDK APis that are game related exist in GNU/Linux.
Additionally thanks to Proton, Valve is doing nothing less than supporting Windows/XBox game studios to not bother at all, as Valve does the required work anyway.
The SteamWorks SDK, an optional component if you want to use steam features like achievements, Steam friends in multiplayer, or DRM, is proprietary. But you can use Steamworks without Proton or Proton without Steamworks.
The rest of Proton is open source and is at its core a distribution of wine + dxvk.
You'll see DLLs with names like Windows DLLs, but they come from Wine, not Windows, and are reimplementations.
I can totally see how Godot is the most attractive engine for Google now. Let's hope it stays open and doesn't end up compromised by Google spy- and adware.
Until I read what it was actually about, with the headline alone, I felt a bit of dread, worrying that google would get involved and destroy yet another good thing. Even surprised myself at how quickly my gut reacted like that.
I had the same feeling. But Godot is open, and if it's taken into a direction that the community doesn't like, I'm sure they'll fork it. And Google probably just wants there to be a good alternative to Epic and to Unity's ad framework. They don't need to infect Godot. I hope.
Google knows how to use an open project and lock-in enough features that community forking is basically a waste of time. e.g. Chromium and Android. I hate when they get anywhere near anything.
Chromium and Android were created by them, though. Godot exists independently from Google, and the moment Google starts adding questionable stuff, the community can fork without any problem.
>.NET support is provided as a dedicated engine executable. C# support is currently only available for desktop platforms in Godot 4. Use Godot 3 to run C# on Android, iOS and Web.
A bummer for me. Maybe they can also work with Google and Microsoft to improve .NET support?
I read somewhere that they will completely redo C# support as multiplatform GDExtension. Then there will be one build and all additional languages can be added as extensions. And they can be updated faster, regardless of the editor build.
Unless you specifically need a lot of the dot net library (and in this case you can probably theoretically 'just' use a plugin for access) I would encourage you to try gdscript. I went from 5 years of unity pseudo-c# to it in about 2 weeks, and I globally just find it an equivalent if not better experience for the majority of the code base.
Honestly one of my current fears is that they focus on c# integration in place of improving gdscript support (the integrated ide is not specially comfy, and static typing support still lack some feature, collection wise in particular. but nothing really awfull).
C# is a real programming language usable outside game dev, as well as transferable to other engines or frameworks like Unity and MonoGame. GDScript is usable only in Godot.
While this is true most of the structure of the language is taken directly from Python, which depending on your interests might be a little more useful than learning C#. The only syntactical differences I’ve found so far are the additions of var, const, match, how the walrus operator is used, and of course all the nice godot editor specific keywords. The built-ins have almost exactly the same naming scheme, you can still use global functions like len on any collection, I could go on…
I would argue that someone who starts programming on gdscript today would be able to transition into Python with little to no overhead.
Maybe if someone is learning their first language that's a semi-important choice but, if you already know a programming language, syntax doesn't really have a steep learning curve.
No disrespect but judging languages on syntax is a lot like judging a book on its cover. Chosing a language is, for the experienced programmer, a choice of ecosystem, libraries, tools, architecture, and also a matter of long term maintenance, evolution, technical debts. Gscript scores very low on all of these, especially compared to the behemoth that is C#. Only unexperienced programmers and sales people use the "it looks somewhat similar so it must be" argument.
For scripting I've yet to see general purpose (with the exception of Lua) languages shine where domain specifically cannot, instead usually from my experience the general purpose language adds complexity when you don't have certain built in features or structures.
Don't worry, they should be prioritizing C# but for now it is still very much a second-class citizen so your beloved GDScript gets to dictate the inefficiency of the API for more type-expressive languages.
Learn C++, use UE5++ for rendering, all problems solved (and those that are not solved are solvable). People use all kinds of garbage like C# and Blueprint to do their scripting (and more) and then they're wondering how is it possible that the performance of their game is hot garbage. Bring back higher barriers to entry in game programming!
My heart skipped a beat when I read the headline, in a scare of this being a way of saying that Godot no more because of, you know, "collaboration" with Google. Turns out these are in fact good news. I have to admit that I apparently have some trust issues here.
Very nice of Google to support Godot this way. Looking forward to a new wave of Android games with great performance and minimal battery drain.