Chaos Computer Club - GodotFest 2026 (mp3)

You want to add Shaders to your game? Here is how you start. (godotfest2026)

Wed, 04 Nov 2026 16:30:00 +0100

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/

Using Godot for defence simulators (godotfest2026)

Wed, 04 Nov 2026 15:30:00 +0100

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/

Let's Hear It! Enabling True Audio Accessibility in Godot (godotfest2026)

Wed, 04 Nov 2026 12:30:00 +0100

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/

Waiting for GDScript: Rebuilding a Dialogue Engine Without C# (godotfest2026)

Wed, 04 Nov 2026 14:30:00 +0100

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/

Developing a humanitarian video game in Godot (godotfest2026)

Wed, 04 Nov 2026 12:00:00 +0100

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/

Mobile Games Without the Slop (godotfest2026)

Wed, 04 Nov 2026 12:00:00 +0100

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/

I Don't Know If This Game Is Good (godotfest2026)

Wed, 04 Nov 2026 10:00:00 +0100

Even after years of making games, I can’t reliably tell if one is "good" while we’re building it. Intuition, playtests, retention and wishlists all help - but every signal can mislead you in a different way. It is also hard to judge if the game is just "not good yet" or can actually never be good. In this talk, I’ll show how we deal with that at Bippinbits, using examples from both our successful games and the ones we chose to cancel. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/XMEH88/

The 5-Phase Game Jam Framework: Bringing Structure to Chaos (godotfest2026)

Wed, 04 Nov 2026 11:00:00 +0100

Game jams are exciting, but they're also chaotic. Many participants lose valuable time, over-scope their ideas, or spend days polishing features that players never experience. Over the past five years, I've completed more than a dozen game jams and developed a simple five-phase framework that brings structure to the entire process, from choosing an idea to publishing the final build. This talk walks through each phase of the framework, covering planning, execution, polishing, submission, and post-jam visibility. Rather than focusing on specific tools or engine features, the framework is built around habits and decision-making that work regardless of experience level. Whether you're entering your first game jam or your fifteenth, you'll leave with a repeatable process that helps you finish stronger games with less stress. Every game jam begins with ambitious ideas, but finishing a polished game requires a lot of decisions under intense time pressure. This session breaks those decisions down into a practical five-phase framework that attendees can immediately apply in their next jam. **Phase 1 - Planning:** Turn the jam theme into a unique, achievable game idea, brainstorm effectively, control the scope, and use a one-page "Mini GDD" to organise ideas before opening the engine. **Phase 2 - Execution:** Learn how to stay productive under pressure by following a clear plan, prioritising the core gameplay loop, keeping mechanics simple, choosing technology that fits the deadline, and knowing when "good enough" is the right decision. **Phase 3 - Polishing:** Learn how to make a game feel finished by adding impactful feedback, creating intuitive tutorials, and using game juice to make every player interaction feel satisfying. **Phase 4 - Finalising:** Avoid last-minute disasters by testing exported builds, planning around the deadline instead of racing it, and learning why I treat uploading several hours early as a non-negotiable rule. **Phase 5 - Post-Jam:** Give your game the first impression it deserves by presenting it effectively with compelling screenshots, GIFs, and descriptions that encourage players to give it a chance. Throughout the session, I'll share real examples from my own game jams, highlighting both successful decisions and mistakes that taught valuable lessons, alongside practical techniques attendees can immediately apply in their next jam using Godot. Winning a jam is never guaranteed, but consistently finishing polished, enjoyable games is something you can prepare for. This talk is about building the habits and workflow that help you do exactly that. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/MXVUPL/

Small Team, Big Leverage: Using Automation to Build Games Faster (godotfest2026)

Wed, 04 Nov 2026 10:00:00 +0100

