Hello, everyone! Let's create an effect that resembles boiling lava viewed from above, which can be useful for various top-down games. It's also a great demonstration of using four-dimensional noise and slicing it into three-dimensional layers, resulting in the characteristic flowing lava animation.

Would really appreciate any and all feedback for my cooking game. I kind of used making the game as a way to learn the Cogito framework in Godot. If you haven't of it you might want to check it out. It's pretty useful.

https://oneoverzero.itch.io/burger-stack

I am thrilled to announce that the action platformer Amata will be releasing on the 20th of August 2026! This news comes with the final feature update for the main campaign before release <3. This patch contains all the planned content for the final release, though I'll continue working on translations and any bugs that come up!

There won't be much changing between now and Aug 20th so if you'd like to jump in early then try the demo and pick up the game in EA today!

Thank you everyone so much for everything, I hope you enjoy! Come hang out on Discord!

https://store.steampowered.com/app/1841160/Amata/

Hello,

I'm trying to use Godot on Linux (CachyOS) for the first time but it keeps crashing on a specific point. There is no error message or anything, it just closes. I've been following this tutorial on Youtube: https://youtu.be/AdN27y_-UHA , at around 9 minutes it crashes every time.

I tried to record it: https://streamable.com/3fcbv8

I'm using Godot v4.7.1.stable.arch_linux [a13da4feb]

Has anyone an idea why this happens? thank youu

Over the past 2 months I've been working on a stream overlay for my streams implemented in @godot, and last night I finally got animated emotes working which has been the biggest hurdle to making the app usable on stream!

Hello, everyone! For the third time, we'll be working with a shader based on a line graph with many vertices. This time, we'll program an effect that loosely resembles a seismograph or another instrument with a similar display. It's a fairly simple algorithm and, as usual, comes with plenty of parameters to customize its appearance.

Hi all, I'm new to Godot and recently returned to my project that I have started last year. I've been trying to create a reusable button and use it in my GUI scenes. I created a separate scene round_button.tscn which has the following structure:

Control
 └─ RoundTextureButton
     └─ CenterContainer
        └─ IconTextureRect

RoundTextureButton is a TextureButton that reacts to mouse hover and IconTextureRect is a TextureRect that is meant to be an icon with texture set as an AtlasTexture. I made the following script that is attached to Control:

extends Control
class_name RoundButton

enum IconID { play, pause, back, forward, … }

const ICON_REGIONS =  [
	Vector2i(64, 0),
	Vector2i(64, 16),
	…]

@export var icon_id: IconID = IconID.play
@onready var icon_rect: TextureRect = $RoundTextureButton/CenterContainer/IconTextureRect

func _ready() -> void:
	icon_rect.texture.region = Rect2(ICON_REGIONS[icon_id], Vector2i(16, 16))

This creates a dropdown in Godot GUI which allows me to comfortably set the type of a button. It works as expected when I run the button scene.

Then I Instantiate Child Scene… in my menu scene menu.tscn to add a few buttons to my game menu. One button works fine, but when I add two or more, they all have the same icon, the last button that I added and set. What am I missing here with sharing attributes? I read that exported arrays are shared by all instances because the variables are really pointers to some memory location, but my icon_id is an enum value. To test this I have put a print statement in _ready() and it seems like the buttons have distinct values, but the icons are still shared by all of them.

https://backstitch.dev/

https://github.com/inkandswitch/backstitch/

paraphrasing one attendee: I didn't know that I wanted this

https://ghostarchive.org/archive/bxUO3

Released my first Godot Asset! A retro voice synthesizer :mycomputer:

Asset: https://store.godotengine.org/asset/eibriel/tts-079/

Try it on Itchio: https://eibriel.itch.io/scp-079-voice

Project: Hadean chronicles.

Drunk yaw. Ships were flying like they’d had one too many at the cantin: pure proportional yaw meant no drag on angular velocity, so every heading correction sailed past the target and wobbled back. Dropped a D term on angular velocity. Now they settle like they mean it.

