We had to restart our Fractured Library demo six days before our internal deadline. Not a rebuild from scratch restart, but one of those too many issues to untangle, cleaner to start fresh with what we’d learned restarts.
It wasn’t part of the plan, but it also wasn’t a disaster. It was the kind of choice you make once you stop lying to yourself about how much duct tape is holding things together.
Here’s how the six-day crunch actually went – what worked, what didn’t, and what I’d do differently if I ever found myself back in this situation (which, hopefully, I won’t).
The Decision
This all happened the week leading up to Steam Next Fest and our Kickstarter launch. The pressure was on, but the real trigger wasn’t the deadline – it was the creeping sense that something deep in the build was off.
I was testing some light effects one night and noticed unrelated errors popping up in the console. Then scenes started loading weirdly. NPCs spawned half inside walls. Sometimes Unity just shrugged and refused to open scenes at all.
Each fix uncovered another problem until I realised I’d built a house on sand – a collection of quick patches and half-measures that had become too brittle to stand.
It was late. I was tired. I could keep throwing time at it, or I could admit what I already knew: this version wasn’t worth saving.
So I made the call – start clean, keep the art, rebuild the rest. It was my own mess to clean up, and honestly, I was relieved once I made the decision.
The hardest part wasn’t the work – it was accepting that perfect wasn’t on the table anymore.
Rebuilding the World
Day one was all about maps and movement – the skeleton of the game. I wired up the nine core scenes, re-established transitions, and rebuilt the base flow.
It went better than expected. When you know what not to do, things move fast. I set up new prefabs, reused tilesets properly, and didn’t try to make every object bespoke. That shift alone probably saved me hours.
It felt good to be rebuilding with intention instead of inertia. The first time around I’d worked modular – isolated systems stitched together later – but this time I could see the whole picture.
Clean. Simple. Functional. The kind of progress that makes you think “why didn’t I just do it like this before?”
Dialogue, Quests, and Skeletons
By day two, the focus was on bringing the narrative back to life – getting Kayak and Elliot talking again.
The big fix was the save system. In the old build, the database registration had derailed itself, which left quest references broken. Things weren’t saving correctly, and the game was hunting for GUIDs that didn’t exist. Once I understood that, I rebuilt the references and reexamined the logic from the ground up.
By the end of the day, both main quests were back in with all their tasks configured. No fluff yet, just the bones. I simplified a few triggers to make quest progression more reliable, and that clarity made the whole thing easier to test.
This was the turning point – the moment the rebuild stopped feeling like damage control and started feeling like proper development again.
Portals and Paradoxes
Day three was for portal sequences – the weirder, more technical parts of the demo. The animations came together beautifully, and Hannah jumped in to finish a few that were still outstanding.
Of course, nothing ever goes completely to plan.
At one point, Elliot – our wandering NPC – decided to spend an entire playthrough hiding in the trees. Another time I accidentally flipped an axis and watched him bolt in the wrong direction at the exact moment the end scene was supposed to trigger.
Classic.
But overall, this was a good day. The portal systems worked, animations looped properly, and for the first time I could play from start to finish without the whole thing imploding.
Colliders and Compromises
Day four was supposed to be polish day. It wasn’t.
What it actually became was fix the things that make the game unplayable day.
One of the scenes had gotten way too complicated, so I rebuilt it from scratch with a simpler setup – less clever, more functional. That choice alone saved hours.
Colliders were the real time sink, though. Getting the player to walk in front of and behind scenery consistently is harder than it looks, and I’ll admit it’s the weakest part of the demo. Those pivot points will definitely be refined for the full game.
Earlier in development I’d tried to patch problems with extra code, but this time I stopped and fixed things properly. It cost time, but it meant the rebuild wasn’t just a new coat of paint over the same cracks.
Near enough became good enough – not perfect, but stable.
Polish Pass is game dev optimism at its finest. This was more like Make Save Files Not Corrupt Pass.
The Bug Loop
Day five was triage.
The checklist looked something like this:
- Core gameplay loop: ✓
- Quest system: ✓ (mostly)
- Scene transitions: ⚠️ (functional but janky)
- Dialogue: ✓
- Polish: ✗
Every fix created new problems. Every test revealed something else slightly broken. But we prioritised what mattered: story, pacing, player experience.
If a tree rendered weird on the edge of a map, fine. If the quest chain broke two-thirds in, not fine.
I must have played through the demo dozens of times that day. Fix a task trigger, test again, break something new, repeat. It was exhausting, but by the end of the night, everything that needed to work… worked.
The Finish Line
By the final day, I was running on adrenaline and cold medicine. I’d been pretty sick – the kind of sick where there were genuine hospital conversations – but I wasn’t going to miss the finish line.
Hannah and I sat side by side: her playing, me fixing. We tweaked dialogue, tightened pacing, and added one new line that completely changed the tone of the game. That moment – seeing it click, hearing it land – made the entire week worth it.
By the end, Fractured Library was playable from start to finish. No crashes. Quests flowed. Kayak’s voice held steady, and Elliot’s story still hit the emotional beats we wanted.
Particle effects and fancy lighting didn’t make it, but the soul of the demo did – and that was the point.
Reflection
I wish I’d done more prototyping early on. I think I got too comfortable knowing I could rebuild anything later – and then, when later came, I had to.
If I could go back, I’d test the save system immediately, double the time budget for animations, and build null-safety in from day one.
But I’m also proud of what we pulled off. The story landed. The characters feel alive. People are connecting with Hannah’s world exactly the way we hoped. The technical polish will come with time, but the heart is already there.
Lessons Learned
- Know when to clear the board. Don’t throw good time after bad.
- Prototype early. Don’t build a cathedral when a cardboard model would’ve shown the cracks.
- Simpler beats clever. Every smart system I wrote cost me more time later.
- Fix it properly once. Band-aids always peel off under pressure.
- Test constantly. Especially before your brain’s too tired to tell what’s broken.
And maybe most importantly: don’t crunch alone if you can avoid it. It’s easier to stay honest about your progress when someone else is there to call out the delusion of “just one more hour.”
Closing
When everything broke, it felt like failure. Six days later, it felt like clarity.
The rebuild wasn’t glamorous, but it was necessary – a reminder that sometimes you have to burn the bad version to get to the real one.
We shipped a playable demo that told our story, hit its emotional beats, and proved that Fractured Library works. It’s not perfect, but it’s honest. And for a game built in six days, I’ll take that any time.
Game dev is iterative, messy, and rarely goes to plan. But if your core vision is strong, you can always build back to it – even when everything breaks.
If you enjoyed this and want to help us get the complete game out to the public you can support us on Kickstarter or Patreon.
Leave a Reply