Large companies use automation to reduce repetitive work, improve reliability, and help teams move faster. Many of the same ideas can be just as valuable for solo developers and small indie teams—without bringing along the complexity and bureaucracy of a large organization. This talk explores how automated builds, reusable development environments, continuous integration, testing, packaging, and versioned releases can increase development velocity and make ambitious projects more sustainable. Using the multiple open-source Godot projects I maintain as a real-world case study, I will show how automation makes it possible for one developer to support several platforms, dependencies, and release workflows at a scale that would be unrealistic to manage manually. This session looks at how solo developers and small teams can adapt proven engineering practices from large companies to gain more leverage from limited time and resources. The talk will cover practical techniques such as automated cross-platform builds, reusable dependency environments, continuous integration, testing, packaging, and versioned releases. It will also explore how tools such as godot-package can download specific versions of GitHub release artifacts, making dependencies explicit and helping projects reproduce known working configurations without unexpectedly breaking users. Drawing from my experience building and maintaining large, complex systems in professional software environments, I will show how I applied the same underlying ideas to the growing collection of open-source Godot extensions I maintain. Without automation, supporting these projects across multiple platforms and releases would be impractical for a solo developer. The focus will be on creating simple, repeatable systems that reduce manual work, prevent regressions, and make an otherwise unsustainable workload manageable. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/QRCMAP/

The Return of Game Programming Patterns for Godot (godotfest2026)

Wed, 04 Nov 2026 11:00:00 +0100

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/

Shipping 3D Cross-Platform on a Shoestring Budget: A Solo Dev's Postmortem (godotfest2026)

Tue, 03 Nov 2026 17:00:00 +0100

How do you ship a 3D educational game for Web, Desktop, and Mobile in Godot 4 on a tight budget? In this postmortem of "The Masked Particle," I will share my survival strategies as a solo dev. Drawing from 1.5 years of building hypercasual mobile prototypes in 2-week sprints, I will show how that "need for speed" helped me build momentum in the crucial early stages of this Godot project. You will learn how to manage a mixed asset pipeline without in-house artists, build pragmatic responsive UIs, and discover a massive performance hack: simulating a complex 3D particle detector using lightweight 2D line draw calls for smooth web and mobile exports. This session is aimed at indie developers, freelancers, and solo devs who want to build and release cross-platform projects in Godot 4 without burning out or breaking the bank. **Talk Outline:** - The Setup & Prototyping Mindset: Introducing "The Masked Particle" and the constraints of targeting Web/Desktop/Mobile. I will briefly touch on how my background in 2-week hypercasual sprints helped me scope the project and gain speed during the crucial early prototyping phase. - The Pragmatic Pipeline: How to build a 3D game without a 3D artist. A look at mixing store assets, outsourcing work, and AI backgrounds to stay on budget. - Good Enough UI: Utilizing Godot's Control nodes to build a single UI that works on big desktops as well as small smartphones, prioritizing shipping readiness over perfection. - The "Fake 3D" Hero Hack: A deep dive into web and mobile performance optimization. I will show how I avoided melting GPUs by simulating a complex 3D view into a particle detector using performance-friendly 2D line draw calls. - Q&A Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/RJSRWU/

Multiplayer Bloopers: Common networking pitfalls explained with painful examples (godotfest2026)

Tue, 03 Nov 2026 16:00:00 +0100

Your game works perfectly until other players show up with their own version of reality. This is a light, fast tour of the classic multiplayer bugs: why they happen, how to fix them, and how to fix the fix. Networking breaks your game in ways that are hard to explain, easy to laugh at, and even easier to misdiagnose. Players will call all of it lag. You will blame the server. It is usually neither. This talk walks through the common ways multiplayer goes wrong: why each one happens, what the usual fix is, and what that fix quietly breaks in return. No code or netcode background needed. If you are adding multiplayer to your game, or already shipped it and are now reading the reviews, this one is for you. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/WXYKTM/

Godot & Accessibility - Creating the Utmost Freedom (godotfest2026)

Tue, 03 Nov 2026 16:30:00 +0100

