FlyCore

The first big project of the rebuild was scalability. We needed to be able to create content fast, cleanly, and maintain it without losing our minds.

Until then, our content pipeline was deeply rustic. A Google Sheet held the questions, classified and organized in a way that kind of worked. Everything else — the flights, the worlds, the parameters, the structure — was hard-coded. Every single activity meant me opening the project, writing code, wiring things manually. Setting up one flight took me more than three hours. Three hours of fragile, repetitive work that broke easily and left bugs in its wake.

It wasn't a pipeline. It was a bottleneck. And the bottleneck was me.

So we stepped back and asked a different question: what if we didn't build content anymore — what if we built a system that built content for us?

The idea

The idea was to design a real engine inside the game. Something that would take care of assembling all the pieces — questions, activities, flights, worlds — automatically. Our job would shift entirely. No more wiring. No more hard-coding. Just designing the pedagogical journey and feeding the engine.

To get there, we had to think more procedural, more sandbox. The code needed to be rebuilt around the idea that content is data, not instructions.

The blueprint

We started prototyping with Google Sheets again, but this time as a structured architecture instead of a single dump. One sheet for questions. Another sheet for activities, referencing the question sheet. Another for flights, referencing the activities sheet. Another for worlds, referencing the flights sheet. Layer by layer, an architecture started to emerge. Each level pointed to the one below it. Each level could be edited without breaking the rest.

That was the blueprint.

The engine

Then I built the engine itself. Once the architecture was solid, I integrated the procedural system into the game. Activities, flights, worlds — they all started drawing themselves automatically. No more manual placement. No more hard-coded structure. I'd update a sheet, hit refresh in the app, and the whole experience would reorganize itself accordingly.

Honestly, the first time it worked, it felt like magic.

The Manager

But of course, once the engine was alive, working through spreadsheets quickly became absurd. You don't drive a Formula 1 with bicycle handlebars. So I built an external Manager — a proper interface that lets us handle every layer with an actual user experience. Worlds, flights, activities, questions, parameters: all editable, all visualized, all in one place.

The best part of the Manager is the visualizer. It draws the entire content arborescence live, in real time, so we can actually see the shape of FlyQuest as we build it. Branching paths, nested layers, dependencies — everything laid out visually. It transformed the way we think about content. We're not editing rows anymore. We're shaping a world.

And the last piece: a one-click import. Whatever we change in the Manager, we push to the game in a single click. The loop between content design and in-app experience went from hours to seconds.

That's how our in-house content engine was born. We called it FlyCore.

It's not just a tool. It's the backbone of FlyQuest.