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/

Video:godotfest-26-8-eng-The_Return_of_Game_Programming_Patterns_for_Godot_sd.mp4

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/

Video:godotfest-26-72-eng-Farewell_Speech_sd.mp4

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/

Video:godotfest-26-70-eng-Waiting_for_GDScript_Rebuilding_a_Dialogue_Engine_Without_C_sd.mp4

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/

Video:godotfest-26-66-eng-I_Dont_Know_If_This_Game_Is_Good_sd.mp4

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/

Video:godotfest-26-64-eng-You_want_to_add_Shaders_to_your_game_Here_is_how_you_start_sd.mp4

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/

Video:godotfest-26-45-eng-Using_Godot_for_defence_simulators_sd.mp4

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/

Video:godotfest-26-43-eng-Mobile_Games_Without_the_Slop_sd.mp4

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/

Video:godotfest-26-39-eng-Small_Team_Big_Leverage_Using_Automation_to_Build_Games_Faster_sd.mp4

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/

Video:godotfest-26-28-eng-Cracking_open_Godot_Editor_what_it_taught_me_about_Godot_sd.mp4

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/

Video:godotfest-26-25-eng-Lets_Hear_It_Enabling_True_Audio_Accessibility_in_Godot_sd.mp4

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/

Video:godotfest-26-22-eng-Developing_a_humanitarian_video_game_in_Godot_sd.mp4

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/

Video:godotfest-26-21-eng-The_5-Phase_Game_Jam_Framework_Bringing_Structure_to_Chaos_sd.mp4

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/

Video:godotfest-26-13-eng-Synthesizing_a_Flamethrower_from_a_Bathroom_Sink_DIY_Sound_Design_for_Indie_Devs_sd.mp4

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/

Video:godotfest-26-70-eng-Waiting_for_GDScript_Rebuilding_a_Dialogue_Engine_Without_C_hd.mp4

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/

Video:godotfest-26-39-eng-Small_Team_Big_Leverage_Using_Automation_to_Build_Games_Faster_hd.mp4

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/

Video:godotfest-26-21-eng-The_5-Phase_Game_Jam_Framework_Bringing_Structure_to_Chaos_hd.mp4

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/

Video:godotfest-26-9-eng-Continuous_community_driven_translations_with_gettext_and_Weblate_sd.mp4

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/

Video:godotfest-26-71-eng-Keynote_Tools_Change_Craft_Remains_-_Reflections_on_Godot_AI_and_the_Future_of_Making_Games_sd.mp4

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/

Video:godotfest-26-69-eng-Building_Your_Discord_Server_Through_Every_Stage_of_Game_Development_sd.mp4

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/

Video:godotfest-26-67-eng-Multiplayer_Bloopers_Common_networking_pitfalls_explained_with_painful_examples_sd.mp4

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/

Video:godotfest-26-65-eng-Shipping_3D_Cross-Platform_on_a_Shoestring_Budget_A_Solo_Devs_Postmortem_sd.mp4

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/

Video:godotfest-26-6-eng-LOVE_DOGS_ROBOTS_NET_C_and_Godot_everywhere_sd.mp4

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/

Video:godotfest-26-58-eng-No_Big_Rewrites_Incrementally_Porting_GDScript_to_C_with_GDExtension_sd.mp4

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/

Video:godotfest-26-53-eng-TestFlight_for_Godot_Developers_Playtesting_Games_on_Apple_Platforms_sd.mp4

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/

Video:godotfest-26-50-eng-The_basics_of_Image_Composition_sd.mp4

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/

Video:godotfest-26-49-eng-Ichor_Online_Building_a_Massive_Multiplayer_Online_RPG_in_Godot_sd.mp4

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/

Video:godotfest-26-47-eng-From_Alpha_to_Z-Test_A_trip_through_Godots_renderer_sd.mp4

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/

Video:godotfest-26-46-eng-The_Price_of_Rushing_Preproduction_-_Vultures_A_Turn-Based_Resident_Evil_Postmortem_sd.mp4

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/

Video:godotfest-26-41-eng-Why_You_Should_Develop_and_Release_on_Console_First_sd.mp4

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/

Video:godotfest-26-37-eng-Building_A_Multiplayer_Network_for_Digital_Twins_in_VR_AR_sd.mp4

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/

Video:godotfest-26-36-eng-Console_Development_Unlocked_Bringing_Your_Godot_Game_to_PS5_Xbox_Switch_sd.mp4

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/

Video:godotfest-26-35-eng-Godot_Accessibility_-_Creating_the_Utmost_Freedom_sd.mp4

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/

Video:godotfest-26-27-eng-Crashes_Dont_Care_What_Language_You_Wrote_Your_Game_In_sd.mp4