Discover the essentials of accessibility in games and learn how to make your great work enjoyable for so many more users - using incredibly simple methods! We might not realize it at first, but accessibility plays a role in virtually **_every_** aspect of our life - whether by wearing glasses or hearing aids, living with physical limitations or sustaining sensory overloads. Even the brightness level of the screen on which you are currently reading this text can be considered an accessibility or quality-of-life feature! **In this short talk, I focus on the topic of general accessibility in games, including:** - An explanation of what accessibility actually is and why it is so important. - How small and simple (UI) optimizations can make a **_huge positive difference_** for many users. - An overview of tools available to (indie) developers. - Why forcing accessibility is a bad idea and why it is (sadly) impossible to optimize games for every single individual. So, join me on this little journey through virtual realms of boundless freedom, and let’s discover new ways of making games as accessible as possible - after all, it enhances **everyone's** enjoyment of your fantastic works! ♥ Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/GFUZ9L/

Backstitch: Real-Time Version Control for Godot (godotfest2026)

Tue, 03 Nov 2026 17:30:00 +0100

Our open-source version control plugin, [Backstitch](https://backstitch.dev/), enables fast collaboration for dev teams, game jams, and classrooms! Are you an artist who struggles with Git merge conflicts, and broken Godot scenes? Or perhaps you're a programmer who keeps handling your team's Git problems, instead of writing code? Maybe you teach Godot to students, and half your time is spent fixing Git mistakes? Game development includes a diversity of roles, and not everyone can be expected to learn or teach Git. Its learning curve is way too steep, and less-technical participants can end up locked out of Godot entirely. Plus, Git was built for code -- games are a lot more than code! Enter [Backstitch](https://backstitch.dev). Our open-source Godot plugin allows for real-time collaboration, similar to a Google Doc. You can... - See a history of changes, including visual diffs - Revert to previous versions - Create and merge branches ... all without leaving the editor. Most importantly, you're *never* stuck with a broken scene. Everyone's changes are intelligently merged together, automatically. Backstitch is great for game jams, or remote, asynchronous work. It is also excellent for classrooms! The plugin grew out of a collaboration with the Endless Foundation, who teach game development with Godot, and needed a better solution for students than Git. In this talk, we'll cover the challenges of version control in game development, what we've learned from students, and what collaboration can look like when everyone on the team can work together. Everyone deserves equal access to version control! Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/HSYC8B/

The basics of Image Composition (godotfest2026)

Tue, 03 Nov 2026 17:30:00 +0100

How to compose a balanced and strong image is a skill that is relevant for any gamedev, not just artists. I will go over some tool that we use in Illustration, so that your Storefront graphics, Video Thumbnails, Cutscenes, Ui and Leveldesign visuals will improve :) We will go over examples of strong compositions and then look at individual "tools" that will help you create clearer and better images: Visual hirachy, Colors & Contrast, Shape language, Text and Spacing. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/QVRYE3/

Ichor Online: Building a Massive Multiplayer Online RPG in Godot (godotfest2026)

Tue, 03 Nov 2026 16:30:00 +0100

Building an MMORPG as Indie Devs: workflows, scope management, lessons learned and leveraging the power of SpacetimeDB with Godot. Building an MMORPG comes with big challenges across content production, large-world tooling, rendering many entities, connection management, latency, netcode and networked physics. This talk explores how we’re combining Godot, SpacetimeDB, and Blender to approach these problems while building Ichor Online. We’ll share our architecture, workflows, lessons learned, and practical trade-offs. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/7YUGET/

Crashes Don't Care What Language You Wrote Your Game In (godotfest2026)

Tue, 03 Nov 2026 15:30:00 +0100

