Chaos Computer Club - recent audio-only feed

Let's wrap this year up!

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/WS9E8T/

I spent months inside Godot Editor's source code, rebuilding it into a multi-scene editor called GDstudio. Along the way the editor taught me a lot about Godot itself, and this talk is that story. What is a singleton, really? Why is the whole 3D editor a panel? What is a Node under the hood, and what does all that machinery cost? I bring Tracy measurements to answer that: instantiating just the editor's GUI takes seconds, and the editor is built from the same nodes, Controls and resources your game is. You will leave with practical performance knowledge for your game, and a few what-ifs about where Godot could go next.

Godot Editor is a Godot app itself, probably the largest one ever written. I spent months rebuilding it into a multi-scene editor with a profiler running the whole time, and this talk is everything it taught me about Godot.

We start with why Godot is genuinely useful for the industry, how GDScript and Godot formats like gdshader quietly form an open set of standards, a precious resource we should make good use of.

Then we crack the editor open. Why is the whole 3D editor a panel? What is a singleton, really? What is a Node under the hood? Objects created in heap space pointing at other objects, talking through signals, enter tree and exit tree callbacks, script override checks along the way. That is a lot of machinery for a separator line in the GUI. Is it good or bad? Let's find out. Tracy measurements: instantiating just the editor's GUI takes seconds, one theme change walks the entire Control tree, and entering or leaving the tree has a cost of its own.

The same costs appear in your game, because gameplay logic runs on the same nodes. So there is a practical section: theme, tree lifecycle, and the resource cache, which will quietly load your resource from disk again if you are not paying attention.

To close, some what-ifs. What if Godot's data model became an open specification, and anyone could build their own tooling against it? Where could Godot go from there?

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/CHMGZR/

Shaders can be scary, but shaders make many things possible.

During the talk I'll show various shaders used in production games.

I'll show how to write from scratch your own effects.

Static VFX, shader based animation, and even gameplay mechanics.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/KJFJWN/

In this talk, we will dive into our experiences switching from Unity to Godot when you have customers where Security, IP, and Continuity are critical priorities.

Our product is a multiplayer shooting simulator developed on Unity and Photon. We will share our experiences finding and evaluating replacement products for all elements, and offer good advice on how to work with large corporate and government IT and procurement organizations to get such a fundamental technical switch approved and successfully implemented.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/CYQXPS/

Your game features a devastating, hyper-realistic flamethrower, but your audio budget only covers a glass of tap water. Is that enough? Absolutely.

In this 50-minute crash course, we will strip away the mystery of professional sound design and explore the bizarre reality of Foley. You will learn the core theoretical principles of how audio functions in games, the accessible tools required to capture it, and the precise processing tricks used to completely transform mundane household sounds. We will walk through a concrete case study where we turn a basic water tap recording into a roaring weapon of mass destruction - giving you the exact knowledge needed to record and design your own custom sound effects without the massive studio overhead.

Sound design is fundamentally the art of illusion. This session is designed for solo developers and indie teams who want to stop relying on repetitive asset flips and start taking matters into their own hands… or ears.

We will focus on practical takeaways, essential tools, and processing techniques that developers can immediately apply to their situation.

**What we will cover in this session:**

• The function of Sound: Understanding exactly why we use sound in games (from providing crucial player feedback to guiding attention and simulating a believable reality).

• The setup: A practical look at the essential software (like Reaper or Cubase) and hardware needed to start recording, including understanding microphone polar patterns, managing levels to avoid clipping, and the golden rule of leaving 12dB of headroom.

• The tools: The core of the talk. We will break down the four pillars of sound manipulation:

o Equalization (EQ): Removing problematic frequencies and sculpting the sound.

o Compression: Taming dynamic range to make sounds punchy and energetic.

o Reverb: Simulating physical spaces and creating surreal magic effects.

o Pitching/Stretching: Altering the perceived physical size of an object simply by changing its pitch.

• Case Study - The Water Tap Flamethrower: A step-by-step breakdown demonstrating how layering and processing techniques can transform the sound of rushing water from a kitchen sink into an aggressive, dynamic flamethrower effect.

**Target Audience:** Indie developers, programmers, and generalists looking to build foundational sound design skills and elevate their game’s audio quality on a budget.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/LHKY7Z/

Our dialogue tool, Yarn Spinner for Godot, has been built on C#, and we love it. Godot's C# support is fantastic. But we wanted every Godot developer to have great dialogue, so we rebuilt the whole runtime in pure GDScript too. Now the same Yarn script runs identically in both. This talk is a joyful tour of how we did it, what it taught us about GDScript, and everything else we learned along the way.

Much of the GDScript tutorials, documentation, and advice comes from gameplay code. But we got to take it somewhere new: a bytecode virtual machine, protobut, a stack, a variable store and a localisation system. And it was a blast!

In this talk we'll cover

- Bringing a C# runtime across to GDScript, and the surprising places each language shines.

- Making GDScript appropriately fast for a job it isn't usually asked to do.

- How typed GDScript shaped the design for the better.

- Plugging straight into Godot's TranslationServer for localisation.

- Parity testing: how we keep two runtimes in lockstep from shared test scripts.

- Why supporting both Godot languages is worth it, and how to do it for your own plugins.

- And more secrets and tips on using Godot for narrative, and building narrative engines!

You'll leave with practical patterns for performance sensitive GDScript, a testing approach you can use on any project with two implementations, and hopefully some excitement about what both of Godot's languages can do.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/7QH3NL/

Audio accessibility is often treated as an afterthought - or even reduced to a lonely volume slider -while sound design plays a crucial role in gameplay legibility, inclusion and immersion.

The good news? Some of the most impactful audio accessibility features in Godot take no time to build and cost little to no CPU overhead. So let's hear what they are!