Docking death-spiral. The behavior planner checked emergency HP before docked status. A docked ship still patching its hull got reclassified as “emergency” every tick, which silently disabled both healing and hazard immunity. Reordered: docked wins. Always. No exceptions.

The overshoot plague. Ships barreled into docks and loot at max throttle, tunneling clean through the interaction radius on pure momentum. Same thing at hazards: they started the avoidance turn fine, but inertia carried them into the danger zone anyway. One shared cause, one shared fix — STEERING_ARRIVAL_RADIUS now clamps approach speed as targets get close. It’ll tune per capture radius later, as long as it stays under 65 so combat orbit hysteresis doesn’t get confused.

Combat strobe light. A single hard distance threshold meant ships at the boundary flickered between orbit and charge — two headings ~90° apart, flipping every frame. Replaced with hysteresis: separate enter/exit radii, orbit state remembered between ticks. Stable at all ranges.

“0 units from hazard.” Every planet was screaming about a collision that didn’t exist because Position was first assigned in _PhysicsProcess, and synchronous scene-load spawns beat it to the punch. Seeded position eagerly at setup with the same orbital formula and delta=0; physics ticks just update from there.

The invisible fleet. Everything rendered: ships, sun, background, all sharing the correct World3D. But there was no Camera3D — only a leftover Camera2D from the before-times. Zero errors, zero output, zero fleet on screen. Added a proper top-down Camera3D, evicted the dead legacy background scene that was still being instanced alongside the new one, and the armada reappeared.

Tiny win. Velocity-clamp check was doing a sqrt every tick for the 99% happy path where nothing needed clamping. Swapped to a squared-threshold compare. Minimal, but it adds up.

I needed a way to embed Godot in .NET applications, and ended up facilitating HTML5 export for C# games, too, which really reinvigorated my passion for Godot in game jams. And for boring work, I needed parallel unit testing (across multiple ALCs).

But what is it...? I call it a C# front-end for the Godot engine, but really...

2dog is still Godot