A Godot game is rarely written in just one language. You've got GDScript for gameplay, more and more C#/.NET for the heavier systems, and native C++ through GDExtension underneath. Then you export the whole thing to Windows, Linux, macOS, Android, iOS, the Web, SteamOS/Proton, and - for some of us - consoles. Every one of those languages fails differently. Every one of those platforms reports and symbolicates crashes differently. So when a player hits a bug you can't reproduce, the problem is collapsing that entire grid of languages and platforms into one readable issue, no matter what threw it or where it died. This talk walks through that problem end-to-end, using Sentry's Godot SDK - recently expanded with first-class .NET support - as the example. We'll look at how a GDScript error, a C# exception, and a native crash differ; how the same crash has to survive Android tombstones, WASM in the browser, and the Proton translation layer on SteamOS; and how you can still get all of it back as a single, grouped, source-mapped issue. It's a talk about the messy reality of shipping a Godot game everywhere at once - and how to stay sane while doing it. **You write in three languages and ship to eight platforms. A crash can come from any cell in that grid. You need to turn that grid back into one clear answer.** Most crash-reporting talks assume one language and one platform. Godot oftenbreaks both assumptions at the same time, which is exactly what makes it relevant for all Godot developers,whether they're all-in on GDScript, betting on C#, or dropping into native code for performance. ## Axis 1 - The languages: three ways a game can fail Under one engine, "an error" means three different things: * **GDScript** - Errors come from the engine's own script VM. You want the script, the line, and the game state around it, captured live as the game runs. * **C#/.NET - The newest and fastest-growing surface.** These are managed-runtime exceptions with their own stack shape, and the SDK now captures them as first-class events (including script context and variable values on the platforms that support it). Godot's C# community has been waiting on solid tooling here, which is a big part of why this talk is timely. There's even a build-time check that nudges C# developers toward the Godot-aware SDK instead of the raw one, a small thing that prevents a lot of misconfigured setups. * **Native / GDExtension (C++)** - When your own native module or the engine itself crashes, you don't get an exception at all; you get a full-process minidump from an out-of-process handler. A completely different capture model from the two above. The point for the audience: these aren't three flavors of the same thing. They fail differently, they carry different context, and unifying them means agreeing on what an event even is before you can put them together in one list. ## Axis 2 - The platforms: the same crash, eight hostile environments Now take any of those failures and ship it across Godot's export targets. Each one has different rules: * **Desktop** (Windows / Linux / macOS) - the baseline, and even here you're juggling different symbol formats and, on Apple, a separate underlying SDK. * **Android** - its own crash world: tombstones, ANRs ("Application Not Responding"), app hangs, and multiple CPU architectures to build and symbolicate for. * **iOS** - managed through the platform's native tooling, with its own signing and symbol quirks. * **Web (WASM)** - your game is now running in a browser sandbox; a crash looks nothing like it does on desktop. * **SteamOS / Proton** - your Windows build running through a translation layer on Linux. When it crashes, which stack are you even looking at? One example: under Wine the thread's stack bounds can report back wrong, so the crash handler tries to capture a wildly oversized stack - the SDK has to detect that it's running under Proton and rein the capture back in. * **Consoles** - locked-down platforms where you can't just drop in a standard crash handler at all. This axis is where a lot of the complexity lies and it's the part many devs underestimate until they ship. Turning the grid back into one answer ## The payoff of the talk is how the two axes come back together: * **One SDK, many engines underneath.** The Godot SDK is built as a GDExtension that quietly composes several native SDKs (the native/C++ crash backend, plus the Apple, Android, and Web SDKs) and presents a single, clean GDScript and C# API on top. You write against one interface; it fans out to the right machinery per platform. * **Normalize, then symbolicate.** Events from three different runtimes get normalized into one shape, and then each is mapped back to your source - GDScript line, C# frame, or native symbol - using the right method for that platform. * **One list, grouped and readable.** A C# exception under Proton and a native crash on Android end up side by side as grouped, source-mapped issues - plus Godot-native context like the scene tree, a screenshot of what the player saw, breadcrumbs, and device info. * **Where it's heading.** Once every language and platform lands as structured, richly-contextual data, that context becomes the raw material for AI-assisted root cause - a natural, non-salesy closing note. ## Under the hood: how the layers actually talk (and where it got messy) This is the technical spine I'd want to give the talk real weight. Focus on the handful of design decisions and hard-won bugs that make the "one clean issue" illusion hold together. It's the part senior devs in the room will recognize from their own native/managed bridges. * **One interface, swappable backends.** Everything the public API does - set a tag, add a breadcrumb, capture an event - goes through a single internal C++ interface. Desktop fulfills it with the native/crashpad backend; Apple, Android, and Web each plug a different underlying SDK in behind the exact same interface. The GDScript or C# you write never knows, or cares, which one answered underneath. * **The C#↔native bridge is hand-built**, and it's mostly about strings and structs. Godot's C# layer doesn't get to use a normal SDK. The managed and native sides talk over a raw function-pointer boundary. Native registers a table of callbacks C# can invoke; C# imports a matching set of native entry points. Every string crosses as a raw UTF-16 pointer + length with explicit handoff, and every struct has to have byte-for-byte identical layout on both sides. Get one field out of order and there's no compiler to catch it - you get a crash while reporting a crash. * **Keeping scope in sync without an infinite loop.** Set the user, a tag, or a breadcrumb in C#, and it has to also show up on a native crash that C# never sees - so each layer observes the other and mirrors changes across. The obvious trap: native tells managed, managed's own observer tells native, which tells managed… forever. The fix is a small thread-local re-entrancy guard so a change that arrived from a sync doesn't echo back out. * **The SDK crashing on its own crash reports.** We hook Godot's error stream to turn engine errors into events - but our own code can log errors, which we'd then capture, which logs more errors. That's a feedback loop, and done naively under a lock, a deadlock. Making it safe took a recursion-depth guard, filtering out our own log output by prefix, and a hard rule to never emit an error from inside the per-frame handler. * **Error storms.** One bad line in _process() throws the same error every single frame. With no limits you'd ship 60 identical events a second and set the player's machine on fire, so there's per-frame caps, a throttling window, and per-source-line dedup - plus deliberately looser limits for the first few frames of startup, where a burst of errors is normal. * **"Is this even a C# error?"** C# exceptions arrive through the same logger as GDScript errors - sometimes tagged with a .cs file, but on the Mono runtime sometimes with an empty file, so we fall back to sniffing the backtrace's language name to route it to the .NET layer. And then symbolication itself: GDScript source we can pull live from the running script VM, but in an exported .NET game the assemblies live inside Godot's packed, compressed virtual filesystem - no file on disk for the .NET SDK to open, so every managed frame comes back as unknown_image. The workaround is handing the SDK a fake seekable "file" that reads those bytes back out through Godot's own filesystem, and only the two small slices it actually needs. The theme across all of these: the friendly one-line API is easy; what's hard is the plumbing underneath that keeps three runtimes agreeing on what happened, without deadlocking, looping, or lying about where the crash came from. ## Key Takeaways * **"One language, one platform"** is a fantasy for Godot devs. Design your error handling for the whole grid from day one. * **GDScript, C#, and native failures are genuinely different** - knowing how they differ is the first step to unifying them. * **Your export targets are where reproducibility goes to die** - Proton, Web, Android, and consoles each change what a crash even looks like. * **GDExtension is a powerful seam for wrapping native capability** behind a friendly GDScript/C# API - crash reporting is one worked example of a general pattern. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/EALHBY/

