I've been messing around with Rust and Godot myself over the past year. I think it's a match made in heaven. Sure, there's an occasional hiccup, but nothing major. Although I'm waiting on Godot 4 before continuing my project because I could really do with the better double precision float support, and I don't mind spending time on other projects while waiting.
Where did you hear that? Decent progress has been made on one of the PRs and the issue is still open last I checked. It was originally slated for the previous major/minor version but it got bumped to 4.0 last year.
Would be interested to hear if it'd been dropped because I have alternative solutions I can play, just far less convenient.
Not officially, but in recent versions it's become incredibly easy to plug in pretty much any language, so there's bindings out there that exist for almost every language. Their custom language is super easy to pick up though (superficially looks like Python but is even simpler). If you know any programming at all you can pretty much just start on Godot tutorials and be fine.
Godot really seems to be taking off lately. It would be very exciting to see a true open-source competitor to Unity and Unreal. Unfortunately I think it'll be held back on that front until it supports console builds, but still, it's quite an impressive endeavor considering the size of the team and the funding model.
> Unfortunately I think it'll be held back on that front until it supports console builds
I think the Godot devs have not been clear enough communicating about console support. There are export templates ready to use, up to date and fully working on different consoles. They just can't be offered as part of the open source engine due to legal reasons. That actually applies to other engines too. In the case of Unity, to build for Switch you need to download the required software from the Nintendo Developers portal and it's only accessible to you if you get approved as a developer. If Nintendo wishes to do the same with Godot they can do it know since there are no technical or legal impediments. Since Nintendo hasn't done it so far and the Godot team can't do it for legal reasons, it falls to third parties to do it.
One of those is Lone Worlf Technology LLC, owned by one of the co-founders of the engine, so it's as official as it can get. If you don't want to work with them you now have a second option that's called Pineapple Works.
It's not like you have to pay a company to port your game to switch from scratch. I think many people get that idea.
Edit: orthography
Edit2: Just to clarify even further. If you check the process to build for switch using Unreal you'll see that the process is exactly the same as with Godot, the only difference being that in the case of Unreal it's the same company providing the base engine and the switch export tools.
https://www.unrealengine.com/en-US/blog/launch-your-game-on-...
>It's not like you have to pay a company to port your game to switch from scratch. I think many people get that idea.
Your reply is a really good one because I totally got this impression from the other replies here! So Godot isn't fundamentally incompatible with consoles, it's just the open source part of it that is.
I think it's more just that you have to go grab the console piece separately, in the same way that Ubuntu can't include the mp3 codec as part of its distribution even though you can trivially go and install it yourself for free
> I think it'll be held back on that front until it supports console builds
It likely won't ever directly support consoles. [1]
But yes Godot is awesome and Juan is doing an extremely large public good in terms of education. I've been a gamedev for half a decade and there's still so much to learn, and godot's code base serves as an amazing resource.
I don't quite understand so I'll just invoke Cunningham's Law: Why couldn't the SFC, or whatever foundation springs up to run things, publish binary blobs for making builds? I don't see why the open source nature of the project would be an obstacle.
To make sure no one can make games for their platforms without their permission and agreeing to their terms. If the platform was open, anyone could make anything and sell it in any way they wanted - so how would they squeeze more money out of them for themselves?
If you look at the history of consoles, many are sold at very thin margins, or even at a loss, not even including R&D, distribution, etc. just purely from a component cost standpoint. They recoup these costs using revenue from the game sales and the online play features. It’s not a squeezing money kind of thing. For example, the next gen of consoles is probably going to be in the $500 range, and includes pcie4 speed 1tb SSDs. I bought one of these for my new machine and it was about $200 alone. Add in the processor, ram, motherboard, case, optical drive, etc. and these systems are not making tons of profit.
Presumably the console manufacturers would not allow this. They want more control than that and don't want licensees acting as a sort of sub-licensor and building things for people like this.
You have to sign agreements with the console manufacturers - they get to set any rules the market will support.
I dont know if we're on the same page here. It isn't a question of engineering time. It's a legal problem. It's not going to become feasible in the way ordinary problems do.
There's a couple companies out there that will port your game to consoles for you. [1]
The issue here is that Godot isn't someone you can contact to support their systems. It's an open source project. They either add it to the source, which they can't because of NDAs, or they point you to companies who have a track record of porting and publishing Godot games on Switch, PS4 and Xbox One, which they are currently doing:
It's feasible that they could do the work themselves and only allow access to a branch or patches for console to folks who have signed the NDA. This is basically how Epic works with Unreal. The Unreal source code is available for anyone to look at on github, but it doesn't include any console-specific code.
Open source projects can definitely be contacted in most cases (including Godot) and anybody can fork the project to support a given console. Vendors can publish such support under NDA.
Technically speaking, improvements to the Vulkan renderer like this are not beneficial to the two major consoles that do not bother supporting Vulkan. The console manufacturers need to get with the program if you want to have any chance of running cross-platform code on there. As long as most studios remain reliant on the small handful of middleware companies (Unreal, Unity) to supply these abstraction layers for them, then this likely won't change.
The Switch does support Vulkan but it still leads to the problem of the walled-garden and NDAs which has already been discussed here at length, and also prevents any further abstraction layers for consoles from being developed by anyone besides these approved middleware companies. If the open source aspect is important to you then I would suggest avoiding these walled-garden consoles completely.
Lightmapping is mostly a bunch of higher-level infrastructure that is mostly portable between rendering APIs, there is often some additional amount of work that has to be done per API but I generally expect it to be minimal.
I don't think the console manufacturers have many incentives to work too hard on supporting these shared APIs. Their business models make it much more valuable to provide higher performing and more specialized code that works better on their console. And that price generally ends up being pretty small and well worth it for a team maintaining their own engine. And that math only becomes more insignificant the more teams are switching to the main engines such as Unity and Unreal.
Of course lightmapping is just one part, but the major focus of the 4.0 release is the entirety of the Vulkan backend. There is a lot more code there than just this.
I don't think your second paragraph is quite true and it's only because Vulkan is already supported on one of the consoles (Switch) and has been promoted by them for years as a way to make it easier for PC developers to port their games. There are also things like MoltenVK (which was a prime motivator for Vulkan support in Godot) that prove that there is some demand AND that other companies are willing to pay the expense of maintaining it, so it's not something that has to cut into their business model or mess with other products either.
I'm actually not sure if Switch has a shippable Vulkan back-end. They've been saying they have Vulkan support for years, but at least 2 years ago there was no Vulkan support to speak of.
Even if it is now finally supported, most of the game developers I know of are using the NVN backend.
You can publish to consoles with Godot. The issue is that the console makers don't give anyone access to their API without being officially licensed developers (and signing an NDA) so there's no public export templates. However there are several companies that help with this and I believe the Godot devs do as well if you can prove you're a licensed developer.
Also, if there is enough of a market for it, someone can maintain a version of Godot as a company (like RedHat) and then you can use that version for consoles, although obviously at some cost. If Godot grows, that could be an interesting business for someone on HN.
I really like Godot. It's not as full featured as other engines but it feels very logical and clear.
NDAs and other factors prohibit a truly open source release with direct support for official console APIs. Companies like http://lonewolftechnology.com/ help developers launch on consoles.
So if I write some console APIs in my niche language (say, Haskell) and get that language building for said console..I can't share it with anyone? Or can I share it so long as the sharee also is NDA'd? (e.g. have a public stub repo where people with credentials can get free access to the private repo per NDA)
Remember that NDA stands for "Non Disclosure Agreement". That agreement could say anything. If you sign the agreement, then you are bound to it (assuming the agreement is legal). If you don't sign the agreement, then you aren't bound by it. If you manage to get your API working on a console without needing any help from the console producer, then there is no reason to sign an NDA. However, in many countries reverse engineering (even for the purpose of interoperability) is illegal... So this means that you have no way of getting your API working on the console without signing the NDA. The companies lobbying to make copyright law the way it is know exactly what they are doing...
You can only share them via private forums hosted by consoles parent companies, like siedev.net, developer.nintendo.com and similar. Direct sharing/selling of middleware/code between companies is usually fully forbidden.
It's wild to me that even just the API would be so controlled. Is it not enough that they control signing of the software? Does this not shoot them in the foot when it comes to courting developers?
Layman here, but IIUC it's the exact opposite. Nintendo in particular had massive problems with crapware and knockoff devs adopting the traditional 70s/80s PC game distribution paradigms, if you know what I mean. It was difficult to tell what was a genuine, high-quality purchase. Locking down development is apparently one of the reasons they won out over Atari. We're in a different world today, but 2/3rds of the major console market is Japanese, and the business culture there is supposedly very cautious about reapproaching things that have burnt the company in the past.
That explains why they locked their platforms down, but it doesn't explain why they need to do that at the API level. They already totally control the storefronts and all software run on a console must be signed by them. That should be enough to prevent the Atari situation on its own.
The companies hold the gates to millions and millions of potential buyers. Indies want to sell in all of them and there is no other way for them to do so.
In addition, consider that most indies use Unity/UE, which already support the consoles, so vendors couldn't compete on ease of development even if they wanted.
If Godot was overwhelmingly used by indies, then yes, you could be right.
Most indies already use Unity, which has support for all consoles. Most indies don't even know a single native API call. Unless the game needs something very special, they just use Unity API for everything.
So I guess I could share it on the private forums and link to it whenever someone is interested. Definitely a pain in the ass compared to even iOS as a walled garden.
Generally speaking, NDAs are structured such that you are allowed to share information/code/whatever with anyone else who is also covered by an NDA with the same entity.
Considering that Epic, and Unity clearly share their console API code with developers with agreements with MS and Sony it's clear that this is the case (+ or - maybe some exceptions specified in the agreements)
Console development is sickening with all the NDAs and such, so it's hard to combine their dinosaur approach with normal open development model. Console makers really should switch to the new century already and drop all their NDA garbage.
Video game consoles, especially modern ones (the Switch is an Nvidia Android tablet, the Xbone and PS4 are AMD NUCs) are fundamentally owner hostile devices. Their business model is to sell you a computer with crippled software and no ccontrol over it where programming for it requires NDA to get developer documentation.
They are a gross facimilie of computer. They waste what could be general usage hardware on restricted functionality all for the sake of maintaing total software control to extort maximum profits out of their userbase. And they can only get away with it by having their userbases - the audience they hold captive is pressure on game developers to have to submit to their rule to access their captive audience.
They are a middle men that parasitizes developers and gamers for the utility of "convenience" but its their market dominance that prevents less heinous alternatives from emerging. SteamOS was the closest we saw and even that Valve wasn't willing to invest that much into given its less profitable than the fully proprietary contemporaries.
You're missing the fact that the lower costs of consoles(and support surrounding them) are subsidized by the restrictions that you're railing against.
Take the switch, if you wanted to sell it as an "open" platform my guess is Nintendo would have to price it $75-100 higher. That's a huge shift in what consumers are willing to buy and my guess is it would be a lot less successful as a platform.
The Switch is a direct successor in a line of Nvidia tablets that were regularly priced at $200-$250. That being said, I'm not sure about its profit margin.
But I know for a fact that since launch the Xbone and PS4 were profitable. They were never sold as a loss leader.
Especially now, after all 3 have been out for years, none are losing money. They are all profitable when sold and then infinite money machines by acting as a tax on developers and consumers.
The NRE on consoles is pretty high, for the Nvidia tablets all the upfront costs of the OS have been fronted by Google and Nvidia hasn't been able to position their SoCs as a competitive processor given there have been almost no designs aside from their in-house products.
If wide open hardware and appstore was a recipe for success Android would be a clear winner. However if you want to ship a title where you get the most out of the platform and you can rely on the platform to be stable from both HW and SW perspective then curating that space seems to be a recipe for success.
It's be really neat if all the console hardware was wide open, however there's a bunch of hurdles there that tend to lead towards curated platforms being more successful.
Yes, their business model is sick with anti-competitve tactics, DRM and other despicable methods that are all aimed against users and developers. NDA is just some cream on top of the pile of manure.
Look, the tears of the world are a constant quantity. For each one who begins to weep somewhere else another stops. The same is true of the laugh. Let us not then speak ill of our console generation, it is not any unhappier than its predecessors. Let us not speak well of it either. Let us not speak of it at all.
The consoles have enough garbage as well. Like "life of black tiger" which is a bad console port of a horrible mobile game. Its trailer is featured on the official PlayStation channel even though it's apparently using copyrighted background music without permission. Nobody knows why Sony allowed this all to happen.
But to be fair the Play Store definitely has more of such low-quality games.
Yes, the quality net has holes in it, and since 1983 not all decisions were done correctly.
Yet it is still better than not having a net at all, leading to a bunch of "Hello World" games, half finished game demos, copy cats that dilute branding.
Alone on iOS there are around 3000 submissions per month on average, even taking around 50% away for updates, it still leaves us with an enormous amount of low quality games to triage, per month.
I don't buy that as a justification to create a walled-garden. Curation and quality control don't require locking everything down; it doesn't make the manual review process any less expensive.
What it does do is make it less expensive to exert total control over the associated branding. This might seem like a good thing for customers if this branding wasn't already for sale to the the highest bidder, but it is. The practice of hardware manufacturers paying for exclusives proves this.
The play store is not really relevant to what I was talking about because
it is intentionally not curated. There will always be at least one place like
this where the developers who can't afford the expensive fees to get on the
curated stores will congregate. It also seems irrelevant to me to keep referring
to the "crash of 1983" when that was very obviously caused by Atari having a
monopoly, i.e. the exact opposite of there being an open market for hardware.
I personally have avoided many game development communities for exactly the reasons
you describe — overly extreme fear of "copy cats" to the point of paranoia, coupled with way too much enthusiasm to adopt certain pieces of cargo-culted technology without considering the question of who will
support it and for how long. I think Godot is a step in the right direction, but it will take these companies time to let go of these other APIs that cost them high prices just for the privilege of being able to read the documentation. They are not immune to these price dynamics.
> should switch to the new century already and drop all their NDA garbage.
> we already have enough garbage
That's not an issue of NDAs but discovery (or lack of curation). NDAs may exist as a proxy for some companies, but that's still a separate issue that can be addressed in the vacuum.
Nobody is asking you to play the garbage. At least on those platforms you have the option to play whatever you want, unlike consoles where you can only play games that managed to secure a deal with the manufacturer.
Now if you refuse to accept how things work fine, but then do something about it instead of cursing and trolling everyone that actually have experience in the industry.
I don't know, create an association, start a movement or something else.
If no one likes the garbage as you say, it won't be hard to get people to join your cause, after all it takes one person to change the world.
From the previous discussions, it's pretty pointless to debate proper development practices with lock-in proponents. They don't get it or if they do, but they don't care, since they are after anti-user practices by design.
To me it looks more like it isn't that easy to gather people to your cause as you affirm.
After all you argue against everyone like myself, with games development experience, as apparent in several games related forums on Reddit and who knows where else, and yet don't get anyone to pay attention.
Yes I am perfectly alright defending industry practices, try to offend me won't change anything on the games industry.
If you want to change anything start a revolution, writing comments is easy.
What keeps surprising me is how angry you are against the industry, and yet are unable to do anything useful to our society besides writing rants on online forums.
After all I would expect that with such energy we would have seen you at some GDC(E) teaching us the true path, leading the way out of the slavery from game development industry practices.
Open source and consoles won't mix unless they remove the licensing (they won't). Which is why the Unreal model keeps platforms modular and has a bot to sync code back to GH.
The reality of open source in games is we need more engine sponsors from the studios running those engines in order to keep development alive.
Console driven development should also come from the studios, and they should partner with GoDot to enable packs/modules/tools.
Blender successfully navigated this with the open movies project. The game engines need a similar model.
It's not just console support, 3d on Godot is bad compare to other engines. I mean it's really not on part for serious games. It's far far behind Unity and Unreal.
It's been really enjoyable to read these progress reports. Juan is a great programmer and I admire his dedication and ability to consistently put out high-quality features and drive the project despite being the only developer working full-time on it for many years now. He really knows his stuff.
I haven't had time for it lately, but I used to participate in the Godot Wild Jam. It's a great way to connect with other Godot users and test out these new engine features. I highly recommend it for any new Godot users: https://godotwildjam.com/
I have started by following "Discovering Godot"[1] video course on Udemy, I still think this is the best place to start.
After that I have watched "Top-down Tank Battle"[2], and I highly recommend it, absolutely brilliant series of tutorials(all of the tutorials on this channel are great). Really helped me to understand all the concepts much better.
For intermediate/advanced tutorials, watch GDQuest. They have a youtube channel[3] and excellent video courses[4]. They are planning to release courses on procedural generation and multiplayer too, I'm really looking forward to watching those.
Finally, a shameless plug - I'm making some tutorials on Godot(alongside with some general Digital Art and Houdini videos). I'm still just getting started, but people seem to like them. The most popular one I've made so far is "Creating Platformer Character Movement in Godot - Wall Jumping/Sliding, Double Jumping, Dashing"[5].
One important thing I had to do to learn Godot. I started with the tutorials, but I had to re-create one of their demo games from scratch before it really clicked.
Now I'm very fluent in it, and it's been a JOY. I've been building a game in it for the last month or so and progress so far is very satisfying.
there's quite a few tutorials on youtube. i just picked up godot and i'm following one by angega studios. it's really well made, albeit a bit outdated now, but the impact of that is minimal. http://kidscancode.org/blog/ seems to be a good resource as well.
In addition to what the others have said, come join us on the discord! People are frequently in voice calls and live streams, there are dedicated channels for various issues with quick response times, and many of the authors of the resources mentioned here are present there as well.
Light maps are when you use any lighting algorithm to generate a pre-rendered texture of all the lights and shadows in a scene. The result is a big packed texture and an extra set of texture coords on all the scene geometry that says which bit of the texture corresponds to what. You can use any lighting algorithm to generate the map, but presumably something that's too slow to use in real time, and that's in some way better than your real time shader.
Light maps only work on non-moving lights and non-moving objects, but they're usually combined with light probes, which are samples of what the shadows would be like in a given chunk of empty space if an object were there. Moving objects can shadow themselves using these.
Light maps can be combined with other lighting/shadow algorithms. For example you might leave out the direct lighting from the most important lights in your scene, and use shadow maps for those instead, so dynamic objects can cast shadows.
None that I know of. Your best bet is to find a post explaining what effects are in a renderer you like (such as the Godot one above), then look up the research papers those effects were published in.
I really like democoder Smash's old blog for getting an idea of the graphics coding mindset - https://directtovideo.wordpress.com/ . Another good source of what is possible and what it's named is the yearly Siggraph Technical Papers Trailer.
But it's usually going to come down to learning the names of the techniques used and then finding the papers.
Note if the post author is here, there is a typo in the sentence "In Godot, different scenes can have their own ligthmaps and you can mix and match them however you like."
That's true in most cases, if you want to make a game as fast as possible, if it's not too ambitious, if you like the framework, and if the constraints are satisfying.
Frameworks are not so cut and dry compared to libraries. Not using a framework is not necessarily a bad idea.
Godot lets you script with native code (GDNative) and more importantly lets you access the very low level parts of the engine should you so wish, allowing you to implement advanced custom functionality performantly.
I do get your point but honestly unless you're a big studio or a custom engine enthusiast, there's very few logical reasons not to use a framework.
Exactly. Also, most of the time frameworks/Engines has the tool you need to build a game. Only in some specific technical bottle neck you need to ditch game engines and go for libraries or some in-house tools. But in that case, it would be pretty artist-unfriendly.
If I had to guess, which I do, I'd say it's probably a voxel size constraint. As long as one voxel is bigger than a perceivable pixel, all you can really do is interpolate the GI values within the voxel grid. That's is why lights moving smoothly and linearly will look slightly "choppy". It's probably less obvious in most real-world applications.
Again, just a wild guess based on watching that clip, I'm open to corrections!
I suspect the global illumination is running at a lower refresh rate than the rest of the scene for performance. I've seen other Godot demos that don't have this jerkiness.
I ended up doing a web search.
Found this comment.
“””
Godot's editor is built with Godot's own Control nodes which you can use for your games. In short, there's no external toolkit, Godot's editor is a Godot game.
“””
And from looking at a tutorial it appears to be a retained mode UI.
I believe real-time raytracing will change everything once cheap hardware can do it. It may take a while to get it on mobile, but for PC and consoles, I'm not sure all AAA in 10 years will have old fashioned light maps.
Depends on what you mean with 'lightmap' - if you mean the classic Quake 2-style slapping of colored textures on top of diffuse textures, sure, probably that wont be much of a sight in 10 years. However even nowadays (or years ago, really) most lightmaps contained more than that (e.g. at minimum you'd need directional information) and i doubt raytracing will get rid of the idea of precalculating lighting information per surface, especially as raytracing hardware becomes more programmable.
The idea is that since there are several years ahead until full raytracing hardware starts to appear, you could focus on that (and a single Vulkan renderer), reducing the manpower needed.
Meanwhile, commercial engines have to focus on current games, rasterization, raster + RT and the myriad of renderers and hardware they support.
Full raytracing is very possible sooner than we may think if approaches like DLSS 2 keep improving.
I thought you were saying they should focus on ray tracing instead of the Vulkan renderer. Saying they should build a vulkan renderer and a ray tracing renderer is a much different statement than what I was understanding, and sounds like a lot to ask for.
Additionally there's a ton of risk in betting on full ray tracing in several years. Given that they are a small team with a small community and small funding, they simply have to hedge there bets, and myself as a user am damn glad they are. Unity going guns blazing on new shit and having things be broken all the time is a huge reason why I switched to Godot in the first place.
A nice thing about godot is that it's code base is very easy to get your hands in to, so if Juan wants to focus on the big stable market with the raster renderer, the community can work on a ray tracing renderer. Juan is exposing an api called RenderingDevice in 4.0 that should enable the community to write their own renderers easier than from scratch.
> Saying they should build a vulkan renderer and a ray tracing renderer is a much different statement than what I was understanding
Raytracing is an extension on Vulkan. I don't understand what you are trying to say. I am not talking about CPU raytracers.
> Additionally there's a ton of risk in betting on full ray tracing in several years.
They are not commercial, so the risk is minimal. That is why Godot is such a good place for that.
> Unity going guns blazing on new shit and having things be broken all the time is a huge reason why I switched to Godot in the first place.
That is true and it is why most games avoid updating Unity if possible. But I feel if Godot had so many features, it would have the same problem too (or worse, given less manpower).
> the community can work on a ray tracing renderer
Juan is the one with financial support. Most people cannot afford to take on a research-heavy, multi-year project on their own.
Nevertheless, RenderingDevice sounds great for research projects and academia!
Not technically wrong, but an incomplete picture. The way that engine renderers are organized right now does not lend them well to raytracing. The Vulkan extension we're talking about requires you to set up completely separate pipelines, use different kinds of dispatches, and different shaders. Very little is compatible, and most "ray-traced" are bodged in there in a weird way -- they're mostly used for single-bounce specular AA, as we only have a very small ray budget.
I was pointing that out because the other user seemed to think I was talking about a non-accelerated renderer. However, to access RT hardware and compute capabilities you need Vulkan nevertheless (or the non-portable ways that I guess Godot wants to avoid).
My original post was precisely about focusing on such a full RT renderer (via Vulkan). I am not an expert, so it may be a dumb idea, but it would be nice to have a FOSS production-quality renderer by the time full RT becomes a thing for more and more games.
Betting your project development on something that might pay of in the future is not minimal risk, both for the project and for the people being financially supported to work on.
I bought a new system with RTX 2070 Super and couldn't get any demos with raytracing to work acceptably in either Unreal or unity... The frame rates on super simple levels were maybe 10fps at best...
I was a little dismayed. It seems like AAA games are also not making a huge amount of use of it either. Despite the RTX name I don't know if it's really ready for prime time, at all.
I have a 2070 non super. Minecraft RTX was acceptable. You can't get competitive FPS gamer acceptable framerates but you can get RPG/minecraft acceptable framerates (40ish) depending on how spoiled you are by 144+ fps feels.
But yeah generally I agree, a game that is already doing AAA amounts of gemeometry and shading, that uses RTX to good effect, is going to need 2080ti in SLI to be still a bit slow.
Current gen hardware is nowhere powerful enough for that, yeah. But for simple games a lot is already possible (like Minecraft).
DLSS 2 and similar techniques help a lot to reduce the number of rays needed. Perhaps by the time of RTX 4000 (what I meant as next-next-gen) we might be able to see full raytracing.
I have an RTX 2060. I was very impressed by the game Control. It uses raytacing and has good frame rates. It's graphics are really nice. It certainly looks possible to get good results with current hardware, particularly now DLSS 2 is as available.
Here is my tutorial on using Godot and Rust together - https://medium.com/@recallsingularity/gorgeous-godot-games-i...
Also, I'm making a space factory game. Sporadic updates so far but here is the most recent
https://medium.com/@recallsingularity/space-factory-building...
There is a Discord mentioned in there if you run into any issues with your godot-rust dev, we've got a very active development community there.
Godot also supports GDScript, C#, Python, C++ and more.