# How a Single Function Derailed Deltarune's Development When GameMaker added game_change to its scripting language in July 2023, it marked an unprecedented moment in game engine development - a core platform feature added specifically at one game's request, with that game's future development timeline entirely dependent on its implementation. A mere two weeks of engineering decisions would go on to impact years of Deltarune's development. ## Origins: 2018-2023 Deltarune's first chapter released in 2018 without Xbox support. When Chapter 2 arrived in 2021, the combined game project had grown unwieldy - every patch required complete retesting of both chapters, load times increased, and development became increasingly complex. The solution seemed straightforward: split each chapter into separate GameMaker projects. In June 2023, leaked Discord messages revealed GameMaker was adding a new function specifically for this purpose. By July, game_change appeared in GameMaker's codebase. The function seemed simple enough - it would let any GameMaker project launch other GameMaker games at runtime, passing window state and display settings between them. ## The Implementation Choice Looking at game_change's native implementation in `sub_1400FA680`, we see the critical design decision that would shape Deltarune's future. Rather than managing chapter transitions within GameMaker's virtual machine (which has a strict 128KB memory limit and should be easily resettable), the function takes a more direct approach. It saves window state to shared memory, launches an entirely new process for the next chapter, and terminates itself. Here's what that shared state looks like based on the disassembled code: ```cpp // Reconstructed from sub_1400FA680 struct SharedGameState { // 0x00-0x08: Initial flags uint32_t initFlags; uint32_t displayMode; // 0x08-0x20: Display settings from various subsystems uint32_t displaySettings1; // From 14007B090 uint32_t displaySettings2; // From 14007B040 uint32_t displaySettings3; // From 14007B120 uint32_t displaySettings4; // From 14007B180 // Window/display state continues... }; ``` This implementation took just weeks to complete - the technically simpler solution of process switching won out over proper virtual machine state management. That decision would go on to affect every aspect of Deltarune's development, from platform support to feature parity between chapters. By August 2024, game_change shipped in GameMaker 2022.0.3 LTS. Now in November 2024, over 16 months after the function's addition, users are beta testing basic functionality. The results reveal deep-rooted issues that trace back to those initial engineering decisions in 2023. ## The Problems Begin On November 25th, 2024, Toby Fox announced a public beta test of the game_change functionality:

We are testing a new command to switch Chapters in Deltarune Chapter 1&2. If you would like to test, please see the attached images and report any issues (mainly if it doesn't work...) with this Google form.

The announcement included a curious note: "Nothing is different so don't play any more unless you really really want to." Yet within hours, players discovered the chapter selection screen played no music:

Why are there no creepy sounds when I first run the game 🥲

The issues went deeper. Players found that switching chapters in fullscreen mode broke the display entirely:

Fullscreen bug

Buried in game_change's implementation is a warning about this exact issue: ```cpp "WARNING: game_change() called while in full-screen mode! This will not transition cleanly due to mode switching. Use of windowed/borderless full-screen is suggested instead." ``` Yet this warning appears nowhere in GameMaker's documentation for the function. It's unclear if it even surfaces in logs developers can access, leaving them to discover these limitations through user reports. The situation deteriorated further when Toby had to acknowledge widespread crashes:

Actually, it seems there may be a couple crashes, mainly in Chapter 2, due to something called a "Malformed Variable." We caught many of these before releasing, but it seems there are still some left (ex. if you give Susie the present in Ch2...)

Most telling was an unexpected change players noticed in the beta - Swatch's overworld sprite was different from the release version:
They fixed swatch's fucked up overworld sprite. I don't care if this is the only change they made in the new build, this is all i needed
This visual change in a build that supposedly contained "no differences" suggests the beta wasn't built from the stable Chapter 2 release code at all, but from an evolved development branch. The development team seemingly couldn't even reproduce the last known-good version of Chapter 2. GameMaker's VM already has mechanisms for managing game state - the engine's `game_save()` function demonstrates this capability. Speedrunners even use it for save states. Yet instead of building on this existing functionality, game_change opts for complete process termination and restart. The technically simpler solution, chosen for its quick implementation, has led to years of technical debt. The Xbox situation particularly highlights these consequences. When Deltarune initially skipped Xbox release in 2018, game_change didn't exist. But now, its process-switching architecture has permanently cemented that platform separation. Even though Deltarune runs perfectly in Xbox development mode and contains Xbox button graphics, the game can never properly release there without fundamentally reworking its chapter management system. ## Beyond Chapter 3: The Future of Deltarune's Development The game_change situation creates ripple effects that extend far beyond just switching between chapters. By splitting Deltarune into separate GameMaker projects, each chapter becomes effectively frozen in time - a snapshot of the engine version, coding practices, and game mechanics from when it was developed. When a developer fixes a bug in Chapter 3, that fix won't automatically propagate to Chapters 1 and 2. We can already see this issue with the mercy meter, save slot system, and combat targeting mechanics - each improvement or change remains isolated in its chapter of origin. As new chapters are released, this fragmentation will only increase. Players might encounter different behavior for the same actions depending on which chapter they're in, creating an inconsistent experience that's difficult to patch. The console situation is particularly concerning. While PC users can at least test the game_change functionality through the beta branch, console versions have no testing path at all. Each console has its own process management quirks and security models. The Xbox situation exemplifies this - what started as a simple platform absence in 2018 has evolved into a permanent technical impossibility. The process-switching architecture of game_change fundamentally conflicts with Xbox's security model, meaning Deltarune can never release on the platform without completely reworking its chapter management system. This suggests a worrying pattern for future development. Each new chapter adds another independent project to maintain, another set of potential version mismatches, another opportunity for features to drift apart. The current beta's unexpected sprite changes hint at deeper version control challenges - if the development team can't easily reproduce the last stable build of Chapter 2, how will they manage coordination between five or more chapters? Game_change was meant to solve the technical challenges of a growing game, but its implementation may have inadvertently created more problems than it solved. What began as a simple function for switching between game executables has become a fundamental constraint on Deltarune's entire development and release strategy. The rush to implement the "easier" solution - taking just a couple weeks to add process switching rather than proper VM state management - has led to years of technical debt that will affect the game's development for the foreseeable future. This serves as a sobering lesson in engine development and technical planning. Sometimes the quickest solution to implement becomes the longest to live with, especially when that solution sits at the very foundation of how a game operates.