Post

First, after visiting many conferences at the same time, me and @steinmakesgames.bsky.social finally met face to face!

It’s so nice to have another conference in Amsterdam! Though next year GodotCon may move to southern Europe instead. As Emi says: “To get some nicer weather.”

Breaking news: In a couple of hours there will be new Godot plushie available: Godette

Theatre 2 is not much different: HUGE screen!

I’ve already had some good discussions about editor design, as well as USD pipelines. For version control purposes it’s so much nicer to be able to diff ASCII files, which USD can easily convert to, from binary But remember: There is no such thing as a sensible default: gdcvault.com/play/1034261...

Editors and tools need defaults, but never ever considering those defaults sensible. Whatever you are used to as a developer of tools will not be what your audience is used to, even if they are also developers of tools.

Now watching @adriaan.games and @franzlazerte.bsky.social talk about getting started with Editor Tools, for Godot!

YEEEESSSSS

They mention it can be as easy as adding @export_tool_button to a script, which adds a button. They use this a lot for Hidden Folks. They make a function, display it as a tool in the editor, and now they can easily activate that function as a tool.

Though watch out with exposing tools, as you have to understand you are affecting both the editor and the runtime of the game. So be careful and knowledgeable about when these functions run, so when strange things start happening you know where the issue comes from.

They also found it easy to set up hotkeys to easily allow them to, for example, parent and reparent objects in a giant scene hierarchy. They then show the hotkeys in a little text tab so it’s easy to remember and use quickly. This sped up their workflows a lot!

They also found it very easy to set up such tool UIs, as the Godot UI editor allows you to set up UIs for tools as well. In this case the UI on the right is also the one you see in the tool on the bottom left.

Lastly they had headless versions of tools that only ran in-game, and not in the editor. This then allowed them to more easily debug the game, though did require a bash script to set up

Overall: They’re happy with the tools they were able to build in Godot, and it really helped their workflows, but it can be finicky to get things to not crash, or have unexpected results, and it requires experience more than anything to prevent those issues. So, their advice: Try!

After a great lunch with conversations, next is @picster.bsky.social with “Changing the Mood: Better Atmosphere for Godot Games” in front of a very packed room!

A good grain of salt to have with any talk you see. (The right answer for most questions is: “It depends.”)

(The Wi-Fi/SIM connection is very bad in here, so I’m behind on posting)

For mood and atmosphere, it’s important to make invisible things visible. Such as temperature, sound, wind, and things like that, by using dust, moving vegetation, gusts, shockwaves, etc.

This also means you need many debug options to control such invisible behaviors (cc @andrewfray.dev)

Resources work well for this.

Of course also use composition to maken it all look great. (There was a really good gif here showing a room with and without lights, which illustrated the concept very clearly. Catch the recording for all the great videos showing the concepts!)

After that, @bodybygumdrop.bsky.social is using Blender and Godot together in increasingly entwined ways: “Never Done: An Evolving Blender Workflow for Building RPGs”

David’s showing Blender as a level editor for Godot, where if you save/export in one, it reflects to the other. Thus allowing you to make edits Godot can’t do, but Blender can do.