Building Your Discord Server Through Every Stage of Game Development (godotfest2026)

Tue, 03 Nov 2026 15:30:00 +0100

This talk runs through setting up a Discord server to help game developers as they build and grow their games. It talks about how to set up moderation, create channels, create roles, get feedback, run events, and interact with the community. It steps through how these things change as a dev's game goes from prototype to beta to release. Your Discord server isn't just a community, it's a development tool. This talk walks through building a server that works for you at every stage of your game's development. We'll talk about channels, roles, events, moderation, and how to bring players straight from your game into your community and keep them engaged. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/AZLG7R/

Building A Multiplayer Network for Digital Twins in VR/AR (godotfest2026)

Tue, 03 Nov 2026 15:00:00 +0100

The LSU distillation columns is an advanced structure that gives opportunity for students to operate and experience commercial chemical equipment that follows specialized design standards. With the scale and complexity of the LSU distillation columns, creating a digital replication of the towers with a multiplayer system transforms learning, for both professors and students are able to analyze and study the facility without physical attendance. The multiplayer network facilitates real-time collaboration in a 3D digital environment through virtual reality (VR) and augmented reality (AR). To create a collaborative experience, the development between a multiplayer network, digital twin technology, and VR/AR environment enables an interface connecting data, systems, and people. The system will allow multiple people to thoroughly immerse, communicate effectively, and collect information simultaneously through a multitude of devices. Using digital twins in academics is an extension of learning and a different study method before firsthand operations. This presentation aims to share the challenges that arise within a shared virtual reality and multiplayer systems interactions. In addition, it demonstrates how accessible and scalable it is to implement across diverse platforms with open-source software, making it compatible for applications in education, research, and industry. This project focuses on creating and implementing digital twins of the LSU distillation columns through open-source software. Open-source software is important because it allows more flexibility to modify and improve designs over time as well as be transparent and accessible. We found that open-source software is highly capable and accessible in our workflow when creating interactive digital twins. Using data from lidar or photogrammetry, a point cloud is generated from an application like CloudCompare for accurate measurement, scale, and location of the environment. This point cloud served as a precise reference when constructing the 3D model on a large-scale system. Blender’s dynamic toolset allowed the team to create a detailed visualization of the data in an efficient manner. Shifting the 3D model into Godot, interactivity with user movement, object information, and world navigation was added to the application. Blender and Godot are meant to work together and the reason why we chose these specific programs is because they are fully free. Freedom to build, modify, and share what is made. They are made for the user. Finally, for version control, Github was used to track all the changes. Each of these open-source tools are adaptable and significantly robust for building both optimal digital twins and high-fidelity digital twins. Pipeline: Lidar/Photogrammetry: - Point cloud generated from images provided accurate scale for models Blender: to model the 3D environment - Create a master file to combine separate 3D parts - Individual team member files are linked to the master file - Establish a material legend and asset library for consistency Godot: to handle the VR/AR system - Multiplayer system: backend network - Toy model mode - VR/AR mode - Interactive aspects such as a drawing function and hovering to show information Github: to source control - Documentation - Tracking and maintaining files This aims to use Blender to model the 3D environment and Godot to handle the VR/AR system. Important features include multiplayer system, toy model mode, VR/AR mode, and other interactive aspects such as a drawing function and hovering to show information. The main emphasis is the multiplayer network as this allows multiple users to interact with the 3D surroundings and collect necessary information in real-time. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/P3UM83/

