GMTK Game Jam 2025 Post-Mortem: When Everything Breaks (And How to Fix It)

Game jams are supposed to be learning experiences, but I wasn't quite prepared for the lesson GMTK Game Jam 2025 had in store for me. I submitted what I thought was a clever little game called "err Friday," only to discover that virtually none of my core mechanics worked in the final build. It was a humbling reminder that game development is full of surprises—not all of them pleasant.

Rather than sweep this failure under the rug, I want to share the full story: what I was trying to build, what went catastrophically wrong, and most importantly, how I plan to fix it.

The Game That Almost Was

GMTK25's theme was "loop," and I was pretty excited about my interpretation. The concept was narrative-driven: you play as a wraith whose mission is to ruin a Friday night D&D session by systematically eliminating the player characters and finally the dungeon master to break an eternal loop. Death wasn't failure—it was part of the story. When your wraith was defeated, you'd resurrect the following Friday night, literally looping back in time for another attempt.

I reinforced this loop concept mechanically through enemy AI behavior. Each NPC operated on a state machine with three core states:

• Default: Peaceful patrol or idle behavior
• Alert: Triggered when the wraith was spotted
• Reaction: Either flee or pursue based on character type
• Return: Loop back to default state when the threat was gone

The development timeline was aggressive but manageable: two lunch breaks during the work week, Friday evening, Saturday night, and Sunday afternoon. Total development time was probably around 12-15 hours spread across those sessions.

The HTML Export Disaster

Here's where everything fell apart.

During development in Godot, everything worked beautifully. The state machines were responsive, the death/resurrection cycle functioned properly, and the game felt cohesive. But when I exported to HTML for web submission—which is required for GMTK—both of my core systems completely broke.

The loop mechanic that was supposed to be the heart of the experience? Non-functional. Players would die and... nothing. No resurrection, no narrative progression, just a broken game state.

The carefully crafted enemy AI? Also completely busted. NPCs would get stuck in alert states, ignore the player entirely, or behave in completely unpredictable ways.

Watching players encounter these bugs in real-time was genuinely painful. I'd put effort into creating what I thought was a cohesive experience, and instead I'd subjected people to a barely-functional tech demo.

Lessons Learned (The Hard Way)

This experience taught me several crucial lessons about game jam development:

Test your target platform early and often. I developed entirely in the Godot editor and only tested the HTML export at the very end. This is a rookie mistake that I won't repeat.

HTML exports have unique constraints. Web builds behave differently from native builds, especially regarding state persistence, threading, and resource loading.

Player feedback is invaluable. Despite the broken state of the game, players still took time to provide thoughtful feedback about what they could see I was trying to accomplish.

The 7-Step Recovery Plan

Instead of abandoning the project, I've decided to treat this as a learning opportunity. Based on player feedback and my own analysis, I've identified 7 areas for improvement, broken into critical fixes and optional polish.

Critical Fixes (Must-Have)

1. Repair Game Progression System

The death/resurrection loop needs to function as intended. This involves:

• Properly saving and loading game state between "Friday nights"
• Implementing narrative progression that persists across deaths
• Adding optional power-ups or boosts that players can select between runs to maintain engagement

2. Rebuild Enemy AI Architecture

The state machine needs a complete rewrite with proper safeguards:

• Add range detection to prevent enemies from attacking at impossible distances
• Implement buffer frames in the alert state to prevent constant state switching
• Create fallback behaviors for edge cases where the AI gets confused
• Test thoroughly in HTML export environment

3. Fix Pathfinding in Tight Spaces

My current pathfinding solution is cobbled together from two different tutorials and breaks down in confined areas. The fix involves:

• Smoothing navigation around corners and obstacles
• Redesigning levels to accommodate AI movement limitations
• Implementing better collision detection for moving entities

4. Resolve Cursor/Movement Issues

This was the most common player complaint. During development, Godot hid my system cursor, so I didn't notice the problem. In the HTML build, players saw both the game cursor and system cursor, making movement feel wrong. Solutions to try:

• Multiple cursor hiding methods for web builds
• Alternative input systems that don't rely on cursor visibility
• Better visual feedback for player movement intention

Polish Improvements (Nice-to-Have)

5. Level Design Overhaul

This step ranges from necessary (fixing tight spaces) to aspirational (creating more interesting levels):

• Modify existing levels to support improved AI pathfinding
• Design and implement the final boss encounter I never finished
• Potentially add entirely new levels with escalating difficulty
• Research level design principles more thoroughly (this was my weakest area during the jam)

6. Enhanced Visual Feedback

Players needed more information about game systems:

• Progress bar for dash/charge abilities
• Color-coded enemy types to indicate required damage or behavior
• Better telegraphing of enemy states and intentions
• Clearer UI for health, objectives, and game state

7. Content Expansion

If time and motivation permit:

• Integrate expansion assets from the tile set I used
• Add new character types and weapon varieties
• Implement additional wraith abilities or gameplay mechanics

Moving Forward

Game jams are as much about the journey as the destination, and this particular journey taught me more about the importance of platform testing than a dozen successful projects might have. The broken submission stings, but the learning opportunity is invaluable.

I'm committed to working through this 7-step plan, both as a way to salvage the project and as continued learning. Each fix will be its own mini-project with its own challenges and discoveries.

For other game jam participants who might be reading this: don't be afraid of spectacular failures. They're often more educational than smooth successes, and the game development community is generally understanding about the constraints and pressures of jam development.

What's Next

I'll be documenting the fix process as I work through it, sharing both successes and new failures as they happen. If you're interested in following along with this post-jam development journey, you can follow along.

And if you actually played "err Friday" during the jam—thank you for your patience with the broken build, and I'd love to hear any additional feedback you might have.

Sometimes the best games come from the ashes of the worst ones. Let's find out if that's true for this project.