godot

Yes it's here: https://github.com/godotengine/godot/pull/72883 . Looks like it lost a little momentum in the past few weeks but it's working for people and there is a path forward to getting accepted by maintainers. It's also on the DotNet contributors meeting agenda for tomorrow..

Godot v3.2 added Android C# support, and Godot v4.2 (due out in November) is enabling both .net 6 and .net 7 support for the engine. From the Godot 3.2 docs on C#: > Exporting Mono projects is supported for desktop platforms (Linux, Windows and macOS), Android, HTML5, and iOS. The only platform not supported yet is UWP. And from a recent Github discussion for 4.2: https://github.com/godotengine/godot/pull/73257

This often-repeated statement doesn't really communicate how the editor works. While it does use many of the same APIs, you couldn't build the editor from within the editor (bootstrapping). The editor itself is largely written in C++ and not Godot's integrated language GDScript, you can see for yourself https://github.com/godotengine/godot/tree/master/editor

There's currently an issue in Godot 4 where web exports on macOS just cause the browser to hang. Their advice seems to be use Godot 3 or wait until it gets fixed in the browsers. See https://github.com/godotengine/godot/issues/70691 for details.

There's always the source :) It's easier to follow if you git clone and open it in vscode. Here's Main::iteration - https://github.com/godotengine/godot/blob/e0f644a48da49843ad...

They seem to have implemented everything that the "bistro" scene calls for. I don't know if those hanging colored lights emit light, though. Rend3/WGPU doesn't handle large numbers of light sources yet. But you wouldn't see them in daylight anyway, because this is high dynamic range rendering, and, as in real life, those light are dim relative to the sun. Here's the same scene in Godot.[1] This was modified a bit, and has accurate values for the lamp illumination. So they are totally washed out by the sun. And here it is in several other renderers, with a video.[2] The original scene was in .fbx, from Amazon's "Lumberyard" project. [3] That project started as the Crysis engine, was bought by Amazon, spun off as open source, was renamed Open 3D Engine, and is still getting Github changes, so it's not dead. There are many open source game e

After a week of faffing I managed to fork the three repos Simon made and upgrade them from 3.x to 4.x . Very untested and maybe there's stuff there you don't need. But by gum it works! I'll slim it down in the future, and remove echo messages. Big thanks Simon for your work! Parent action: https://github.com/North-Street-Games/nutshells/blob/main/.g... (attach this as a main.yml file in your GitHub actions workflow folder, and change the in-file variables and your secret itch.io butler key as needed!) Child Godot export action: (for ref) https://github.com/Kwpa/godot-html-export/tree/main Child itch upload action: (for ref - no different to original) https://github.com/Kwpa/itchio-butler-upload Note that 4.x Web builds currently do not run well on MacOS browser apps :/ See this: https://github.com/godotengine/godot/issues/70691

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

Probably this one: https://crbug.com/1324296 Linked from here: https://github.com/godotengine/godot/issues/70691

Yeah I tried to participate in a Ludum Dare jam shortly after 4.0 came out and was hit with the web export issues. Here are some issues worth tracking: https://github.com/godotengine/godot/issues?q=is:open+is:iss...

The binaries produced just for the engine itself (so exluding the game code and assets) is already several MB large when compressed with brotly or gzip [1]. So it works, but it's too large to be competitive enough on web games portals. Most players will just go play another game if it takes too long to load (download). Only JS based game engines and to some extend Defold are good enough in this regard. [1] https://github.com/godotengine/godot/issues/68647

Faolan-Rad and I (fire) are working in that area https://github.com/godotengine/godot/pull/72883 "LibGodot is a system to allows Godot to be compiled as a library and connected into it using GDExtensions by giving a function pointer to the entry point of a GDExtension implementation"

There's an ongoing discussion at [1, 2] which highlights an important difference between GDNative and GDExtension in terms of what the developers expect them to be used for. A lot of people were using GDNative as a way of writing game logic in other programming languages (particularly I've seen this with Rust), but GDExtension seems to be designed to allow people to write editor plugins (e.g. things like a voxel node type, or a custom GUI tool). Each pligin currently seems to provide a custom Node in its own right, not the ability to hook into existing nodes. This is why at the moment, you cannot live-reload a compiled GDExtension library, as the assumption is that it's a product that being provided to the user of the editor, not something which the game developer is directly creating. I think there might be some mechanisms/hooks to allow