Why You Should Develop and Release on Console First (godotfest2026)

Tue, 03 Nov 2026 14:30:00 +0100

Traditionally, indie studios and small teams developed for a single console first before porting to PC—a tradition that has since flipped to "Steam first." This talk challenges that modern default. By exploring the technical advantages of a single hardware spec, the business benefits of dedicated console audiences, and the artistic merit of crafting a canonical, intended experience, we will examine why developing for console first might be the smartest strategic decision for your studio. In this 50-minute session, we will dive deep into the strategic advantages of developing and releasing your game on a console first. Drawing from my history working on early XBLA titles, PlayStation Strategic Content, and Dreams, this talk unpacks why the "PC-first" mentality became the default and why shifting your focus back to console can elevate your game. We will break this down into three core pillars: Technical, Business and Artistic. The biggest barrier is often simply knowing you can. In a world of distraction and slop you can always grow and expand in the future. Why not FOCUS, make interesting technical decisions, different business choice and strong artistic choice in developing for one console first. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/QQWXL9/

Continuous community driven translations with gettext and Weblate (godotfest2026)

Tue, 03 Nov 2026 14:30:00 +0100

Using **gettext** and a continuous translation platform like **Weblate** allows translators to use a **simple web view** to translate and gives developers a simple way to **pull the changes through git**. This talk will cover the basic setup and some tricks I learned while developing 99Managers Futsal Edition with over **60 translation contributors and 16 languages** (and counting...). Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/FAMRTE/