All the Godot goodness still works, including programming with GodotSharp (their official C# SDK) and the 4.7 official editor, which was important to me for stability and trust (also, easier to swap out or extend).

The nuget packages are free and libre open source under the MIT license. 2dog uses libgodot and creates a choice of small .NET "host" applications that you can tailor to your needs - HTML5 browser export, embedding in WinForms, xUnit testing, etc.

Still hot off the press, always happy about visitors to the ⤜outfox⤏ discord or issues on our GitHub.

Archived footage of star system view before the global refactoring.

How global singletons were killed, async race conditions resolved, and the door for custom player modifications opened

❌ The Problem

• Development stagnation: Monolithic generation and logic controller bottlenecked project progress.
• High risks: Minor changes threatened to break completely unrelated systems.
• Cascading failures: Removing the legacy global singleton caused endless compilation errors.
• Pointer errors: Instantiating subsystems before scene tree attachment broke configuration loading ($NullPointer$).

🔄 The Struggle

• Dead-end refactoring: Trimming the singleton without changing architecture immediately broke builds.
• Rigid hardcoding: Directory paths only functioned within one strictly defined file structure.
• Modding unviability: Static paths completely prevented players from installing custom user mods.

The Solution

• Separation of concerns: Monolith split into independent submodules via Single Responsibility Principle.
• Dependency injection: Global singletons replaced with explicit, controlled dependency passing.
• Asynchronous readiness: Added scene tree checks before generation, eliminating race conditions.
• Dynamic discovery: Engine now automatically locates resources regardless of folder structure.
• Language migration: Rewrote code from GDScript to C# for efficient modular development.

Hello, everyone! In the previous video, we created a simulation of an electrical discharge using a line with multiple segments. This time, we'll stick with a similar concept, although we'll approach it a bit differently. We'll create something like an ECG monitor that displays the characteristic heartbeat waveform.

The architectural evolution of the rendering pipeline in the space 4X/roguelite hybrid Project: Hadean recently shifted from an isolated multi-viewport structure to a single, high-performance 3D scene.

The Discarded Path: The Hybrid 2D/3D Viewport Setup

The initial rendering layer nested an isolated 3D SubViewport inside a 2D SubViewportContainer for every single planet. This approach aimed to let 2D orbit physics coexist with fully shaded 3D planetary surfaces. However, scaling this architecture introduced severe performance bottlenecks:

• Lifecycle Race Conditions: Initialization logic inside _enter_tree() triggered frequent ERR_FILE_NOT_FOUND engine failures because global configuration files loaded before @onready node references were resolved. Moving setup to _ready() and caching node references resolved the issue, eliminating frame micro-stutters caused by repeated get_node_or_null() lookups.
• VRAM and Resolution Spikes: Every planet rendered its own isolated World3D, duplicating render passes and light setups. Forcing runtime viewport resizing between 64×64 and 2048×2048 via UPDATE_WHEN_VISIBLE failed to keep VRAM overhead within stable bounds as the simulated solar systems expanded.

The Breakthrough: Migration to a Unified World3D

To ensure stable VRAM usage and fluid frame rates, the multi-viewport architecture was completely dismantled. All planetary bodies now inhabit a single, monolithic Node3D scene sharing a common World3D instance, viewed through a locked top-down orthographic Camera3D that handles panning and zoom. Real-time shadows are now efficiently handled via distance-culling rather than being baked per-object.

Shading and Orthographic Lighting Refactors

Planet shading completely overrides Godot’s default PBR lighting pass for maximum performance. Custom lighting logic is executed directly inside the light() shader function, utilizing the ATTENUATION parameter for pure occlusion mapping.

Fixing the sun lighting system to track correct orbital positions under top-down orthography required three major iterations:

1. DirectionalLight3D: Produced parallel light rays from infinity, causing the day/night terminator line to twist 90–180° during planet orbits.
2. Synced Global Vectors: Rebuilding shaders to use MODEL_MATRIX * vec4(TANGENT, 0.0) isolated normal mapping from camera transformations, preventing normals from collapsing into funnel-shaped artifacts at the poles. However, directional lighting still failed to track the real on-screen position of a nearby point-source sun.
3. OmniLight3D Nodes: Spawning an OmniLight3D node at the exact spatial coordinates of the sun successfully resolved the polar vector collapse and fixed the terminator tracking.

Resolved Migration Traps

• Tree Membership Trap: Querying GlobalPosition during synchronous node setup before integration into the active scene graph caused engine failures with !is_inside_tree() warnings. Implementing explicit is_inside_tree() validation guards resolved the hidden failures.
• Unit Scaling Discrepancy: A legacy sprite-era pixel scale factor was accidentally mapped to the 3D mesh transformation, shrinking planets down to ~6 world units. Metrics are now strictly locked to canonical world-unit radius fields.

Most people seem to agree gdscript should be faster for heavy engine work, but that's not what I found.

Hi everyone! Let's create another 2D effect that we can use in a game as an obstacle or an energy weapon. We'll program an animated jagged line that resembles a lightning bolt or an electrical discharge.

Signed distance field raymarching in Godot 4, authored with nodes. Physics-driven metaballs melt into the SDF cubes in one fullscreen pass, and since every CSG op works on (color, distance) pairs, the colors blend along with the shapes.

Two free editions: Standalone shader (CC0): one .gdshader, no scripts paste onto a QuadMesh, edit map(). Godot Shaders https://godotshaders.com/shader/fullscreen-sdf-raymarching-with-smooth-csg-and-depth/

Node-based project (MIT): shapes as Node3D nodes, live editor preview, physics, up to 32 primitives and a write-up. VavLabs Mit
https://vav-labs.com/case-studies/sdf-raymarcher-godot/

Distance functions after Inigo Quilez.

youtube: https://youtu.be/Y1sd9Cx4NAs