In this talk, sound designer and gameplay audio programmer Max de Kroon presents a fast-paced practical approach to building accessible audio systems in Godot. We will move from upgrading our basic single-slider settings to actionable techniques like dynamic bus routing, low-overhead EQ profiles, contrast-complete UI feedback and sound customization for the sensitive ears.

Grounded in real-world production learnings, this session provides a practical checklist of built-in engine features and an open boilerplate that you can immediately implement in your next project to make it playable, audible and enjoyable for everyone.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/SPVYA9/

Mobile games are often associated with aggressive monetization, dark patterns, and disposable experiences. But does mobile really have to be that way?

I’m Leon, creator of LOOTFALL, a retro-inspired RPG that has grown into a Top 50 iOS RPG in multiple countries, with thousands of daily players and a community that genuinely loves the game.

In this talk, I want to share what I’ve learned building and monetizing a mobile game in Godot without relying on the practices mobile games are often criticized for. I’ll also dive into the technical side of building a fairly complex mobile game with Godot, including the tools, systems, and performance challenges involved in using an engine that isn’t always designed with mobile-first development in mind.

The talk combines three areas: game design, business, and technology.

I’ll use LOOTFALL as a real-world case study to discuss how meaningful progression, long-term systems, and player-friendly monetization can coexist with a sustainable mobile business.

On the technical side, I’ll cover how I built and shipped LOOTFALL with Godot, including mobile performance optimization, memory and loading considerations, handling large amounts of UI and game data, and some of the challenges of using Godot for a relatively complex mobile game when many parts of the engine and workflow are not specifically mobile-first.

The talk is aimed at developers interested in mobile development, Godot, sustainable (and fair) monetization, and building games that players want to keep playing (live service).

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/T78FZV/

Amnios is a free narrative game about pregnancy, childbirth, and early motherhood during migration, built in Godot and co-created with migrant women, hospital clinicians, and the ICRC. This talk walks through how a research-creation methodology shaped the game's narrative, art direction, and puzzle mechanics — and what it actually takes, technically and ethically, to turn lived testimony into a playable experience.

Most "games for good" struggle with the same tension: how do you build something emotionally honest without turning real suffering into spectacle, and without the production collapsing under its own good intentions? This talk uses Amnios — a hand-drawn 2D narrative game developed in Godot — as a concrete case study for navigating that tension from a technical and production standpoint.

Amnios follows three women navigating pregnancy, childbirth, and early motherhood across three different displacement contexts (the Darién Gap, the DRC–Uganda border, and Geneva). It was developed by a small interdisciplinary team (HEAD – Genève, HEdS, HUG, ICRC) on an eight-month seed grant, using real testimonies and a co-creation workshop with twelve migrant women as source material rather than research statistics.

I'll cover:

- Why Godot was the right engine for a small, cross-disciplinary team mixing artists, clinicians, and researchers with no prior game-dev experience

- Building a hybrid comic/side-scrolling structure — combining illustrated panel sequences with forced-scroll 2D levels to represent involuntary displacement

- "Bubble Puzzles": a symbolic dialogue mechanic (conversation, thought, and violence bubbles) used as both a narrative device and a literal gameplay system, and how we implemented it in Godot's node/signal architecture

- Translating testimony into mechanics — the practical pipeline from workshop transcripts and field interviews to level design and environmental storytelling, without reproducing individual stories directly

- Production reality on a tiny budget and timeline — team structure, scope decisions, what got cut, and what we'd do differently

- Ethical representation as a design constraint, not an afterthought: how clinical and humanitarian partners (obstetrics, perinatal psychiatry, ICRC field researchers) were embedded in the actual dev process, not just consulted at the end

Who this is for: developers and studios considering socially-engaged or research-based projects, anyone scoping a narrative game on a small team/budget, and educators or NGOs curious about games as a serious medium for sensitive topics. Attendees will leave with a concrete production framework for working with external experts and lived testimony without either exploiting the subject matter or diluting the game into something toothless. No prior knowledge of humanitarian work needed — this is a game-dev talk first, with the social impact angle as the lens.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/XRDB8E/

At GodotCon Amsterdam 2026, "Game Programming Patterns for Godot" started with a tiny Reddit find, a cached getter and grew into a tour of underexplored patterns for real Godot projects. Then the video went online, and the comment section did what comment sections do: it argued, it questioned, and it asked for more.

This sequel answers back. We'll address the most common (and most spicy) objections from the community head-on, with code, and then go further: new patterns that didn't fit in the first talk, each demonstrated in a real, shipping Godot project.

The talk has three acts:

Act I: A New Hope, Recapped. A fast, visual recap of the first talk's core idea.

Act II: The Comments Strike Back. The top community objections and questions from the YouTube release, each answered with working code

Act III: Return of the Patterns. Three patterns that didn't make the first talk, each shown in the context of my own released game, Tiny Drift:

- State machines beyond the basics: pushdown automata for input and UI flows that plain enum-based FSMs handle poorly.

- MVVM for game UI: separating game state from UI scenes using observable custom Resources; why this is underexplored in Godot and what it buys you in practice.

- The Repository pattern with custom Resources: abstracting save data and content databases behind a data-source interface, and where the classic IRepository approach breaks down in GDScript.

At GodotCon Amsterdam 2026, "Game Programming Patterns for Godot" started with a tiny Reddit find, a cached getter, and grew into a tour of underexplored patterns for real Godot projects. Then the video went online, and the comment section did what comment sections do: it argued, it questioned, and it asked for more.

This sequel answers back. We'll address the most common (and most spicy) objections from the community head-on, with code, and then go further: new patterns that didn't fit in the first talk, each demonstrated in a real, shipped Godot project.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/

about this event: https://talks.godotfest.com/godotfest-26/talk/UEWVJG/