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 the 4.7 official editor, which was important to me for stability and trust (also, easy extensibility).

It's free and libre open source under the MIT license. It uses libgodot and 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.

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.

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.

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

Hello, everyone! Let’s again create a spatial shader for a 3D object. This time we'll create a simple flag, make it wave gently in the wind, and demonstrate how we can dynamically control this effect in the vertex function.

I'm making a game where the player moves through an endless scrolling 2D world. Currently, I want the terrain to represent a sine wave, as shown in the provided illustration.

How should I setup my terrain scene to generate this terrain with collision? Or should the terrain generation be in the main game scene? If the later, what node structure should I use for my terrain?

In your time with Godot, have you stumbled across something useful but hard to find, like:

• Godot features
• Edge cases/issues of Godot features
• Libraries/assets
• Open source projects
• Tutorials, Guides, Blog posts

Or anything else you wish you'd found earlier? If so please feel free to share it here!

Hi everyone! Let's make something simple, because it's the beginning of July, and I'd rather relax than program overly complex shaders. We'll create a simple image warp effect that fits into a single line of code. So let’s go ahead and program that one line.

Not surprising, but glad they pick a more sensible approach than other open source projects.

Hello, everyone! In this tutorial, I’d like to return to simple effects that don’t require any image input. This time, we’ll create something like an animated nebula, which can be an interesting visual enhancement for many space games.

cross-posted from: https://programming.dev/post/52632331

Hi everyone!

I'm excited to finally share the current progress of my solo indie racing game, Asphalt Dreams, built with the Godot Engine.

After months of learning, experimenting, and improving the project, I've reached a point where I'm comfortable calling it Pre-Alpha. There's still a long journey ahead, but I'm happy to finally start sharing the game with the community.

Current Pre-Alpha Features:

• 🚗 10+ drivable vehicles • 🌍 3+ unique environments • 🚦 AI traffic system • 🎨 Vehicle customization (currently in development) • ⚡ Performance optimizations for smoother gameplay • 🛣️ Endless arcade-style traffic racing

This is only the beginning. I still have many features planned, including better AI, improved graphics, additional gameplay mechanics, new vehicles, and plenty of polish before release.

I'd genuinely love to hear your thoughts, suggestions, or feedback. Every comment helps me make the game better.

Discord Community: https://lnkd.in/gvWz2dFg

Thanks for checking out Asphalt Dreams, and I hope you'll enjoy following its development! 🚓