What Our Unity Team Got Wrong (So You Don't Have To) (godotfest2026)

Tue, 03 Nov 2026 12:30:00 +0100

We migrated a team from Unity to Godot - not as beginners, but as experts whose Unity instincts actively worked against us. The habits that made us fast in Unity quietly produced brittle, un-idiomatic Godot code, and the bill came due within weeks. This is the honest post-mortem of our first month: the mental models that collided, the muscle memory that backfired, and the day source control broke. For each, we'll show what we assumed, what actually happened, and the convention that fixed it - so your first month is shorter and less painful than ours. Most "switching to Godot" talks target newcomers. This one is for teams who already know how to ship - because migrating experienced engineers is a different, harder problem. Your expertise doesn't transfer cleanly; it misleads you. Godot looks enough like Unity that you reach for familiar patterns, and those patterns are exactly what produce fragile code. We'll walk through the specific collisions our team hit, in three buckets: **Mental models that don't map 1:1**: - GameObjects-and-Components vs. nodes-and-scenes - Prefabs and variants vs. PackedScenes and scene inheritance (where instancing and overrides genuinely differ) - ScriptableObjects as Data Containers vs. Resources - `Update()` vs. `_process`/`_physics_process`. **Muscle memory that backfired**: - Porting Unity's singleton/manager soup straight onto autoloads - The `GetComponent<>()` reflex becoming `get_node()` coupling - And the big one, "we already know C#, so we'll just use C#". The honest team tradeoff between GDScript and C# _(iteration speed, export pipeline, community examples)_. **The day git broke**: - Scene and resource files are text now: diffable, but conflict-prone. - How we kept scenes small and reviewable - what to commit vs. ignore We're just one team, one project into Godot - so this is what worked for *us*, not a definitive playbook. But if sharing our wrong turns spares you a little of the trouble they cost us, that's a win. **Audience:** engineers, tech leads, and studio decision-makers considering or mid-migration. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/EJG9MJ/

TestFlight for Godot Developers: Playtesting Games on Apple Platforms (godotfest2026)

Tue, 03 Nov 2026 12:00:00 +0100

Practical overview of using Apple’s TestFlight to playtest and distribute Godot games. Learn how to set up staged rollout channels to test updates with targeted user groups, configure feedback channels, and structure "What to Test" prompts that yield useful player insights. We'll showcase onboarding new playtesters and gathering their feedback in real time. The talk also covers navigating platform constraints, clarifying what TestFlight can measure vs where you must implement custom telemetry, promoting validated builds directly to the App Store, and using the ShipGodot editor plugin for easy cross-platform deployment. This talk provides a practical guide to playtesting and releasing Godot games on Apple platforms. No prior Apple developer experience is required. **Topics covered:** - TestFlight Overview - Creating staged rollout channels to test updates with targeted user groups. - A live demo showing how easy it is to onboard new playtesters and receive their feedback. - Setting up the feedback channel and structuring "What to Test" prompts to get honest, and useful insights from playtesters. - Handling TestFlight constraints, what can be measured with it and where you need to implement your own telemetry - Promoting validated builds directly to the AppStore - Using ShipGodot editor plugin for easy cross-platform deployment Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/JUMP8X/

The Price of Rushing Preproduction - Vultures: A "Turn-Based Resident Evil" Postmortem (godotfest2026)

Tue, 03 Nov 2026 11:30:00 +0100

Preproduction should be the space where you experiment with mechanics and figure out what game you're actually building. But if you never stop throwing out new ideas, you can get stuck exploring forever without ever locking anything down. However, finishing it with a lot of "we'll figure out later," and not measuring the impact of changing mechanics or levels during production, can be risky. This talk breaks down what rushing preproduction actually cost Vultures - Scavengers of Death. Vultures - Scavengers of Death started as a text based roguelike prototype, then a small 3D vertical slice built in Godot 3. That vertical slice became our demo, and it did its job, it proved the core mechanic worked, turn based tactics that played like Resident Evil. We got funded and started working on the game without being aware of how much everything else would actually cost: story, levels, enemy design, even the bosses. We cut preproduction short under the pressure of hitting our release commitments with the publisher. That decision followed us through the rest of production, and it showed up exactly where we couldn't afford it, the final weeks before launch. This talk covers three years of prototyping, pitching, and producing Vultures, told through the real production timeline of a two person studio shipping a commercial game in Godot.. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/DBRFQC/

Console Development Unlocked: Bringing Your Godot Game to PS5, Xbox & Switch (godotfest2026)

Tue, 03 Nov 2026 11:30:00 +0100

Bringing a Godot game to consoles involves much more than getting the engine to run on the hardware. In this talk, I'll walk through what it actually takes to bring a Godot game to PlayStation, Xbox, and Nintendo Switch, from becoming an approved console developer and getting access to development hardware, to choosing a Godot console port, preparing your game, and getting through certification. We'll look at practical lessons for building a console-ready Godot project, including platform-independent architecture, input and controller handling, save games, performance, loading times, platform services, and certification requirements. I'll also share real-world experience from console development with Godot, including case studies such as The Dark Queen of Mortholme and Astra Bestiary, and look at other Godot games making their way onto consoles. The goal is to give you a practical understanding of the entire journey, from having a Godot game on PC to actually shipping it on a console. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/3PAYYA/

LOVE,DOGS+ROBOTS .NET, C#, and Godot everywhere! (godotfest2026)

Tue, 03 Nov 2026 11:00:00 +0100

Come on a journey where we explore what's possible with Godot 4.7, 4.8, and .NET 10 / 11. I'll share findings, fascinations, and funny bits about my love for Godot with .NET; the things many developers long for, and how **Godot** and the **Godot community** helps us find them. ### Live Demo: [2dog.dev](https://2dog.dev) We'll go through the motions of porting a real C# Godot game to HTML5 and WebAssembly for publishing on [itch.io](https://itch.io) ... live on stage. **Woof, or oof?** Don't worry, it's really just about as easy as typing: ``` dnx 2dog add dotnet publish ``` Voilà! ### Treats 🦴 In version 4.6, `libgodot` became an official part of Godot. Now Godot 4.8 brings .NET 10, but what does that really _mean for us_ developers? Both Godot and 2dog (which really _is still Godot,_ just a little backwards) have much more in store, with the brand new `godot-dotnet` and C# bindings on the horizon. Let's peek at some advancements coming from the .NET ecosystem with .NET 10 and 11. ## Who is this talk for? Developers using C# with Godot, for anything from applications, game jams, prototypes, and entire games ready to ship on Steam tomorrow. ## What to expect? An overview of where Godot and C# is in actual use, in games and application development. See **2dog**, a concrete, free, and easy to apply use case of `libgodot`. It turns out it can do *a whole lot of very useful things* for game developers on every level. - Publish Godot C# games to WebAssembly for the browser - Run xUnit, GdUnit, or NUnit tests from your IDE, the CLI, or CI - Import resources through MSBuild tasks - Add another layer of .NET code around an existing game ## But why? In late 2025, I went on a journey to learn the innards of Godot and find a way to write my own importers and unit test runners. I was also still waiting for Godot and the promised C# web exports since version 4.1 ... then I met some amazing folks from the community at GodotCon Berlin and Amsterdam, and the rest was pure magic. **Stay a while and listen!** 🦴 Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/RFNWCH/

From Alpha to Z-Test: A trip through Godot's renderer (godotfest2026)

Tue, 03 Nov 2026 10:30:00 +0100

In this talk I will break down how Godot's Forward+ renderer works starting from where it fits within the overall game frame to individual choices for major features. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/8BNKRM/

No Big Rewrites! Incrementally Porting GDScript to C++ with GDExtension (godotfest2026)

Tue, 03 Nov 2026 10:30:00 +0100

Take an example GDScript class and port it to C++ with me! We'll compare the benefits and tradeoffs of multiple approaches. Finally, I'll show my preferred method which allows for moving code to C++ incrementally and safely. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/ZFVM3B/

Keynote: Tools Change, Craft Remains - Reflections on Godot, AI and the Future of Making Games (godotfest2026)

Tue, 03 Nov 2026 10:00:00 +0100

Every generation of game developers has seen its tools change, from custom in-house engines to open-source editors like Godot. AI is the newest change, and it is already part of many professional workflows. It also raises real questions about credit, quality and creative ownership, and those questions deserve careful answers rather than quick verdicts. This keynote reflects on where making games is heading, what AI can and can't do for developers, and why the Godot community is well placed to help shape it. Tools will keep changing; the craft remains. Our shared task is to make sure the tools keep serving the craft. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://talks.godotfest.com/godotfest-26/talk/BBVKBH/